Fstab-ba hogyan érdemes csatolni a partíciókat?

Fórumok

Sziasztok!

Én 3 féle módot ismerek: /dev/sdX, UUID és LABEL.

Nálam ma egy kernel update során az UUID kiesett, elszállt az egész, mert néhány partícióm UUID-ja megváltozott (wtf?!)
/dev/sdX szintén kiesett, mert bootoolás alatti detektálásnál függ, melyik lesz az sda és melyik lesz az sdb.
Maradt a LABEL, de ezzel is vannak fenntartásaim.

Szóval ti miként csatoltok fstabban partíciót, ha több merevlemez/SSD van a gépben?

Hozzászólások

Én uuid-vel. Az, hogy megváltozott elég érdekes, gondolom nem feature, inkább bug :-)
Ha a uuid megváltozik, akkor annyi erővel a label is változhat...

Nagyon fura lenne, ha a uuid megvaltozna, mivel az a filerendszer keletkezesekor jon letre es semmi koze a particiohoz. Itt szerintem valami mas lesz, amit a kollega nezett be.
A "/dev/sdX" a particiot jelenti, de mind a Label, mind pedig a UUID a fajlrendszer resze. Nem tudom nem e blkid-t rakott e a kollega az fstabba a uuid helyett....

A hetvegen allitottam at mindent LABEL-re. Az ok: ssd-re csereltem a rootot ujratelepites nelul, szoval a korabbi winyorol dd-vel csinaltam egy masolatot, ami ugye a UUID-t is masolta, szoval az sem eleg unique. Gondolom atallithattam volna valami ujra konnyen, de szamomra amugy is konnyebben fogyaszthato, ha a winyok particioit elnevezem, es utana ugy hivatkozom rajuk.
A /dev/sdX ugye nem jo (jelenleg eleg gyakran cserelgetem, adatokat rendezek, most sde-ig vannak).

--
A strange game. The only winning move is not to play. How about a nice game of chess? - Wargames

Nekem van mind a 3 féle. Ott ahol a telepítő megcsinálta valahogy, ott általában úgy marad ezek tipikusan mostanában uuid vagy label. A régi rendszereim mindig /dev/valami. Van vegyes is, ha én rakok be utólag valamit az mindig /dev/valami lesz(én ezt jobb szeretem, ez van), így ha a telepítő másképp csinálta a többi diszket, akkor ezek meg vegyesek lesznek.
--
Rózsár Gábor (muszashi)

LVM? akkor neve lesz mindegyik partíciónak... ;) :D

Ez nekem olyan fura a linuxos LVM-en. Mi köze a disknek ahhoz, hogy hogyan nevezem a groupját egy rendszerben? Normális esetben a VG nevét a vgimport során határozom meg, a disknek csak a VGID-t kell ismernie. De linuxon ezt sem sikerült normálisan implementálni. :-(

Ave, Saabi.

komoly rendszerekben uuid-val csatolják a disk-ket

Dirty Cow CVE miatt frissült a kernel.
Hibát az apt nem dobott, gondoltam, minden szép és jó. Rebootnál már nem állt fel többé a rendszer, mert nem találta az fstab-ban szereplő HDD-ket UUID alapján. Tömören ennyi a lényeg.

Sajnos csak a reinstall maradt, mivel live CD-t sem tudtam bebootolni, másképp nem lehetett megoldani.

Kemény 8 órám ment rá, mire mindent vissza tudtam rakni. Szerencsére adatvesztés nem volt.

--
-- GKPortál Blog
Tégy Jót!®
Legyen neked is Dropbox tárhelyed! :)

Trollbe#

Jajjjjj.... a kategóriát is nézd. Jó kis tanulópénz na. Teszem hozzá, csináltam ilyeneket én is annak idején. Sőt. Durvábbakat is.

Trollki#

---------------------------------------------------------------
Ritkán szólok hozzá dolgokhoz. Így ne várj tőlem interakciót.

Dehogy töröltem. Egyszerű apt-get update ; apt-get upgrade volt. Tessék a kimenet (php is frissült, de a felesleges részeket most kigyomláltam):

Az alábbi csomagok frissítve lesznek:
linux-image-3.16.0-4-amd64 (3.16.7-ckt20-1+deb8u4 => 3.16.36-1+deb8u2)

14 frissített, 0 újonnan telepített, 0 eltávolítandó és 0 nem frissített.
Letöltendő adatmennyiség: 40,2 MB.
A művelet után 553 kB lemezterület kerül felhasználásra.
Folytatni akarja? [I/n]
Letöltés:5 http://security.debian.org/ jessie/updates/main linux-image-3.16.0-4-amd64 amd64 3.16.36-1+deb8u2 [33,9 MB]
[...]
Reading changelogs... Done
Csomagok előkonfigurálása ...
(Adatbázis olvasása ... 56302 fájl és könyvtár van jelenleg telepítve.)
Kibontás előkészítése: .../linux-image-3.16.0-4-amd64_3.16.36-1+deb8u2_amd64.deb ...
Kibontás: linux-image-3.16.0-4-amd64 (3.16.36-1+deb8u2) e helyett: 3.16.7-ckt20-1+deb8u4 ...
[...]
Aktiválók feldolgozása: man-db (2.7.0.2-5) ...
Beállítás: linux-image-3.16.0-4-amd64 (3.16.36-1+deb8u2) ...
/etc/kernel/postinst.d/initramfs-tools:
update-initramfs: Generating /boot/initrd.img-3.16.0-4-amd64
/etc/kernel/postinst.d/zz-update-grub:
Generating grub configuration file ...
Found background image: /usr/share/images/desktop-base/desktop-grub.png
Found linux image: /boot/vmlinuz-3.16.0-4-amd64
Found initrd image: /boot/initrd.img-3.16.0-4-amd64
done

--
-- GKPortál Blog
Tégy Jót!®
Legyen neked is Dropbox tárhelyed! :)

Ugy emlekszem, ilyenkor kapsz egy nagyon lekorlatozott shellt, amivel fel tudod mountolni a root particiodat, atirod a /etc/fstab-ot, aztan reboot..

Ezen kivul milyen telepitod van, amivel telepiteni tudsz, de felmountolni egy egyebkent ismert fs-t, es megvaltoztatni egy file-t nem? Az osszes normalisabb disztro telepitoje kepes egy root shell kiadasara, nemelyik sokkal tobbre is ennel.

--
A strange game. The only winning move is not to play. How about a nice game of chess? - Wargames

A kernel firristese tutira nem irta volna at a disken levo filerendszer uuid-jat. Hozza sem nyul egy kernel update a filerendszer leiroihoz, se az fstab-hoz. Maximum az initrd-t updatelheti, de az sem nyul a UUID-hoz. Nem tudom mi volt a problema, de gyanus, hogy nem a UUID volt a baj. Sokkal inkabb el tudom kepzelni, hogy valami initrd problema volt.
Ja meg talan a GRUB elcseszese johet szoba, ha elcseszta a "root="-t

Komolytalan vagyok és LABEL-lel csatolom.
Egyébként mondjuk SSD-s rendszeren dd_rescue helyett már rsync-kel mentek és értelemszerűen diszkenként eltér az UUID. Meghibásodás esetén ha cserélni kell, akkor nem kell első lépésben a csere vinyó fstab-jában állítgatni az UUID-ket, hogy egyáltalán be tudjon boot-olni a menté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."