Migrace systému: bootovací proces (diskuse)

[Josef]

Dobrý den. Dle mých zkušeností není UUID úplně optimální. Jak řešíte když je UUID zapsáno v initrd ? Respektive jak initrd přegenerujete, když nemáte po ruce funkční systém se stejným jádrem? Zatím jsem si na tom několikrát úspěšně vylámal zuby. děkuji

[xkucf03]

Jedna možnost je nastavit novému disku/oddílu původní UUID. Např. když starý disk odejde a obnovuji ze zálohy – nebo i jindy, ale pak musím změnit UUID i na starém disku, aby se mi náhodou nesešla stejná ID v jednom systému.

[Jendа]

Moje distribuce (Debian) nevyžaduje k vygenerování initrd stejné jádro. Co to je za distro?

[Max]

Mohl bych poprosit o nějaký příklad problému (zřejmě jsem méně chápavý :-/ )?
Protože initrd neobsahuje UUID, jen skripty, které ho zjistí a překlopý na klasický /dev/sdx, kterému jádro rozumí, přesně jak tady uvádí "petr_p". Nějaké info třeba i na gentoo wiki : UUID/LABEL Root Mounting

Pokud si tedy vygeneruji nové UUID u root partition, tak stačí zanést nové UUID do fstab a menu.lst, není třeba přegenerovávat initrd a systém normálně naběhne.

Generování initrd nemá s běžícím jádrem moc společného. Prostě se jen zkopírují požadované moduly z požadovaného jádra + skripty a drobnosti okolo a to celé se zabalí do souboru. V archu třeba takto :

mkinitcpio -k 3.2.12-1-ARCH -g /boot/initramfs-linux.img

Díky
Zdar Max

[Jindřich Makovička]

Přesně tak... osobně používám následující skriptík pro zálohování root partition tak, aby byla i záloha bootovatelná a prozatím to funguje :)

VERB="-q"

get_uuid() {
    sed -ne "\%^UUID=[-0-9a-f]\+\s\+$1\s%s/UUID=\([-0-9a-f]\+\)\s.*/\\1/p" < /etc/fstab
}

# backup root partition
backup_root() {
    DEST=$1

    if grep -q $DEST /proc/mounts ; then : ; else
        echo "Backup patition $DEST not mounted"
        exit 1
    fi

    rsync $VERB -x -a --inplace --delete --delete-excluded --exclude-from /rsync-exclude / "$DEST"

    ROOT_UUID=`get_uuid /`
    BACKUP_ROOT_UUID=`get_uuid "$DEST"`

    # replace root partition in backup fstab, comment out backup root and swap
    sed -e "
s%^UUID=$ROOT_UUID%UUID=$BACKUP_ROOT_UUID%
t
s%\(UUID=$BACKUP_ROOT_UUID.*\)%\#\\1%
t
s%\([^\#].*\sswap\s.*\)%\#\\1%
t
" < "$DEST"/etc/fstab > "$DEST"/etc/fstab.edited

    mv "$DEST"/etc/fstab.edited "$DEST"/etc/fstab

    sed -e "
s%$ROOT_UUID%$BACKUP_ROOT_UUID%
t
" < "$DEST"/boot/grub/grub.cfg > "$DEST"/boot/grub/grub.cfg.edited

    mv "$DEST"/boot/grub/grub.cfg.edited "$DEST"/boot/grub/grub.cfg
}

backup_root /mnt/root-backup

[pavlix]

Dobrý den. Dle mých zkušeností není UUID úplně optimální. Jak řešíte když je UUID zapsáno v initrd ? Respektive jak initrd přegenerujete, když nemáte po ruce funkční systém se stejným jádrem? Zatím jsem si na tom několikrát úspěšně vylámal zuby. děkuji

Já tak úplně netuším v čem je problém, ani jsem na něj nikdy nenarazil.

[petr_p]

Z článku by jeden mohl nabýt dojmu, že jádro jmenovkám souborových systémů rozumí. Není tomu tak, je na tom úplně stejně jako s UUID. Pokud tedy použijete zápis LABEL= v jaderném parametru root, musí se o překlad postarat initramdisk. Obvykle tak, že prozkoumá /proc/cmdline a kořenový systém připojí programem mount, kterýžto samotný jmenovku (nebo UUID) přeloží na symbolický jaderný název (/dev/sdXN).

[Max]

Díky za upozornění, všiml jsem si toho a říkal si, že to nějak líp zformuluji a zapomněl jsem nato. Nechávám provést korekturu :).
Zdar Max

[petr_p]

Jedinečnost UUID pokazí nejen fáze Měsíce, ale také snímek souborového systému nebo jeho prostá kopie (například záloha). Z tohoto důvodu dávám přednost sériovým číslům disků.

[xkucf03]

snímek souborového systému

Tohle se mi jednou vymstilo – systém pak po restartu nabootoval ze snapshotu místo z původního oddílu, docela průšvih… UUID je potřeba změnit resp. udržovat jedinečné.

[BigWrigley]

Zdravim, to je zajimave, take jsem se spalil pri pouziti kopie. Pouzivate nekdo WWN? Viz napr.

Emil-II:~# ll /dev/disk/by-id/ | grep wwn
lrwxrwxrwx 1 root root  9 Apr 24 20:24 wwn-0x50014ee0571cb58b -> ../../sdb
lrwxrwxrwx 1 root root 10 Apr 24 20:24 wwn-0x50014ee0571cb58b-part1 -> ../../sdb1
lrwxrwxrwx 1 root root  9 Apr 24 20:24 wwn-0x50014ee057e7e8e6 -> ../../sdc
lrwxrwxrwx 1 root root 10 Apr 24 20:24 wwn-0x50014ee057e7e8e6-part1 -> ../../sdc1
lrwxrwxrwx 1 root root  9 Apr 24 20:24 wwn-0x5e83a97f52f3f9cc -> ../../sda
lrwxrwxrwx 1 root root 10 Apr 24 20:24 wwn-0x5e83a97f52f3f9cc-part1 -> ../../sda1
lrwxrwxrwx 1 root root 10 Apr 24 20:24 wwn-0x5e83a97f52f3f9cc-part2 -> ../../sda2
lrwxrwxrwx 1 root root 10 Apr 24 20:24 wwn-0x5e83a97f52f3f9cc-part3 -> ../../sda3
lrwxrwxrwx 1 root root 10 Apr 24 20:24 wwn-0x5e83a97f52f3f9cc-part5 -> ../../sda5
lrwxrwxrwx 1 root root 10 Apr 24 20:24 wwn-0x5e83a97f52f3f9cc-part6 -> ../../sda6
Emil-II:~# 

[Martin]

Příklad výpisu:

Výpisu čeho (jakého programu)?

Věnovat se GRUBU Legacy je škoda. Jednak začíná být obsolete, druhak o něm už toho bylo napsáno moc a bylo by lepší popsat GRUB 2.

[Max]

Díky za upozornění, nechávám doplnit info.
Nemyslím si, že v době, kdy nemálo lidí používá lilo, by měl být grub legacy obsolete. Ještě tu s námi bude dosti dlouho a nemálo lidí neví, jak ve skutečnosti funguje.
O Grubu2 možná také padne nějaké slovo (v nějakém tom pokračování).
Zdar Max

[Luboš Doležel (Doli)]

GRUB2 jsem docela dobře popsal ve svém článku.

[the.max]

to sice ano, ale 'legacy' grub mi prijde PODSTATNE jednodussi na konfiguraci a tak dokud to bude mozne, budu ho pouzivat.

[tomo_tn]

Plne chapem - ja osobne pouzivam lilo pride mi na konfiguraciu najjednoduchsie, asi to bude tym ze ju dobre poznam...

Kernel to zevedie tak naco riesit nieco novsie?

[AsciiWolf]

+1

V "archaických časech" jsem LILO rovněž používal a pamatuji si, že následný přechod na GRUB mi přinesl více nevýhod, než-li výhod...

[ukos]

+1

Ano, vzpomínám, přechod na GRUB z LILA mi také žádnou výhodu nepřinesl. Ale násilný přechod z GRUBU na GRUB2 ve fedoře je ještě horší. Přinesl mi jen příšerné problémy s velikostí zaváděče a šílenou konfigurací. Jediná výhoda GRUBu2 je tapeta v plném rozlišení monitoru, která problikne zlomek vteřiny, než se začne natahovat ten jeden kernel, který v počítači je.

[Max]

Ze začátku jsem se přechodu z lila na grub taktéž bránil a říkal si, že to nebude mít žádný přínos, ale to je omyl. Editace nabídky a další vyfikundace, to se vždy hodilo a nemálokrát jsem to použil.
U grubu2 také nějaký malý přínos vidím, ale zároveň i nějaké překážky, třeba snahu věci automatizovat skriptama :-/.
Zdar Max

[xicht]

Pred mnoha lety jsem prechazel na grub a jednu vyhodu to melo. Editace parametru grubu bez nutnosti chrootu.

[Kvakor]

To není třeba, lilo se umí chrootnou samo (parametr -r), zmatek může být jenom v tom, jak se jmenují zařízení v /dev a jak vypadají oblasti disků v /proc (ale jejich absenci lilo skousne).

PS: Když to srovnám s ostatními zavaděči Linuxu na ne-PC platformách, kde stačí většinou jen připravit jádro v učitém formátu a pak ho nahrát do první oblast bootovacího média, tak je i lilo složité

[the.max]

lilo jsem pouzival take hodne dlouho, ale dost casto jsem zapominal pri aktualziaci jadra ho spustit, to nastesti grub resi

[pavel]

Myslíš tím, že musím zadat "update-grub" pro grub2 místo "lilo" pro lilo?

[Lol Phirae]

Ne, nemyslí; když nezavoláš update-grub, tak se stane prdlajz, když nezavoláš lilo, tak už ti po rebootu nenaběhne.

[Max]

update-grub dynamicky vygeneruje nový menu.lst pomocí skriptů. Když se vygeneruje špatně, tak to nevadí, protože je vždy možnost editace grubu přímo z menu.
lilo rovnou zapisuje do mbr. Pokud tam zapíše něco špatně, tak finito, žádná spása, jedině livecd a chroot + oprava.
Další věcí je, že update-grub je jen taková zbytečná "klikačka". Menu si můžeš psát ručně, stejně jako u starého grubu, ale většina distribucí na to má právě skripty, které se po aktualizaci spouštějí / aktualizují apod. a následně ti přepíšou tvé ruční nastavení.
Zdar Max

[ukos]

ten grubovský shell je samozřejmě výhoda oproti lilu, ale zase ne taková, aby to vždy stálo za to. Když se něco podělá na zavádění systému s grubem, tak má běžný Franta sice teoretickou možnost spustit si druhém počítači Googla a začít se učit, jak se s tím Airbusem, pardon grubem, vlastně lítá - nebo vrazit do mechaniky záchranné CD. Takže v praxi to skončí (opakovaná vlastní zkušenost) stejně jako s tím lilem. Akorát to zabere více času.

Na okraj: Grub mi ani tak nevadí, vadí mi, že pokud chci používat nějakou moderní distribuci, nemám možnost volby. Např. bych rád poslední Fedoru, ale bez zbytečností typu GRUB2-Plymouth-NetworkManager a polofunkčních experimentů typu systemd. Tedy na nonstop běžící wired desktop PC takhle, ale třeba na notebook i s těmi fancy krávovinami a Network Managerem. Bohužel Fedoří spiny jsou zaměřené pouze na volbu aplikací, nikoliv na konfiguraci systému.

[xkucf03]

jak se s tím Airbusem, pardon grubem, vlastně lítá

Úplně pro BFU to sice není, ale vzhledem k tomu, že tam funguje doplňování tabulátorem, tak se dá i s celkem minimálními znalostmi nabootovat, ten GRUB ti hodně pomáhá.

Grub mi ani tak nevadí, vadí mi, že pokud chci používat nějakou moderní distribuci, nemám možnost volby.

Nevím, jestli je moje distribuce dostatečně moderní, ale někde jsem tam viděl volbu "pokračovat bez zavaděče" -- a pak tě to nijak neomezuje a ten systém si nabootuj, jak chceš -- někdo třeba bootuje v KVM přímo jádro bez zavaděče, někdo si tam dá LILO...

[Kvakor]

Starší jádra měla speciální cíl bzlilo, kde se obraz jádra (pojmenovaný vmlinuz) s případným initramdiskem překopíroval do /boot (nebo do / a symlinknul do /boot) a pak se zavolalo lilo. Dnes to jde teoreticky rešit přes cíl install a skript /bin/installkernel, který to automaticky spustí po překladu.

Takže pokud si často překládáte jádro, stačí si připravit tento skript a make spouštět s parametrem install.

[Ondrej 'SanTiago' Zajicek]

Tohle me vzdycky trochu iritovalo. Mame asi pet metod, jak specifikovat root filesystem, zadna z nich neni moc spolehliva[*] a za nejakych okolnosti muze selhat, vetsina z nich navic vyzaduje specificke userspace nastroje ci konfiguraci.

Pritom existuje trivialni specifikace, co se v prevazne vetsine pripadu od systemu pozaduje - za root zvolit partition na tom disku, z ktereho zavadec natahl jadro. Nevim teda, jak a zda vubec by to slo rozumne implementovat v jadre (ci zda to nahodou uz nekdo dokonce neimplementoval).

[*] snad s vyjimkou absolutni adresace zarizeni typu cesta_na_PCI/abs. pozice na ATA ci SCSI, ktera se ale moc nepouziva.

[Kvakor]

Já to mám vyřešené tak, že mám různé disky připojené k různým řadičům (protože mám na desce PATA v chipsetu, SATA v chipsetu a ještě jeden SATA bokem), ale jen ten, na kterém je /, má ovladač v jádře. Protože nepoužívám initramdisk/initramfs, tak jádro před pokusem o jeho přijení vidí jen jediný disk a tudíž se nemůže poplést. Bohužel to u nových desek, kde je jen jediný SATA řadič, nejde použít.

[Max]

To ale také není 100% řešení, jelikož root nemusím mít nutně tam, kde mám jádro.
Zdar Max

[Ondrej 'SanTiago' Zajicek]

Jiste, ale to je trochu neco jineho - pokud uz chci takovou konfiguraci, tak to je mimo moznosti teto metody a proste pouziju jinou metodu. Oproti tomu ty stavajici metody proste selhavaji pri specifickych kombinacich externich okolnosti (napr. pozdeji pripojim dalsi sekundarni harddisk, ktery ma shodou okolnosti fs se stejnym labelem).

[petr_p]

Ve světě PC BIOS umí sdělit, ze kterého zařízení se bootovalo. Spolehlivě to ale funguje jen při bootu z ATA. LILO si dokonce při instalaci stěžuje, když se jej pokusíte nainstalovat do MBR jiného disku. Mám pocit, že UEFI je v tomto ještě lepší.

Údaj o bootu je ale k ničemu, když kořenový systém je ve virtuálním zařízení (například LVM). Pak se stejně musí použít nějaké umělé číslování.

[Mrkva]

za root zvolit partition na tom disku, z ktereho zavadec natahl jadro.

Ale jakou partition?

[pavlix]

Hint: Jsou očíslované.

[Mrkva]

Jasně, ale to bude jádro zkoušet bootvat z první, z druhé, ze třetí.... a bude doufat, že tam někde bude root (a že narazí na ten správný)?

[pavlix]

Tak čistě teoreticky by to číslo mohlo být za běhu systému známé. Ale jak říkal ondra, je X způsobů, každý má svoje výhody a nevýhody.

[Ondrej 'SanTiago' Zajicek]

Napadaji mne dve moznosti: bud by se pouzila ta sama partition, z ktere se natahlo jadro (nevim, jak standardni bootovaci protokol, ale treba multiboot tuhle informaci snad predava), nebo by proste partition v ramci bootovaciho device byla nakonfigurovana jako cmdline argument jadru (napr. root=/dev/boot3), preci jen cisla partitions v ramci jednoho zarizeni jsou podstatne stabilnejsi nez samotne identifikatory blokovych zarizeni.

[Grunt]

za root zvolit partition na tom disku, z ktereho zavadec natahl jadro

A o tom má jádro rozhodnout jako jak? Jádro je spustitelný blok kódu, který někdo (zavaděč) natáhne do paměti a spustí/nastartuje instrukcí JMP (V podstatě je to úplně obyčejný program akorát v reálném módu s exkluzivním během — teda ještě ho nikdo neplánuje, plánuje se samo, ale až na pár takových drobností je to úplně obyčejný ELF). Jádro neví nic o tom jak to vypadalo v systému před tím než bylo spuštěno. Samo si detekuje periferní zařízení na stroji na kterém bylo spuštěno a až má práci hotovou, tak je postaveno před nelehký úkol: Určit jak pokračovat. Většinou se to dělá tak, že pokračování nechá na Early User-Space a ten si dělá co chce (ten musí být v systému vždycky) a nech si pokračuje jak chce ten kdo si ho napsal. Disky a pole a takové věci jsou specifikum architektury x86. Na jiných architekturách může jádro klidně ležet pouze jako blok RAW-dat od adresy X do adresy Y na nějakém zařízení (to nemusí být ani disk), jiný systém ho natáhne do paměti a spustí jako běžný ELF (a nemusí to být ani jiná architektura — DOS-Grub pamatuje kdo?). Jak by mělo rozhodnout v takovém případě? Jádro se nepoužívá jen na Hi-Tech serverech s polema a loukama, ale jádro musí zůstat univerzální.

[Ondrej 'SanTiago' Zajicek]

A o tom má jádro rozhodnout jako jak? Jádro je spustitelný blok kódu, který někdo (zavaděč) natáhne do paměti a spustí/nastartuje instrukcí JMP (V podstatě je to úplně obyčejný program akorát v reálném módu s exkluzivním během — teda ještě ho nikdo neplánuje, plánuje se samo, ale až na pár takových drobností je to úplně obyčejný ELF). Jádro neví nic o tom jak to vypadalo v systému před tím než bylo spuštěno.

To je otazka boot protokolu mezi zavadecem a jadrem. Treba Multiboot predava informaci o disku a partition (i kdyz ve forme jeho BIOS identifikatoru, takze by mozna nebylo jednoduche z nej zjistit skutecny disk). Standardni linuxovy x86 boot protokol to asi (jak ted koukam) nepredava. Jak je to u jinych boot protokolu (treba OFI, UEFI) netusim, ale prekvapilo by mne, kdyby to tam nebylo.

Disky a pole a takové věci jsou specifikum architektury x86.

No a? VGAcon je take vicemene x86 specifikum, a presto se defaultne hojne pouziva.