[Lezárva] Eltérő adatok az lsblk (blkid) és /etc/fstab-ban

Debian GNU/Linux

Adott egy Proxmox 8-as rendszer. Ezen van egy Debian 12 KVM virtuális gép.

Hogyan fordulhat elő a következő anomália: a /etc/fstab-ban és az `lsblk` (`blkid`) parancs kimenetében fel vannak cserélődve a /dev/sdc1 és a /dev/sdd1 eszközök?!

# lsblk
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
sda      8:0    0   60G  0 disk
├─sda1   8:1    0  1,9G  0 part [SWAP]
└─sda2   8:2    0 58,1G  0 part /
sdb      8:16   0  600G  0 disk
└─sdb1   8:17   0  600G  0 part /srv/samba/share1
sdc      8:32   0  500G  0 disk
└─sdc1   8:33   0  500G  0 part /srv/samba/share3
sdd      8:48   0  500G  0 disk
└─sdd1   8:49   0  500G  0 part /srv/samba/share2
sr0     11:0    1  627M  0 rom

# cat /etc/fstab

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# systemd generates mount units based on this file, see systemd.mount(5).
# Please run 'systemctl daemon-reload' after making changes here.
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# ...
# /srv/samba/share1 was on /dev/sdb1 during installation
UUID=11111111-1111-1111-1111-111111111111 /srv/samba/share1 ext4    noexec,usrquota,grpquota,user_xattr 0       2
# /srv/samba/share2 was on /dev/sdc1 during installation
UUID=22222222-2222-2222-2222-222222222222 /srv/samba/share2 ext4    noexec,usrquota,grpquota,user_xattr 0       2
# /srv/samba/share3 was on /dev/sdd1 during installation
UUID=33333333-3333-3333-3333-333333333333 /srv/samba/share3 ext4    noexec,usrquota,grpquota,user_xattr 0       2
# ...

Telepítéskor úgy adtam meg, ahogy a /etc/fstab-ban is van. A telepítés után semmit sem változtattam a /etc/fstab fájlban.

A `blkid` kimenete az alábbi (átrendeztem, hogy jobban láthatóak legyenek a felcserélt értékek):

# blkid
/dev/sdb1: UUID="11111111-1111-1111-1111-111111111111" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="23456789-01"
/dev/sdc1: UUID="33333333-3333-3333-3333-333333333333" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="34567890-01"
/dev/sdd1: UUID="22222222-2222-2222-2222-222222222222" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="12345678-01"

...

A telepítés óta egyszer volt újraindítva a VM és a Proxmox host, egy frissítés után.

Mi idézhette elő ezt a cserét ( talán systemd)? Hogyan lehet ezt szépen rendbe rakni, hogy a módosítások után "minden a helyére kerüljön", a módosítás tartós legyen, a VM megfelelően felcsatolja a köteteket és "ne tojja össze magát"?

  • Pl: a /etc/fstab fájlt módosítom a `blkid` parancs kimenete alapján, majd futtatom a `systemctl daemon-reload`parancsot?!
  • 595 megtekintés

( pch v | 2023. 10. 10., k – 12:40 )

Én nem látok cserét...

/dev/sdd1: UUID="22222222-2222-2222-2222-222222222222"

UUID=22222222-2222-2222-2222-222222222222 /srv/samba/share2 ext4

sdd 8:48 0 500G 0 disk └─sdd1 8:49 0 500G 0 part /srv/samba/share2

 

/dev/sdb1: UUID="11111111-1111-1111-1111-111111111111"

UUID=11111111-1111-1111-1111-111111111111 /srv/samba/share1

sdb 8:16 0 600G 0 disk └─sdb1 8:17 0 600G 0 part /srv/samba/share1

 

/dev/sdc1: UUID="33333333-3333-3333-3333-333333333333"

UUID=33333333-3333-3333-3333-333333333333 /srv/samba/share3

sdc 8:32 0 500G 0 disk └─sdc1 8:33 0 500G 0 part /srv/samba/share3

 

Vagy mit kell nézni?

pch
SB-soft online ügyviteli rendszer

Így kellene legyen:

  • /dev/sdb1    UUID=11111111-...    /srv/samba/share1
  • /dev/sdc1    UUID=22222222-...    /srv/samba/share2
  • /dev/sdd1    UUID=33333333-...    /srv/samba/share3

A /etc/fstab fájlban a "tényleges" sorok előtt a kommentezett részben "így is van" (UUID ott nincs), a telepítéskor így adtam meg a csatolásokat.

Ennek ellenére a fentiekhez képest az `lsblk` és a `blkid` parancsok kimenetében a /dev/sdc1 és /dev/sdd1 fel vannak cserélve, a /etc/fstab fájlban a kommentezett részhez képest.

Mondhatjuk azt, hogy a /etc/fstab fájlban csak a kommentek hibásak (az `lsblk` és `blkid` parancsok kimenetével összevetve), a tényleges csatolások jók, de én arról az oldalról tekintem hibásnak / felcseréltnek az eszközöket, amit elvártnak tekintek (ami a telepítéskor meg lett adva).

( persicsb | 2023. 10. 10., k – 14:00 )

Szerkesztve: 2023. 10. 10., k – 14:04

De mi a gond?
Az eszközöket UID azonosítja egyértelműen (és nem az sdc1 stb. név).
És a 33333333-3333-3333-3333-333333333333 eszköz mount pontja az a /srv/samba/share3
A 22222222-2222-2222-2222-222222222222 eszköz mount pontja pedig /srv/samba/share2.

Az, hogy éppen a 33333333-3333-3333-3333-333333333333 eszközt egy másik nevezéktan sdc1-nek, vagy sdd1-nek azonosítja, senkit nem érdekel (valószínűleg a felismerési sorrend aszinkronitása miatt egyszer sdc1, másszor sdd1 lesz). A lényeg a fájlrendszer egyedi azonosítója, semmi más nem számít.

Nem véletlenül használandó a perzisztens device név.

Lásd: https://wiki.archlinux.org/title/Persistent_block_device_naming

 

If your machine has more than one drive sharing a naming scheme, the order in which their corresponding device nodes are added is arbitrary. This may result in block device names (e.g. /dev/sda and /dev/sdb, /dev/nvme0n1 and /dev/nvme1n1, /dev/mmcblk0 and /dev/mmcblk1) switching around on each boot, culminating in an unbootable system, kernel panic, or a block device disappearing. Persistent naming solves these issues.

Mi a probléma?

A "probléma" az, hogy van egy automatizáltan létrehozott /etc/fstab fájl, aminek a komment részében lévő /dev/sd...-ra való utalás nem konzisztens az lsblk és blkid kimenetével. És ez anomáliát okozott számomra a quota -u user_name parancs kimenetének értelmezésekor, mert az nem UUID-ot használ, hanem /dev/sd...-t.

A komment nyilván nem konzisztens, le is írja, hogy a telepítéskor volt az az eszköznek a neve egy elnevezési séma szerint. De az fstab fájl érdemi része nem változott meg. 

És ez anomáliát okozott számomra a quota -u user_name parancs kimenetének értelmezésekor, mert az nem UUID-ot használ, hanem /dev/sd...-t

Mert a quota parancsot rosszul értelmezed. 

quota reports the quotas of all the filesystems listed in /etc/mtab

A quota leszarja, mi van az fstab-ban, az mtab fontos neki. Érdemes megadnod a 

--show-mntpoint

opcciót a quota számára, hogy egyértelmű legyen a dolog.

A megszokásokon nehezen változtat az ember, így vagyok ezzel én is. "Nemrég" még nem jelentett az problémát, hogy a /etc/fstab fájlban /dev/sdX-ként adtam meg azt, amit fel akartam csatolni; most ez már problémát jelent, és nem így kell csinálni.

Köszönöm az információkat.

( Raynes v | 2023. 10. 10., k – 18:48 )

Szerkesztve: 2023. 10. 10., k – 18:51

Nem értem a problémát. Az UUID-nek sose szabad változnia. Ettől a /dev/sd[akármi] az teljesen független, nem lényeges, ha eltoldóik, a UUID, PARTUUID, LABEL, stb. pont ezt hivatott kivédeni. Továbbá igen, a systemd részeként létrejövő udevd nevezi át random az eszközöket, nem csak a lemezeket, de még a Wi-Fi, USB, stb. eszközök /dev/ azonosítói is el tudnak csúszni akár minden bootnál. Nem véletlen éri sok kritika, az udevd-t, és a systemd-t is.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

én már meresztettem kerek szemeket amikor másik disk lett a hdb mint elötte volt (betettem még egy lemezet az ide port második csatijára és volt egy a második porton is) illetve amikor az eth0 nem akart müködni (pci slotba volt már egy kártya, de kellett még egy, a régi kártya hátrább lett a sorban).

volt idö amikor a telepítö létrehozta a static udev szabályokat a felismert dolgokkal, csak itt meg akkor volt gond, ha pl. disk csere történt, igy aztán szép lassan átálltak arra hogy nem hoznak létre statikus szabályokat a diskekre, de mintha valamelyik distro még csinálná.

de csinálhatsz ha akarsz most is, például a hálózati kártyákra: /etc/udev/rules.d/70-persistent-net.rules

Nem minden esetben van UUID, nem minden FS támogatja. GPT particionált rendszeren lesz, de a kernel minden alrendszere nem építhet rá. Ezért lehet az fstab-ban megadni mást is, nem csak UUID-et, de UUID az elterjedt.
Viszont a /dev/sdX nevet adó kernel alrendszer nem tételezheti fel, hogy lesz UUID, ő más logikával osztja ki a neveket.

Te kézzel bármikor csinálhatsz olyan udev szabályt, ami megadott eszközt fixen adott /dev/sdX device node-ra tesz. De erre állandó automatizmus nem építhető, csak bizonyos szűk esetekben.

( tttaaa | 2023. 10. 11., sze – 15:10 )

A /dev/disk/by-*/ alatt megtalálható az összes aktuális összerendelés.

Célszerű minden filesystem-nek egyedi label-t beállítani, a saját logikád alapján. Így nem csak egyedi lesz, de könnyen megjegyezhető is. FS-re hivatkozáskor a LABEL=<label> épp úgy használható, mint a UUID=<uuid>. Továbbá, mount -l <label> … paranccsal az adott mount-nak ideiglenes label adható.

Az én laptoppomban nagy katyvasz van. ThinkPad-T420:~$ uname -a
Linux wt-ThinkPad-T420 6.5.0-13-generic #13-Ubuntu SMP PREEMPT_DYNAMIC Fri Nov  3 12:16:05 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

fizikailag van benne egy ssd, egy hdd és pillanatnyilag egy SDcard. Ennek ellenére fura látnom ezt:ThinkPad-T420:~$ blkid
/dev/sda2: UUID="e5285a24-c3b8-42b3-9a8b-1e5ccd8d0903" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="83221d50-6dae-4bfb-af94-be8af88adbff"

Hol vannak a dev eszközeim, a blkid miért nem mond róluk semmit ?
sda                                                                           
├─sda1 vfat   FAT32       BF36-2670                             504,9M     1% /boot/efi
└─sda2 ext4   1.0         e5285a24-c3b8-42b3-9a8b-1e5ccd8d0903   49,4G    61% /var/snap/firefox/common/host-hunspell
                                                                              /
sdb                                                                           
└─sdb1 ext4   1.0         13d3a35a-ed8f-463b-8e45-1e07da78e78c

               
sdc                                                                           
├─sdc1 vfat   FAT32       76DC-9BBD                             201,8M    20% /media/wt/76DC-9BBD
└─sdc2 f2fs   1.16        94369bbb-7f4c-44ac-a65e-2dbe64b62055   10,3G    28% /media/wt/94369bbb-7f4c-44ac-a65e-2dbe64b62055

Próbáltam a blkid man szerint paraméterezett hivásaival, hogy többet, mást lássak de mindig a nem támogatott üzeneteket kaptam.

"Célszerű minden filesystem-nek egyedi label-t beállítani, a saját logikád alapján"
Az UUID és a label megadható ? Hogyan adható meg ?

üdv: virtualm

Az UUID általában a mkfs.akármi -U kapcsolóval adható meg, de nem szokás, mert pont az lenne a lényege, hogy random legyen generálva és ne okozzon ütközést az egyes fájlrendszerek között. A label az mindig csak megadható, az is formázáskor, mkfs.akármi -L címke módszerrel, bár ez változhat, attól függően, hogy milyen fájlrendszerről beszélünk, aszerint variálódhat, hogy az mkfs milyen kapcsolókat támogat, milyen formában. Nem kötelező labelt megadni, ez csak egyfajta lehetőség, hogy jobban emlékezz felcsatolásnál, és ne kelljen random UUID-t, meg eltolódó /dev/sdakármiket megjegyezni. Label esetleg a e2label partíció új_címke formában is megadható (ext fájlrendszereknél).

Arra passz, hogy a blkid miért nem látja az összes drive-od. Próbáld kiadni előtte a partprobe parancsot, hátha segít. Nálam mindig listázott mindent, minden meghajtó, minden partíció, fájlrendszer UUID, partíció PARTUUID, és ha van LABEL, akkor azt is kell írja.

Ha a hogyan kell megadnit felcsatoláskor érted, akkor az /etc/fstab-ban minden ugyanúgy néz ki, csak a /dev/akármi helyett LABEL=saját_címkéd formában hivatkozol a partícióra. Simán, shellben kiadott mount parancsnál meg az -L kapcsoló után írod a labelt: mount -L saját_címkéd /csatolási/pont

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”