Fájlrendszer felosztása /home /usr/local stb.

Linux-haladó

Sziasztok.

Mivel egyik gépemen egyszerre 3 distrib van, elgondolkodtam. Ez legtöbbször rossz jel.

Eddig kapásból 3 részre osztottam egy disket ha linux futott rajta:
/
/home
és swap.

Most azon elmélkedem, hogy mi lenne, ha külön kapna a
/boot
és a
/usr/local
egy közösen használt partíciót. Tudtommal ha a /usr/local-ba rámolok mindent, amit mondjuk állandóan használnék, vagy eleve forráskódból telepítek, nem okozhat gondot, ha más distrib felmountolja.
Más a helyzet mondjuk a /boot-tal, ott ugyanis vannak függőségek a /lib könyvtárban szereplő egyes alkönyvtáraktól, ahol a kernelmodulok vannak.Tehát ha a /boot-ot is közössé tenném, akkor a
/lib/modules
és estleg a
/lib/firmware
könyvtárakat is közösítenem kellene, vagy symlinkelnem.

Kérdésem az, hogy melyek azok a könyvtárak, melyek minden (32 bites) distribben ugyanúgy vannak használva, azaz nem okoz gondot, ha cserélgetve vannak.
Az /mnt és a /media még lehet talán, de az /opt már nem.

  • 4774 megtekintés

( locsemege v | 2015. 10. 22., cs – 19:36 )

Szerintem a /boot-tal nincs gond, hiszen az adott kernel éppen azt az fs-t fogja rootfs-ként használni, amin a saját moduljai vannak. Ami kevésbé világos, az az, hogy mi a jó több disztribúcióban, illetve miért nem virtualizációt használsz.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Ott lehet a gond, ha több telepíteni kívánt disztró ugyanolyan nevű fájlt használ a kernelre - ekkor ugyanis az egyik disztró kernele felülírja a másik disztró kernelét, ami nem feltétlen szerencsés.

Ezt még "gyerekkoromban" úgy küszöböltem ki, hogy volt egy külön partíció a kerneleknek, amit felcsatoltam mondjuk /kernels-be. Ezen a partíción voltak olyan könyvtárak, hogy distr1, distr2, stb., és a distr1 disztró /boot-ja a /kernels/distr1-re volt egy link, a distr2 /boot-ja pedig értelemszerűen a /kernels/distr2-re.
A grub-ba pedig (hda0,1)/distr1/vmlinuz és (hda0,1)/distr2/vmlinuz bejegyzések kerültek be.

Ebben igazad van. Szerencsére Fedorán oprendszer, os verzió, kernel verzió, build mind a névben vannak, így itt nem lehet ütközés, de ettől még a többi disztribúcióban lehet. Valahogy így néz ki a kernelem fileneve:

vmlinuz-4.2.3-200.fc22.x86_64

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( elod v | 2015. 10. 22., cs – 19:58 )

Kizárólag a /home.

/usr/local például függhet olyan lib-ektől amik csak egyik rendszeren vannak. Külön /boot-nak csak speciális esetekben van értelme.

"Kizárólag a /home."

Ez biztos? Mi van, ha a /home alatt tárolt config fájlok egyike nem lesz kompatibilis a másik disztrib alatt futó progival, mert az más verzió vagy csak egyszerűen más paraméterekkel fordították?

--

nTOMasz
"The hardest thing in this world is to live in it!"

Hát az ilyen izé. Amikor fiatal voltam, és azt hittem értek hozzá összehoztam egy ilyen P4-en két IDE vinyó nyolc partíciójára valami rengeteg bootos izét...
Xp, mert akkor az volt a sláger, ubuntu, meg uhu, és sok olyan izé (lehet akkor már létezett a Granular, de lehet nem) amit a distrowatch alján találsz most meg.
Na ez arra jó volt, hogy rájöjjek, hogy a közös /home az jó. Ha röhögni akarsz.
- - - - - - - - - - -
"A fejlesztők és a Jóisten versenyben vannak. Az előbbiek egyre hülyebiztosabb szerkezeteket csinálnak, a Jóisten meg egyre hülyébb embereket. És hát a Jóisten áll nyerésre." By:nalaca001 valahol máshol

Azért ez nagyon ritkán fordul elő. Éveken keresztül használtam két-három disztrót közös /home-mal (volt egy "fő" disztró, és próbálgattam más disztrókat), és sose volt ilyen gondom.
Amire nagyon figyelni kell, hogy az UID egyezzen a rendszerekben (az egyik azt hiszem, 500-tól kezdte osztani, a másik meg 1000-től).

A Red Hat, Fedora kezdte 500-tól osztogatni az uid-eket, de attól még bármilyen uid-dal létre lehetett hozni a felhasználót. Ma már ők is 1000-től kezdik osztogatni, egyrészt, hogy kompatibilis legyen a többi disztribúcióval, másrészt, hogy legyen elég kiosztható uid különféle szolgáltatásoknak.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Átfogalmazom. Red Hat-ben, Fedorában biztosan így volt korábban, persze ettől még egyéb disztribúciók esetén is lehetett így. Sőt, az a gyanúm, az Ubuntu kezdte elsőként, hogy 1000 és fölötte legyenek a normál felhasználók uid-jai.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( vl v | 2015. 10. 23., p – 16:28 )

Kérdésem az, hogy melyek azok a könyvtárak, melyek minden (32 bites) distribben ugyanúgy vannak használva

Azok, amikbe SEMMIT nem ír az adott disztribúció.
A felsoroltak közül kb. semelyikre nem igaz ez:
/boot: ide raknak dolgokat, a boot loadert simán felülcsapnák, ergó nem jó; az műxik, hogy csinálsz egy saját másik könyvtárat, és oda átmásolod, amit szeretnél (boot loader, kernel/initrd, stb.), ennek persze az a következménye, hogy a kernel frissítést nem tudod rájuk bízni, de ez több disztribúció esetén amúgy is necces lenne
/usr/local: ha nem rak ide semmit az OS, akkor lehet róla szó, bár szerintem ha valamit forrásból fordítasz, akkor igen jó esélyed lesz rá, hogy másik disztribúció alatt ne működjön (mondjuk random .so-ból más verzió van rajta, vagy openssl helyett gnutls-t rak fel, meg ehhez hasonló faszságok)
/lib/modules: ezt biztosan túrni fogja, hacsak nem fordítasz saját kernelt
/lib/firmware: ezt is túrja, és nem független a kerneltől, hogy minek kéne itt lennie
/mnt: ebben mindegyiknek saját elképzelése van arról, hogy milyen könyvtáraknak kéne lennie, bár valószínűleg ez azért kézben tartható
/home: ezzel is lesznek szopások, ha mondjuk random grafikus alkalmazásokat/felületeket használsz, és ezek eltérnek az egyes installok között

( jimmy399 v | 2015. 10. 24., szo – 05:13 )

Én speciel el sem gondolkodtam, hogy egyes disztribúciókat közös /boot vagy /home vagy /usr/lib alatt futtassak. Már ahogy korábban kitértek ezekre, hozzám sokkal jobban értők, lehetnek gubancok. Ezért én eleve külön partíciókra, merevlemezekre tettem kb minden disztribet. Így nem lesz akadás. Egy közös pont van, hogy a boot loadert a saját merevlemezükre telepítettem, és kiszedtem a grub os-prober modulját, hogy ne kutassanak más oprendszerek után. Aztán meg csináltam az ubi saját 40_custom fájljába bejegyzéseket a többi oprendszerhez, tehát az Ubuntu grubja a fő rendszerbetöltő, mert ebben lehet kiválasztani a 3 disztribet meg a windows-t.

Sőt most jut eszembe, az SSD-n lévő Windows 10/Arch közösen vannak, azért az SSD-n lévő Arch-ra eleve nem is telepítettem grubot, meghagytam hogy a Windows rendszerbetöltője maradjon a helyén.

Mellesleg megőrülök azoktól a disztribúcióktól, amik kérdés nélkül telepítenek rendszerbetöltőt arra a meghajtóra amire települnek... Meg se kérdi a többség... A másik meg hogy eleve mindegyik akar telepíteni rendszerbetöltőt, esélyt se adnak arra az esetre hogy nem is akarok eleve telepíteni, ahogy fentebb is írtam a windows/arch közös ssd-n.
Ok, értem én, hogy általában jó az, hogy telepíti, meg minden, de vannak esetek, amikor jó lenne választani hogy eleve nem is akarok... Pl. Ubi, lehet választani de olyat nem hogy nem akarok telepíteni, meg pl. Fedora, ott eleve nem is lehet választani hogy melyik lemezre akarok telepíteni rendszerbetöltőt... stb...
Na ez nem baj, csak kicsit zavaró ha olyan van, hogy pl egy másik disztribre hagyom azt, hogy töltse be...

Az utóbbi időben csak upgrade-elek Fedorát, de emlékeim szerint lehet választani, hogy telepítse vagy ne a bootloader-t, meg a helyet is, és nem csak az MBR-be, de adott filerendszerre is tudja tenni. Tehát például sdb1-re. Az igaz, hogy az új telepítő felület annyira letisztult, hogy nehéz megtalálni az efféle opciókat.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( NevemTeve | 2016. 01. 26., k – 06:53 )

Bocsánat, miért kellene a /boot-nak köze legyen a /lib-hez? (Csak nem a grub kavar valamit?)

( uid_194 | 2016. 01. 26., k – 09:20 )

Amikor legutobb ilyesmit muveltem, a bootloaderen kivul semmi kozos nem volt, /home sem. Ami config kellett, gitbe vele, es duplikaltam, ahol eltert, ott kulon branch. Igy nem voltak inkompatibilitasok, es A rendszer tooljai nem szemeteltek tele B homejat es viszont.

--
|8]

( Dwokfur v | 2016. 01. 26., k – 12:56 )

A Gobo jutott eszembe!!! :-D
Egyébként a címben szerintem a fájl rendszer felosztása helyett partícionálás lenne a jobb megnevezés...

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

A filerendszer felosztás pontosabb megfogalmazás, hiszen több partíción is lehet egy filerendszer, egy partíción is lehet több filerendszer, sőt, partícionálatlan területen is lehet filerendszer. Egyfelől lvm által, aztán van btrfs, valamint lehet simán block eszközre adott offsettel filerendszert tenni.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( sigellef | 2016. 02. 03., sze – 14:59 )

én úgy szoktam megközelíteni a dolgot, hogy mit válasszak le külön partícióra. Nyilván azokat, amik sokat íródnak.
/tmp
/var
/
/home

Server esetén a /var/log, /var/cache/squid -ot is külön pakolom.

-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.
/usr/lib/libasound.so --gágágágá --lilaliba

( zeller | 2016. 02. 03., sze – 22:59 )

A legtöbb ajánlás a /home /tmp /var /var/log /var/log/audit alá javasol minimum külön logikai köteteket, ezen felül a efi-s a gép, akkor nem elég egy szimpla boot partíció sem.