Live disztró OpenZFS támogatással?

Naplózó filerendszerek (journaling)

Debian+OpenZFS van a gépemen. Mi lenne, ha egy update elrontana valamit, vagy meghibásodás miatt nem bootolna a rendszer? Vannak snapshotok, de nem vagyok biztos benne, hogy initrd-ből sok mindenre jutnék vele, vagy akár maga az initrd is lehet döglött.

Jó lenne egy live disztró, amin van OpenZFS támogatás, viszonylag aktuális. Ki ismer ilyet? A kedvencem a SystemRescueCD, de az nem tudja. Inkább gyári megoldás kellene, de ha egyszerűen rá lehet faragni egy ZFS-t egy már kész live image-re, tehetek avval is egy próbát. Telepíthetnék egy full rendszert is pendrive-ra VM-ből, de az már végképp túl sok meló.

( tgerczei | 2018. 02. 20., k – 12:06 )

Van egy fearedbliss nickű fiatalember, aki publikál ZFS-enabled sysresccd image-eket, amiket elvileg a gyárilag beépített bővítési lehetőségeket felhasználva készít. Én ezeket használom.
------------------------
{0} ok boto
boto ?

( szilas | 2018. 02. 20., k – 15:26 )

Elvileg az olyan distrók amik alapból támogatják a zfs-on-linux-ot, ott van egy olyan lehetőség, hogy live módban indítod a telepítőt, nyitsz egy konzolt, és (debian alapúaknál):
$ sudo su
apt-add-repository universe # *ubuntuk esetén
apt update
apt install -y zfs-initramfs gdisk

innen már normál zfs parancsok mennek.

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

( denke v | 2018. 02. 20., k – 23:29 )

Az ubuntu a kovetkezot csinalja zfs root eseten, nagyon bolcs dolog, tudom javasolni:
-Letrehoz egy ef00 particiot (a /boot/efi ala van mountolva) amin ugye az efi van. Beleforditja az efi binarisba a zfs supportot is, de megfelelo modon konyvtarba is melle lehet tenni
-Letrehoz ugyanide egy grub config filet, ami csak egy redirectet csinal:

search.fs_uuid XXXXXXXXXXXXXXXX root hd0,gpt2.
set prefix=($root)'/ROOT@/boot/grub'
configfile $prefix/grub.cfg

(az uuid-t az efi console ls -l parancsaval kapod meg, nem egyezik meg a blkid altal adottakkal, nem jottem ra miert)

-A merevlemez tobbi resze egy zfs pool, itt letrehoz tovabbi dataseteket (filerendszer / particio nevezzuk ahogy akarjuk, amit a zfs create parancs letrehoz)
-az rpool/boot dataset fel van mountolva a /boot ala, ez ala teszi be az aktualis grub configot, initrd-t, kernelt, stb.

Ezzel a megoldassal az efi particion levo dolgok SOHA NEM FRISSULNEK, tehat a snapshot mind a rendszer, mind a grub config, mind a kernel mind az initrd egy oszetartozo allapotat tarolja. Ha megolod esetleg a rendszert es nem tudsz felbootolni, akkor inditasz egy grub console-t es read only modon fel tudod bootolni a rendszert egy snapshotbol, majd reverteled a mukodore, reboot es kesz.

set prefix=($root)'/ROOT@SNAPSHOTNAME/boot/grub' ...

Nagyon cool megoldast talaltak ki a sracok!!

Szia!

A tobbi cucc nelkul nincs a grub config snapshotolva, igy:
-a revert utan kezzel meg kell szerkesztened a grub configot a boot viszaszamlalast megallitva
-sikeres boot utan ujra kell generalnod a grub configot

A grub kepes rpool@wtf rol bootolni, (legalabbis nekem megtette) viszont ezt tamogatnia kell az initrd-nek is, hogy a switchroot jo helyre tortenjen , valamint a RO / -t is tamogatnod kell... Vagy az initrdol kell megoldanod a zfs revertet, majd a kovetkezo bootnal a fent leirtak

"A tobbi cucc nelkul nincs a grub config snapshotolva"

Ezt nem értem. Van a /boot/grub/efi, ami ugye egy FAT32 partíció és soha senki nem nyúl hozzá. Azon kívül a /-ben minden egyazon ZFS poolban van, /boot-ot beleértve. És erről van snapshot.

Grub, initrd természetesen támogatja a ZFS-t, anélkül most nem tudnék bootolni egyáltalán :).

Ahhoz hogy a grubtol ne csak egy shellt kapjal, hanem a megszokott menut, ahhoz kell mindenkeppen egy grub config file (azert nem grub.cfg-t irok, mert a config file helyet es nevet a grub install eseten kell megadni, es bele van forditva a grub efi binarisba, disronkent elterhet)

Namost, ennek a config allomanynak mindenkeppen ugyanazon az ef00 (efi boot) tipusu fat32 re formazott particion kell lennie, amin a grub is van.

A legtobb rendszer ezt ugy oldja meg, hogy siman odateszi a grub configot arra a particiora es kesz. Ez a megoldas egyszeru mint a szog, viszont mivel a zfsen kivul eso dolog, nincs is snapshotolva, tehat hiaba rollbackeled az rpool alatt a szukseges dataseteket, a grub config mindig a legfrisebb allapotot fogja tukrozni akkor is, ha a rollback miatt azok a kernelek / initrd-k mar nem elerhetoek.

Az ubuntu (nala lattam eddig egyedul) ezt ugy oldja meg, hogy csak egy redirectet tesz be ebbe a grub configba "Keresd meg ezen az uuid alatt talalhato zfs poolt, es annak a boot datasete alatt X eleresi uttal megtalalod a valodi configot, azt toltsd be" Ezt a kodot masoltam en be kicsit feljebb.

Ez egy lepessel ugyan komplikaltabb, viszont ha rollbackelsz, rollbackelodik a grub config is. Violia, egy konzisztens rendszer rendel!

Akkor most ujat tanultam, koszonom!

Viszont akkor mar kerdesem is lenne ehhez, mi alapjan talalja meg a grub a grub configot, honnan tudja melyik pool melyik dataset alatt kell keresnie? (ugye az rpool es az rpool/boot csak egy megszokas, nem vagy koteles igy elnevezni)
Ubuntu eseten ugye konkretan ezt mondja meg az efi particio alatt levo grub config. A te esetedben ez az informacio valahogy hardkodolva van a grubx64.efi binarisban (uuid vagy label) + dataset formaban?

/boot/grub/grub.cfg részlet: 


menuentry 'GNU/Linux' --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-8f9671a77bda9003' {
        load_video
        insmod gzio
        if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
        insmod part_gpt
        insmod zfs
        set root='hd0,gpt2'
        if [ x$feature_platform_search_hint = xy ]; then
          search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt2 --hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2  
8f9671a77bda9003
        else
          search --no-floppy --fs-uuid --set=root 8f9671a77bda9003
        fi
        echo    'Loading Linux 4.14.0-3-amd64 ...'
        linux   /@/boot/vmlinuz-4.14.0-3-amd64 root=ZFS=rpool ro  
        echo    'Loading initial ramdisk ...'
        initrd  /@/boot/initrd.img-4.14.0-3-amd64
}

Érdekes módon a /boot/efi/EFI/debian/grubx64.efi tartalmazza a "(,gpt2)/@/boot/grub" stringet, ami nem lehet véletlen, szerintem a telepítő beledrótozza, hogy mit hol keressen.

( uid_7086 | 2018. 02. 21., sze – 11:40 )

Kicsit off, de megkérdezhetem, mi okod volt rá, hogy OpenZFS-t használj rootként?
Engem pont az tart vissza az ilyesmitől, hogy mi lesz, ha...
(poén: nekem elsőre az ugrott be, hogy miért nincs kéznél egy Solaris Live ;) )

A zfs root pont azert nagyon erdekes, mert mi lesz ha ... konkretan a fent leirt megoldassal visza tudod hozni a rendszert 5 perc alatt egy elrontott frissites / tamadas / "rm -rf /" utan.

Nagyon jo dolog az is hogy megvan a "tegnapi" valtozat is az adataidbol, igy egy diff-el osze tudod hasonlitani azt is hogy mi valtozott tegnap ota....

Vagy esetleg ha egy oktatasi intezmeny vagy ahol a diakok minden nap szetbaltazzak a rendszert, akkor behuzod az initrd-t es kernelt snapshotbol es bele tudod irni az initrdbe azt is hogy zfs revert, es maris viszatertel egy tiszta allapotra

Illetve a backupolas is nagyon jo zfs eseten, csinalsz egy snapshotot es zfs send / zfs receive .... kizarolag a valtozasok mennek at, de az rsync overhead, atnyalazas, teljes file atvitele nelkul, konkretan block szinten
Kepzeld csak el ez egy sql szerver master-save resync eseten mennyire hasznos ... vagy csak siman orankent csinalsz egy teljes mentest az adatbazisokrol kizarolag a valtozasokat atvive, majdhogynem "effortless"

Ja meg a zfs mindig konzisztens ... ha kiteped a halozatbol a geped SOHA nem lesz serult filerendszer, stb max ha maga a hdd adja meg magat

Mert megspórolom az ext4 modul által foglalt rengeteg memóriát, a ZFS-nek kell minden :D.

Viccen kívül azért, mert a ZFS mindenre jó, rootnak is. Tehát hogy egyben van a volume management és a fájlrendszer, az adatkonzisztencia védelme, a snapshot támogatás, stb. És könnyen tudom a rendszert backupolni zfs send-del. És könnyen le tudok választani dolgokat a snapshotból, pl. /var/log-t külön datasetbe teszem. Ez LVM/EXT4 esetén mind bonyolultabb egy fokkal, illetve ha már a nagy tárhely alatt ZFS van, fölösleges overhead lenne egy rendszeren kétféle megoldást használni.

Poén... de jó tisztázni, ha valaki nem tudná, a solaris, és bizonyos solaris fork-ok, azok a Solaris ZFS-ét támogatják, ami nem ugyanaz mint az OpenZFS, amit a FreeBSD, Linux, stb támogat, illetve újabban az OpenIndiana és annak forkjai.
Az Oracle Solaris jelenleg 37-es Zpool verziónál tart, míg az openzfs-re épülő projektek a 5000 Zpool verziót használnak, és nem a zpool verzió emelésével jelzik a fejlődést, hanem feature flag-ekkel.
Tehát előfordulhat, hogy egy standard solaris live cd nem kezeli egyáltalán, vagy nem kezeli rendesen az OpenZFS-re épülő ZFS-t, tehát vigyázni kell.
Illetve valószínű fordítva is igaz lehet, mivel az utolsó OpenSolaris 22-es Zpool verziót támogatott és nem biztos, sőt valószínűtlen, hogy az OpenZFS implementálta volna a 22-37 Zpool verziók közötti különbségeket, úgy, hogy teljesen kompatibilis maradjon az Oracle ZFS-el.
RO módban meg lehet kockáztatni az átjárást, de RW-ban már gondok lehetnek.

Ezzel csinálom a live cuccaim, ráadásul ha megcsinálsz egy ISO-t (pl. mert lefrissíted a csomag készletet plusz hozzáadsz párat), akkor azt újra beadagolhatod neki.

Debian-hoz is lehet szerintem live-ot csinálni, ha azt használsz, akkor én utánanéznék a helyedben hogy minél jobban stimmeljenek a verziók az éles rendszer és a live között.