Update 2019.06.05. - 21:55
Ezzel kapcsolatban is felmerült egy kérdés. Több helyen is olvastam, hogy vagy csak az adatokat, vagy a /boot partíciót is raid-be rakjuk, de utóbbi esetén külön-külön. Jelenleg nem tudom elképzelni sem, hogy ha tükörben van 2 lemez azonos tartalommal és bármelyiket kiveszem, akkor a másikról ugyanúgy fut/indul a rendszer. A BIOS boot order még okés, ott beállítok egy sorrendet, ha nincs A, jön a B. Még a 2 lemezen a 2 különböző bootloaderrel sem lenne gond, viszont kérdéses, hogy ha a rendszer is tükrözve van (egyáltalán lehet-e?) akkor képes-e elindulni ha A helyett a B lemez van csak. Ha jól tudom, az /etc/fstab fájlban lehet a partíciókra flag-el is hivatkozni illetve dev-by-name vagy valami ilyesmi az uuid helyett, így elvileg nem okozhat gondot de ha van 2 lemezem, mindegyiken van egy BOOT flag-es partíció vagy egy /boot, és eljut addig a rendszer, hogy már olvassa az fstab-ot, akkor honnan tudja melyik lemezről folytatódjon a művelet. Gondolom amelyiken megkezdődött, azon megy tovább a boot folyamat mert elvileg a BIOS/UEFI már kiválasztotta a lemezt, a bootloader bootolhatna másik lemezről/partícióról, de.... áhhh na itt már teljesen belekeveredtem. Ennek alaposan utána kell nézzek
Engedd meg, hogy erre röviden reagáljak. Megpróbálom felvázolni a boot leegyszerűsített folyamatát.
Szóval, a Linux bootolása úgy történik, hogy a BIOS/UEFI kiválasztja a megfelelő fizikai lemez eszközt, aminek BIOS esetén betöltődik az MBR rekordja, ami átirányítja az ugyanazon eszközön belül levő boot partición lévő bootloader kódra a vezérlést, UEFI esetén viszont a teljes bootloader betöltődik. És pont, ezen a ponton a Linux bootfolyamatának függése a BIOS által kiválasztott boot eszköztől véget is ér, innentől csak és kizárólagosan a bootloader konfigurációja az irányadó. A GRUB 2 konfigurálható úgy, hogy adott UUID-ű partíciót keressen, erről töltsön kernelt és initrd-t, vagy meg lehet adni neki a BIOS által felismert lemezek listájabeli sorszámot is a kernel és initrd lokalizálására. Fontos látni, hogy nem evidencia az, hogy a bootloader arról a lemezről bootoljon kötelezően, melyről a BIOS/UEFI eredetileg betöltötte akár az MBR-t, akár a bootloadert.
Az fstab a bootloadertől független valami, a bootloader nem is foglalkozik vele, ezt már az adott operációs rendszer (esetünkben a Linux) olvassa fel a saját inicializációs folyamata során, ugyanis a bootloader nem csatolja fel a boot particiót, csak beletúr és előszedi a kernel-t és az initrd-t. Ez azért van így, mert a "felcsatolás" mint olyan, az - leegyszerűsítve - a Linux kernelben végremenő regisztrációs folyamat, viszont a boot folyamatnál a Linux kernel még egyáltalán nem egy üzemelő valami, hiszen azt épp most olvassuk fel a lemezről. De nem is szükséges a bootloaderhez a Linux kernel, mivel az önmagában egy önálló pici "operációs rendszer", bár erősen korlátozott tudással.
Amikor a bootloader betöltötte és elindította a Linux kernelt, a legtöbb esetben egy inicializációs szkript indul el, ami az fstab és más konfigurációs fájlok alapján összerakja a szoftveres (mdadm, dm-raid) RAID-eket, felcsatolja a megfelelő fájlrendszereket, és elindítja a különféle szolgáltatásokat.
Ami miatt fontos, hogy a fájlrendszerek meghivatkozása egységes módon történjen, az egyfelől a konfiguráció konzisztenciája, másfelől pedig az, hogy bizonyos, a bootloader és más cuccok frissítésekor lefutó userspace szoftverek az fstab alapján építik fel az fstab-tól amúgy független konfigurációjukat. Érdemes tehát UUID/LABEL alapon gondolkodni az eszközök megcímzésénél, mert ez függetlenné teszi a bootfolyamatot attól, hogy fizikailag hova dugod az adott lemezeszközt. Simán lehet, hogy portalanításkor kiveszed mindkét RAID diszket, de véletlenül fordított sorrendben teszed vissza őket, ha UUID vagy LABEL alapú elérést használsz az fstab-ban és a GRUB 2-ben is, akkor semmilyen problémád nem származik a bootoltatás során (amennyiben gondoskodva van arról, hogy BIOS esetén az MBR, EFI esetén pedig az EFI partíció tartalma fenn legyen mind a két diszken, EFI partició esetén a tartalomnak is meg kell egyeznie, viszont ez a partició NEM lehet szoftveres RAID tömbön, az eltérő particiótípus-azonosító flag miatt (szerencsére az EFI partíció tartalma alig változik a gép életciklusa során, elég egy scripttel napi szinten szinkronban tartani)).
--
Blog | @hron84
"valahol egy üzemeltetőmaci most mérgesen toppant a lábával" via @snq-