Sziasztok és egyúttal elnézést, hogy ide írom de nem akartam fragmentálni a fórumot új topik indításával.
Szóval sokszor látjuk, a nemzetközi fórumon is, egy-egy huge-kernel kiadás esetén, hogy usmerged, NON-usrmerge, stb.
A pontos okát nem ismerem és nem is tisztem ecsetelni, de a gyakorlati hatását már annál inkább:
mit jelent az, hogy usrmerge(d) és non-usrmerge(d) kernel, firmware fdrv, stb. Amik nálunk a symlinkes, semi-symlinked és classic-standard kivitelt jelentik?
Gyakorlatilag arról van szó, hogy ami(k) eddig a / gyökérben mappák voltak, tehát a:
De legfőképpen a következő triumvirátus:
Ezek egyetemesen átkerültek a /usr könyvtárba, tehát már csak linkek a / gyökérben, és egybe lettek ömlesztve az /usr könyvtáron belül lévőkkel.
A következő kérdés teljesen jogos ezúttal, hogy akkor ha visszahelyezzük a kérdéses könyvtárakat fizikailag a / gyökérbe az /usr-ből akkor az usrmege(d) kernelből és firmware-ből classic-standard avagy non-usrmerge(d) kernelt és firmware-t lehet csinálni? A válasz: IGEN!
Ugyanez a folyamat érvényes visszafelé, tehát bármely classic-standard, non-usrmerge(d) huge-kernelből és fdrv firmware sfs-ből készíthetünk usrmerge(d) avagy symlinked változatot.
Hogyan?
Először is egy ext fájlredszerű partíción, vagy a /tmp könyvtáron egy tetszőleges mappában, vagy a /root mappa bármelyikében egy tetszőleges könyvtárban, elmásoljuk az eredeti fdrv és zdrv vagy kernel-modules és vagy még a hozzá tartozó kernel forrás sfs-t.
az
parancs kiadásával annak kibontott tartalmával létrejön egy squashfs-root könyvtár, én ezt a leendő mivoltának megfelelően átnevezem ROX-Filerrel, pl: zzdrv -re kernel esetén, ffdrv-re fdrv esetén és ssrc-re kernel forrás sfs esetén.
Miután a classic-standard avagy a non-usrmerge(d) kivitel kibontott / gyökerében ott a /sbin és a /lib egyedül ezt a két mappát huge-kernel esetén áthelyezzük a mellette levő /usr könyvtárba. Majd puppy esetén:
paranccsal újabb zdrv sfs kimenetet hozunk létre amit megfelelően visszanevezve a helyére másolva megkapjuk a symlinkesített huge-kernel változatot.
firmware esetén (fdrv) hasonló az eljárás, ott a /lib mellé létrehozunk egy /usr könyvtárat, és belehelyezzük a mellette lévő /lib könyvtárat. Fontos, hogy a / itt a kicsomagolt sfs mappáját jelöli gyökérként! Nem pedig a rendszer / gyökerét!
Ugyanez visszafelé:
usrmerge(d) kernel és firmware fdrvnél a /usr -ből kihelyezzük a felette eggyel álló / -be az /usr/sbin illetve /usr/lib könyvtárat.
Másik nagyon fontos észrevétel erre ma jöttem rá:
Egyes puppyknál a /usr/lib64 link a /usr/lib -re, tehát itt a zdrv esetén ügyeljünk arra, hogy a /usr/lib64 könyvtárban lévő 2 symlinket és amire mutatnak libau.so.2.10 fájlt úgy hagyjuk érzékelhetővé globálisan, hogy ezt a /usr/lib64 könyvtárat meghagyván a /usr-ben csak simán lib -re átnevezzük lib64 -ről. Így minden esetben látni fogja a rendszer a libau.so.2.10 libet ami ha jól sejtem az aufs függősége.
A semi-symlinked pl.: hybrid vagy hibrid-bookworm64 puppyknál nyer értelmet: Ott a /lib kivételével mozgatunk mindent a /usr-be. Tehát ott egyedül a /lib marad mappa a gyökérben.
Remélem érthető voltam!
Ennek megfelelően készítettem egy usrmerge(d) GigaPack-ot, amiben benne az új fdrv, ucode.cpio, kernel fájlok és forrása. + README.txt
Íme:
https://sourceforge.net/projects/puppys ... 2/download
Kernel forrásnál pedig csak arra kell figyelni, miután áthelyeztük a lib könyvtárat a mellé kreált usr-be, akkor a lib mappa legutolsó útvonalán szereplő 2db szimbolikus linket (build és source) töröljük, majd a felette lévő usr src linux mappára relatív linkeléssel újra létrehozzuk - átnevezzük.
Visszafelé ugyanígy, ha csak usrmerge(d) kernel forrásunk van.