Nemrég vettem egy új számítógépet, pontosabban csak nekem új a HP ElieDesk 800 G1 SFF gép.
Az alaplapon 3 db SATA3 csatlakozási lehetőség van, melyek a következők:
SATA0 Elsődleges merevlemez (sötétkék)
SATA1 Bármilyen SATA meghajtó, amely nem az elsődleges merevlemez (világoskék)
SATA2 Bármilyen SATA meghajtó, amely nem az elsődleges merevlemez (világoskék)
Nálam az alábbi csatlakozás van kialakítva:
SATA0 egy 512GB-os SSD
SATA1 egy 500GB-os HDD
SATA2 egy DVD olvasó
Mindkét lemezt még a beépítést megelőzően particionáltam a GParted segítségével, az általa ajánlott beállításokkal.
A partíciós tábla mindkét lemez esetében GPT.
512GB-os SSD (SATA0)
--------------------
sda1 - 300MB - EFI rendszer
sda2 -  32GB - ext4 (Debian 131.)
sda3 -  32GB - ext4 (MX Linux 23.6)
sda4 -  32GB - ext4 (nincs használatban)
sda5 - 415GB - ext4 (adatok)
500GB-os HDD (SATA1)
--------------------
sdb 1 - A teljes lemez ext4 LUKS titkosítással
A Debian 13-at használom napi szinten, automatikus csatolás (fstab) sda1, sda2, sda5, manuális csatolás sdb.
BIOS-UEFI jelenleg: UEFI Boot, Secure Boot engedélyezve, Legacy boot tiltva. Viszont volt már UEFI Boot, Secure Boot tiltva és Legacy boot engedélyezve. A probléma vonatkozásában eredmény nem változik, vagyis az sda és sdb időnként véletlenszerűen és kiszámíthatatlan gyakorisággal felcserélődik.
Akkor nézzük a /etc/fsatb szerkesztését. Évekig eszköznévre hivatkozással szerkesztettem (sda, sdb stb. néven hivatkoztam a partíciókra), de olvastam, hogy ez már "idejétmúlt". Rendben, legyen akkor UUID-re hivatkozás. Nem jött be. Na, akkor legyen disk by-id, majd disk by-partlabel. Szintén eredménytelen.
Na akkor próbáljuk a HUP-ot :)
Szívesen veszek minden előre múltató segítséget. A regisztrációm ideje senkit ne csábítson könnyelműségekre, csak szájbarágósan. :)
Megoldás:
Amit mindenki leírt, tehát UUID. Az általam problémának tekintett eszköznév cserére locsemege részletes magyarázatot adott (nektek ez evidencia, számomra új információ) gthomas hozzászólását olvasva pedig "homlokon rúgott a múzsa", hát persze, hogy a cryptsetup open esetén is az UUID-re kellene hivatkozni. 
Köszönöm mindenkinek, hogy foglalkozott a problémámmal és segített a megoldásban.
- 735 megtekintés
Hozzászólások
"legyen akkor UUID-re hivatkozás. Nem jött be."
Ezt kifejthetnéd, hogy mit jelent hogy nem jött be, mert azért viszonylag szokott működni.
- A hozzászóláshoz be kell jelentkezni
Szerintem is UUID-vel nem cserélődhet fel a két partíció, mivel általában nem szokott a kettő bitre megegyezni.
- A hozzászóláshoz be kell jelentkezni
Talán félreérthetően fogalmaztam. Nem a partíciók cserélődnek fel, hanem a lemezek . Tehát rendesen az sda az SSD (SATA0), az sdb (SATA1) pedig a HDD. Ezek cserélődnek időnként, így az SSD lesz az sdb és a HDD az sda.
- A hozzászóláshoz be kell jelentkezni
Jó, de ez az előnye a PARTUUID (mert gondolom ez lenne az) használatának, mindegy hogy hová kerül a disk, sda, sdb, nem számít.
A PARTLABEL is szokott működni.
Szóval a "nem jött be", "szintén eredménytelen" dolgokat kéne tisztázni. Különös tekintettel az aktuális hibaüzenetre. Csak hogy értsd, ezek a dolgok azért úgy általában, ha nincs elírva semmi, működnek. Szóval vagy el van írva valami, vagy valami nagyon egzotikus dolog miatt nem megy.
- A hozzászóláshoz be kell jelentkezni
Az /etc/fstab-ban ezt a két variációt próbáltam:
# disk by-id
# /dev/disk/by-id/ata-Vi550_S3_SSD_4935252083715032-part1    /boot/efi               vfat            umask=0077           0  1
# /dev/disk/by-id/ata-Vi550_S3_SSD_4935252083715032-part2    /                          ext4            errors=remount-ro   0  1
# /dev/disk/by-id/ata-hp_DVD-RAM_UJ8E1_1417TP228187ESH3H   /media/cdrom0    udf,iso9660  user,noauto             0  0
# /dev/disk/by-id/ata-Vi550_S3_SSD_4935252083715032-part5    /mnt/mdrive          ext4           defaults,noatime      0  2
# disk by-partlabel
/dev/disk/by-partlabel/ESP        /boot/efi          vfat         umask=0077            0  1
/dev/disk/by-partlabel/DEBIAN  /                     ext4         errors=remount-ro   0  1
/dev/disk/by-partlabel/MDRIVE  /mnt/mdrive    ext4         defaults,noatime       0  2
- A hozzászóláshoz be kell jelentkezni
UUID alapjan csatold. az tuti nem valtozik. Tobbiek is ezt irtak, de te id alapjan csatoltal.
- A hozzászóláshoz be kell jelentkezni
Nem működött:
UUID=038E-BCA5  /boot/efi   vfat   umask=0077   0  1
UUID=90015ed1-e8ef-424b-a3fe-1cb2c75d3cbd /   ext4    errors=remount-ro   0  1
UUID=ebd9007f-5048-4d22-aeed-efe155d9594c  /mnt/sda5   ext4    defaults,noatime   0   2
/dev/sr0   /media/cdrom0   udf,iso9660   user,noauto   0  0
- A hozzászóláshoz be kell jelentkezni
Azért a "nem működött" megint elég általános megfogalmazás.
Nem tudom mi van a /mnt/sda5 alatt, de szemre olyan, amit lehet futás közben umountoni, átírni az fstabot (systemctl daemon-reload) és csapni egy mount -a parancsot, hogy na, mégis, mi a probléma.
Ha nagyon nem nyilvánvaló, akkor pl. egy findmnt --verify --verbose is mehet.
Valami konkrét hibaüzenetnek kell lennie.
- A hozzászóláshoz be kell jelentkezni
sudo umount /dev/sda5
sudo systemctl daemon-reload
sudo mount -a
Fenti három esetében semmi üzenet.
sudo findmnt --verify --verbose
/boot/efi
   [ ] target exists
   [ ] FS options: umask=0077
   [ ] source /dev/disk/by-partlabel/ESP exists
   [ ] FS type is vfat
/
   [ ] target exists
   [ ] FS options: errors=remount-ro
   [ ] source /dev/disk/by-partlabel/DEBIAN exists
   [ ] FS type is ext4
/mnt/mdrive
   [ ] target exists
   [ ] VFS options: noatime
   [ ] source /dev/disk/by-partlabel/MDRIVE exists
   [ ] FS type is ext4
Success, no errors or warnings detected
- A hozzászóláshoz be kell jelentkezni
mount /mnt/mdrive
grep mdrive /proc/mounts
dmesg
?
Én egyébként LABEL=xyz-t jobban szeretem, átláthatóbb, mint egy UUID.
- A hozzászóláshoz be kell jelentkezni
mount /mnt/mdrive
grep mdrive /proc/mounts
/dev/sda5 /mnt/mdrive ext4 rw,noatime 0 0
dmesg
[11824.702768] EXT4-fs (sda5): unmounting filesystem ebd9007f-5048-4d22-aeed-efe155d9594c.
[11859.250000] EXT4-fs (sda5): mounted filesystem ebd9007f-5048-4d22-aeed-efe155d9594c r/w without journal. Quota mode: none.
- A hozzászóláshoz be kell jelentkezni
Akkor működik.
Vagy csak a mount -a problémás?
- A hozzászóláshoz be kell jelentkezni
Nem tudom, nem értek hozzá. Nem lehet, hogy az UEFI-kernel-udev hármas kavar?
- A hozzászóláshoz be kell jelentkezni
De akkor mi a hibajelenség?
Nem bootol be a gép?
A fenti fstabnál a / és a /boot/efi-nél hiányzik az "auto" flag (ami a defaultsban benne van).
Miután hozzáraknám ezt a flaget, még egy update-initramfs-t futtatnék.
- A hozzászóláshoz be kell jelentkezni
Valószínű már csak holnap próbálom, de ide másolom amit a Debian telepítő hozott létre (ebben nincs "auto" flag)
#/ was on /dev/sda2 during installation
UUID=90015ed1-e8ef-424b-a3fe-1cb2c75d3cbd /   ext4    errors=remount-ro   0  1
#/boot/efi was on /dev/sda1 during installation
UUID=038E-BCA5  /boot/efi   vfat   umask=0077   0  1
/dev/sr0 /media/cdrom0 udf,iso9660 user,noauto 0 0
- A hozzászóláshoz be kell jelentkezni
Na most ebben az fstabban egy árva hivatkozás sincs a LUKS-os partíciódra. Ha kézzel indítod a cryptsetupot, annak is megadhatod a /dev/sdb1 helyett a /dev/by-id/...-t elérést.
Attól, hogy a partíciókra UUID-el hivatkozol, nem fog stabilizálódni az sda/sdb elnevezés.
- A hozzászóláshoz be kell jelentkezni
Miután megoldottnak jelöltem a szálat jött a hozzászólásod. Igen, ahogy gthomas is jelezte a cryptsetup open esetén is az UUID-ra kell hivatkozni. Köszönöm.
- A hozzászóláshoz be kell jelentkezni
Sőt, a kernel paraméterek között a rootfs hivatkozása se /dev/sda1, vagy valami hasonló legyen, hanem az is UUID=blabla. Bár ott még nincs kernel, de a grub is egy mini oprendszer lényegében, szóval én azért maradnék a biztosan működő megoldásnál. Fejből nem tudom, hogyan kell megmondani ezt a grubnak. A gond az, hogy ha túl direkt módon mondod neki, akkor működni fog a következő kernel frissítésig, amikor is különféle template-ek alapján a scriptek újra generálják a configfile-t, eltüntetve, amit beleírtál. Ezért kezdődik úgy commentben, hogy Do not edit this file!, vagy valami hasonló.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE- A hozzászóláshoz be kell jelentkezni
Mármint azt nem tudod, hogy működik-e?
Én egyébként - szerintem nem egyedül - nem értem a problémát. Az világos, hogy amennyiben a /dev/sda1, és efféle neveken hivatkozol, abból itt a piros, hol a piros lesz, mert attól függ, éppen melyik eszköz mennyi idő alatt jelentkezik be. Többen mondták az UUID-et, amire az volt a válaszod, hogy nem működik. Ennek az volna a menete, hogy megnézed, mit riportál az lsblk -f parancs, majd a kívánt UUID-et szépen bemásolod az fstab-ba. Mented, majd reboot. Mit tapasztalsz, hogyan nem működik? Megáll, mint a szög, be sem boot-ol? A nem működés mikéntjéről nem beszéltél.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE- A hozzászóláshoz be kell jelentkezni
Amit tapasztalok. Elindul a gép, működik, bejelentkezem (LightDM), akarom csatolni (cryptsetup) a HDD-t (/dev/sdb LUKS), nem csatolja. Elindítom a Lemezek alkalmazást (gnome-disks) és azt látom, hogy a HDD nem sdb, hanem sda. Újraindítom a gépet és ha szerencsém van a HDD újból sdb lesz. Ebből én arra következtetnék - de javítsatok ki - hogy a kernel rontja el, hogy sda vagy sdb lesz a lemez.
Változtattam a /etc/fstab-on az alábbiak szerint és újraindítottam a gépet.
/dev/disk/by-partuuid/40ab2fc2-f9d8-483e-a085-7654b8a4525f  /boot/efi        vfat    umask=0077           0  1
/dev/disk/by-partuuid/c8e52b9b-ca3f-4dce-9022-44f1c2543a39  /                   ext4    errors=remount-ro   0  1
/dev/disk/by-partuuid/27d2b286-a752-4e93-995b-f13244d3ffa5  /mnt/mdrive  ext4    defaults,noatime      0  2
Most ez a helyzet:
lsblk -f
NAME FSTYPE FSVER LABEL        UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
sda                                                                                
├─sda1
│    vfat   FAT32              038E-BCA5                             294,7M     2% /boot/efi
├─sda2
│    ext4   1.0                90015ed1-e8ef-424b-a3fe-1cb2c75d3cbd     20G    27% /
├─sda3
│    ext4   1.0                833374e2-95b0-4523-8464-a2a71c488e61                
├─sda4
│    ext4   1.0                807b2617-d8d1-4cea-a6b0-e3316aedab05                
└─sda5
     ext4   1.0                ebd9007f-5048-4d22-aeed-efe155d9594c  355,5G     1% /mnt/mdrive
sdb  crypto 2                  0cf30abb-70bb-4439-af0c-02eca31807e3                
└─ddrive
     ext4   1.0   SEAGATE500GB 692b3e50-ff08-4f9c-86bb-f281716a66ea  154,4G    61% /mnt/ddrive
sr0
Itt már csatolva van manuálisan a HDD is. Ha újból jelentkezik a probléma milyen parancsok kimenete segíthet?
- A hozzászóláshoz be kell jelentkezni
Kezdem érteni a problémádat. Attól, hogy UUID-et használsz, továbbra is néha sda, néha pedig sdb lesz az a disk. Éppen azért haszálsz UUID-et, hogy akár az sda-n, akár az sdb-n lesz az a partíció, amelynek az UUID-jét az fstab-ba írtad, mindenképp ahhoz a csatolási ponthoz legyen mont-olva az fs, ahova szeretnéd.
Az, hogy a disk nem fixen ugyanaz a block device, az nem bug. Elindul a kernel, szimatol, s amikor megvan egy újabb eszköz, tehát felpörgött a disk, a mikrokontroller startup timer-e kivárta, amíg stabilizálódik a tápfeszültség, majd diagnosztikát futtat, felépíti az adatstruktúráit, akkor bejelntkezik, s az aktuális soron következő block device lesz a disked. Ezt az UUID-sem fogja fixálni, de nem is kell, mert nem sda2-ként hivatkozol rá, ami néha sdb2 lesz, hanem UUID-dal, amit akkor is megtalál, ha történetesen az sda2, meg akkor is, ha sdc2.
Tehát ha a későbbiekben sda2-ként hivatkozol például egy titkosítás feloldásakor rá, akkor még mindig a konfigurációt szúrtad el.
A problémád tehát fog létezni, de ezt tekintsd tulajdonságnak, ez nem bug. Olyan metodikát válassz, hogy mindig UUID-dal, vagy mindig LABEL-lel hivatkozz. Inkább az előbbivel. Illetve, ha az fstab-ba be van jegyezve a filerendszer, akkor a csatoláskor nem kell hivatkozni a device-ra, elég a mount point, hiszen épp az fstab-ból tudja majd az eszközt. Tehát a mount /mnt/ddrive, vagy mount /mnt/mdrive root joggal működni fog. Ha sima userként kell, akkor a user illetve users opciók valamelyikét használd az fstab-ban.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE- A hozzászóláshoz be kell jelentkezni
Eszembe jutott egy példa programozásból. A buff = malloc(size); esetében sem tudod előre, hol, milyen címen adja oda a malloc() a kívánt méretű területet, ellenben megmondja azt a visszatérési értékében. Vagy NULL, ha nem sikerült. Nincs dolgod azzal, hogy mint szám, mint memóriacím, mi lesz a buff értéke. Amikor használod, erre hivatkozol. Bármi is legyen buff, onnantól kezdve tied a size méretű memória. Felszabadításkor pedig ezt a címet adod a free()-nek, s megint csak lényegtelen, mennyi. Tehát free(buff); buff = NULL; lesz a megoldás.
Neked éppen ennyire teljesen mindegy, hogy az a háttértár sda, sdb, sdc, vagy micsoda. Valami. Ha nagyon tudni akarod, UUID alapján egy scripttel kiszeded az lsblk -fr kimenetéből. De lényegtelen, nincs dolgod vele.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE- A hozzászóláshoz be kell jelentkezni
Labelt azért nem szeretem, mert nem egyedi. Hajlamos az ember olyan neveket adni, mint például rootfs, home, aztán ha két ilyen disk kerül a gépbe, kész a baj. Én maradok az UUID-nál, copy-paste, a csatolási pontból úgyis látszik, mi akar az lenni.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE- A hozzászóláshoz be kell jelentkezni
Nálam épp "newroot" a / :)
- A hozzászóláshoz be kell jelentkezni
Akkor az már olyan egyedi, hogy kizárt, hogy valaha ütközés legyen. ;)
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE- A hozzászóláshoz be kell jelentkezni
Desktop gépbe amúgy se szoktam túl gyakran másik diszket rakni. USB-s drivenak tutni nincs ilyen labelje :)
- A hozzászóláshoz be kell jelentkezni
Naja, de ez előny is lehet pl. cserélhető diskeknél, a label mindig "DATA" és mindegy, melyiket teszi be az ember, ott lesz.
Persze ez csak addig előny, amíg egyszerre csak egy disk van :)
És igen, ha nagyon akar az ember, akkor lehet rá vagy ötven más megoldást találni.
- A hozzászóláshoz be kell jelentkezni
/off
en mar csak ott hasznalok particios tablat, akkor a devicet fel akarom osztani _particiokra_ (sda). nalam is van masodlagos disk, es egyben hasznalom az egeszet, igy azon mar nincs kulon GPT, egybol a lusk van rajta.
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
- A hozzászóláshoz be kell jelentkezni
a LUKS struktura is felfoghato particios tablanak
neked aztan fura humorod van...
- A hozzászóláshoz be kell jelentkezni
Éppenséggel bedobhatnál egy lsblk és egy blkid parancs kimenetet is.
Hogy érted, hogy az UUID módszer  nem sikerült? mutatnál példát az  fstab-ra amikor nem sikerült? 
- A hozzászóláshoz be kell jelentkezni
fstab feljebb
lsblk
NAME     MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
sda        8:0    0 476,9G  0 disk  
├─sda1     8:1    0   300M  0 part  /boot/efi
├─sda2     8:2    0    30G  0 part  /
├─sda3     8:3    0    30G  0 part  
├─sda4     8:4    0    30G  0 part  
└─sda5     8:5    0 386,6G  0 part  /mnt/mdrive
sdb        8:16   0 465,8G  0 disk  
└─ddrive 254:0    0 465,7G  0 crypt /mnt/ddrive
sr0       11:0    1  1024M  0 rom 
blkid
/dev/sdb: UUID="0cf30abb-70bb-4439-af0c-02eca31807e3" TYPE="crypto_LUKS"
/dev/mapper/ddrive: LABEL="SEAGATE500GB" UUID="692b3e50-ff08-4f9c-86bb-f281716a66ea" BLOCK_SIZE="4096" TYPE="ext4"
/dev/sda4: UUID="807b2617-d8d1-4cea-a6b0-e3316aedab05" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="1ede9e21-83e7-4901-9c23-23839210f44b"
/dev/sda2: UUID="90015ed1-e8ef-424b-a3fe-1cb2c75d3cbd" BLOCK_SIZE="4096" TYPE="ext4" PARTLABEL="DEBIAN" PARTUUID="c8e52b9b-ca3f-4dce-9022-44f1c2543a39"
/dev/sda5: UUID="ebd9007f-5048-4d22-aeed-efe155d9594c" BLOCK_SIZE="4096" TYPE="ext4" PARTLABEL="MDRIVE" PARTUUID="27d2b286-a752-4e93-995b-f13244d3ffa5"
/dev/sda3: UUID="833374e2-95b0-4523-8464-a2a71c488e61" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="6b4a7520-d23c-4ed8-a4ec-57887ad634f7"
/dev/sda1: UUID="038E-BCA5" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="ESP" PARTUUID="40ab2fc2-f9d8-483e-a085-7654b8a4525f"
- A hozzászóláshoz be kell jelentkezni
Persze a kernel nem tud ám uuid-et kezelni, szóval ha korábban tradicionális eszközneveket használtál, lehet hogy nincs is az initrd-ben az a kód ami létrehozná az uuid transzlációt? Asszem az udev csinálja valahogy, de nem mostanában néztem, meg egyébként a disk-by-path meg hasonlókat is az udev pakolja oda, talán egy initrd update segítene egy olyan állapotban amikor uuid van az fstabban?
- A hozzászóláshoz be kell jelentkezni
Erre gondolsz?
sudo update-initramfs -u
- A hozzászóláshoz be kell jelentkezni
/etc/crypttab -ban ugye nem /dev/sda -ra hivatkozol?
- A hozzászóláshoz be kell jelentkezni