Migrace systému: bootovací proces

24. 4. 2012 | Max Devaine | Návody | 6041×

Dnes se podíváme, jak co funguje při bootování systému a jak provést migraci systému na jiný disk.

Abychom uměli správně zmigrovat systém, tak potřebujeme vědět alespoň nějakou minimální teorii o tom, jak funguje bootování v systému. Budou nás zajímat jen ty nejhlavnější věci. Neztrácejme čas a hrr do toho.

Obsah

• Bootovací proces
  • MBR (Master Boot Record) a boot loader (zavaděč)
• GRUB
• Označení oddílů
  • LABEL
  • UUID
  • Další unikátní pojmenování
  • Který identifikátor používat?
• Jak tedy probíhá bootování?
• Závěr

Bootovací proces

Po zapnutí PC BIOS provede základní detekci a případně diagnostku hardware. V BIOSu máme nastaveno, z jakého zařízení se má uskutečnit bootování.

MBR (Master Boot Record) a boot loader (zavaděč)

BIOS se postará o zavedení boot sektoru, ve kterém je umístěn boot manager, jeho část, nebo jen odkaz na nějakou část disku, kde je zbytek boot manageru s velkou spoustou voleb a různých vychytávek. Mezi nejpoužívanější a nejznámější boot managery patři stařičké lilo, novější GRUB (nyní GRUB legacy), nejnovější GRUB 2 a minimalistický syslinux. Syslinux se spíše zaměřuje na bootování z různých medií, např. i flash disků. Lilo je už hodně staré, ale občas se ještě objeví nějaká aktualizace. Nejpoužívanější je v současné době asi GRUB (neboli grub1, či GRUB 0.9), proto se konfiguračně zaměříme na něj.

GRUB

GRUB funguje tak, že je rozdělen do několika částí (stages):

stage1:
- jedná se o spouštěcí část, jenž je umístěna v mbr a stará se o zavedení stage2, což je kód (soubory) umístěný v /boot/grub/

stage1.5:
- jelikož stage2 se nachází na souborovém systému a stage1 je malý na to, aby se do něj vešel nějaký základní ovladač proc práci se souborovým systémem, tak se musí zavést ještě stage1.5, ten je umístěn mezi začátkem disku LBA0(MBR) a začátkem první partition LBA63.

stage2:
- v této fázi se už načítá vlastní kod grub umístěný v /boot/grub včetně konfiguračního souboru /boot/grub/menu.lst, s daty se již díky stage1.5 pracuje na úrovni souborového systému, tudíž nezáleží na tom, na kterých sektorech jsou přesně uloženy a můžeme je upravovat, aniž bychom potřebovali volat nějaký update jako třeba u lila.

Toto platí pro MBR, kdo používá GPT, tak tam LBA0 leží ladem a LBA1-33 obsahuje tabulku GPT. V takovém případě tedy není nikde místo pro stage1.5, který by umožnil práci s file systémem.
Můžeme si vytvořit „BIOS Boot partition„, která by sloužila pro uložení stage1.5, tato partition by měla mít flag “bios_grub".
Dobrý popis je třeba v článku u kolegů na Rootu: Na disky větší než 2 TB s GPT

Označení oddílů

V konfiguračním souboru grubu je definováno, z jaké partition se má načítat jádro, kde je root (/) oddíl apod.

Dříve se SATA disky označovaly /dev/sdx (sda,sdb apod.) a PATA disky /dev/hdx (hda, hdb apod.). Od nějaké verze jádra 2.6.2x se i pro PATA disky začal používat libata, takže se nyní všechny (PATA, SATA, USB) disky označují /dev/sdx. Od toho se pak odvíjí pojmenování a očíslování partition jako /dev/sda1, /dev/sda2, /dev/sdb1 apod. V konfiguračních souborech se pak uváděly cesty k těmto diskům/partition.

Část konfiguračního souboru grub, která definuje jednu položku v menu, může vypadat takto:

# (0) Arch GNU/Linux                               # komentář v grubu
title  Arch GNU/Linux                              # jméno položky v grubu
root   (hd0,0)                                     # na jakém disku a partition se nachází kernel apod.
kernel /boot/vmlinuz26 root=/dev/sda1 ro vga=795   # kernel, definice root oddílu, připojin jen pro čtení, rozlišení obrazovky
initrd /boot/kernel26.img                          # initrd

root (hd0,0): říká, na jakém disku a na jaké partiton se nachází jádro a příslušné položky nutné pro boot. Označení disků není úplně tak přesně podle pořadí. „hd0“ je vždy disk, ze kterého se provádí boot (načítá se grub). Disk tedy můžeme na řadiči přehazovat jak je libo, ale pokud vždy v biosu zvolíme boot ze správného disku, tak se vždy dobře načte.
root=/dev/sda1: je zase definice root oddílu.
/boot/kernel26.img: v dnešní době jsou moduly/ovladače řadičů a filesystemů apod. obsaženy ve většině distribucí v initrd. Nejsou tedy zakompilovány přímo v jádře. Aby systém mohl nabootovat, tak se musí načíst initrd, který načte do paměti veškeré potřebné moduly a jádro pak uvidí disky, oddíly, rozpozná systém souborů atd. Do initrd se jen necpou moduly, ale v dnešní době i třeba takový udev. Součástí initrd jsou i skripty a další různé pomocné drobnosti, které se starají o sofistikovanější načítání.

Potom, co si to GRUB vyjasní, si to ještě musí vyjasnit /etc/fstab, který se stará o definici připojení jednotlivých partition.

# 
# /etc/fstab: static file system information
#
# <file system> <dir>    <type>   <options>    <dump> <pass>
devpts         /dev/pts  devpts    defaults        0      0
shm            /dev/shm  tmpfs     nodev,nosuid    0      0
/dev/sda1      /         ext3      defaults        0      1
/dev/sda2      /home     reiserfs  defaults        0      0
/dev/sda3      swap      swap      defaults        0      0

Identifikovat disk/partition takovýmto označením není příliš šťastné. Toto označení je dynamické a závisí na tom, jak jsou disky za sebou zapojeny a na jakém řadiči se nacházejí.

LABEL

Tento problém částečně řeší LABEL, což je popisek u filesystému. Podle druhu filesystému můžeme přiřazovat zcela libovolné popisky. Dost často se LABEL pojmenovává stejně jako přípojný bod (ale název si můžete zvolit jakýkoliv). Tzn., že v našem případě se sda1 přiřadí popiska root oddílu /, sda2 popiska home /home a sda3 popiska swap:

# ext2/3:
e2label /dev/sda1 /
# reiserfs:
reiserfstune --label /home /dev/sda2
# swap:
mkswap -L swap /dev/sda3

Zápis v GRUBu by pak vypadal takto:

# (0) Arch GNU/Linux
title  Arch GNU/Linux
root   (hd0,0)
kernel /boot/vmlinuz26 root=LABEL=/ ro vga=795
initrd /boot/kernel26.img

A následný zápis ve fstab takto:

# 
# /etc/fstab: static file system information
#
# <file system> <dir>    <type>   <options>    <dump> <pass>
devpts         /dev/pts  devpts    defaults        0      0
shm            /dev/shm  tmpfs     nodev,nosuid    0      0
LABEL=/        /         ext3      defaults        0      1
LABEL=/home    /home     reiserfs  defaults        0      0
LABEL=swap     swap      swap      defaults        0      0

Manipulace s LABEL je jednoduchá, názvy zapamatovatelné, ale jak jistě nemálo lidí napadlo, i toto není zcela ideální řešení. Můžeme přenést disk do jiného pc, kde bude další disk s některými shodnými popisky a začínají problémy. Z těchto důvodů je dobré, nevymýšlet obecné názvy, ale nějaké vlastní, unikátní. V příkladu jsem tedy uvedl ty nejhorší možné popisky, jaké jsem jen mohl .

UUID

Dalším řešením, jak pracovat s oddíly jednotlivých disků, je UUID (Universally Unique Identifier). UUID je náhodně generované číslo, které je přiřazeno k souborovému systému a zprostředkovaně i k oddílu. UUID lze vypsat pomocí příkazu „blkid“, který bývá součástí balíčku „util-linux“ nebo „e2fsprogs“.

Kernel UUID nerozumí (stejně jako LABELu), tudíž skripty v initrd se postarají o to, aby se UUID převedlo na správný název disku, které již jádru šmakují. Jeho jedinečnost je garantována v rámci stroje, na kterém je generováno. Za úplňku v kooperaci letící vážky a dalších okolností lze tedy teoreticky narazit na stejný UUID na jiném systému. Není to tedy také úplně 100% unikátní pojmenování jako s LABEL.

Příklad výpisu blkid:

/dev/sda1: UUID="14640e9e-d1c3-0960-5b02-06071eecbc2b" TYPE="ext3" 
/dev/sda2: UUID="b35303fe-6ece-491b-8661-ded90e2f0bf8" TYPE="reiserfs"
/dev/sda3: UUID="ac7b118b-f394-46bb-8a1d-458ae32b9e38" TYPE="swap"

Nastavení grubu pak bude vypadat takto:

# (0) Arch GNU/Linux
title  Arch GNU/Linux
root   (hd0,0)
kernel /boot/vmlinuz26 root=UUID=14640e9e-d1c3-0960-5b02-06071eecbc2b ro vga=795
initrd /boot/kernel26.img

A následný zápis ve fstab takto:

# 
# /etc/fstab: static file system information
#
# <file system>                               <dir>    <type>   <options>    <dump> <pass>
devpts                                       /dev/pts  devpts    defaults        0      0
shm                                          /dev/shm  tmpfs     nodev,nosuid    0      0
UUID=14640e9e-d1c3-0960-5b02-06071eecbc2b    /         ext3      defaults        0      1
UUID=b35303fe-6ece-491b-8661-ded90e2f0bf8    /home     reiserfs  defaults        0      0
UUID=ac7b118b-f394-46bb-8a1d-458ae32b9e38    swap      swap      defaults        0      0

Další unikátní pojmenování

V těchto /dev/disk/by* adresářích lze vidět, jak všelijak lze identifikovat oddíl/systém souborů:

/dev/disk/by-id/
/dev/disk/by-label/
/dev/disk/by-path/
/dev/disk/by-uuid/

"by-label" a „by-uuid“ již známe. Poté zde máme „by-path“, což je definice dle cesty k řadiči následně velice zajímavý „by-id“, což je definice typu disku a jeho seriového čísla. Toto by se tedy dalo považovat asi za nejunikátnější řešení. Příklad výpisu ls -l /dev/disk/by-id/:

ata-ASUS_DRW-1604P -> ../../sr0
ata-WDC_WD1502FAEX-007BA0_WD-WMAY02414063 -> ../../sda
ata-WDC_WD1502FAEX-007BA0_WD-WMAY02414063-part1 -> ../../sda1
ata-WDC_WD1502FAEX-007BA0_WD-WMAY02414063-part2 -> ../../sda2
ata-WDC_WD1502FAEX-007BA0_WD-WMAY02414063-part3 -> ../../sda3
ata-WDC_WD1502FAEX-007BA0_WD-WMAY02414063-part4 -> ../../sda4
ata-WDC_WD1502FAEX-007BA0_WD-WMAY02414063-part5 -> ../../sda5
ata-WDC_WD1502FAEX-007BA0_WD-WMAY0241406

Takže třeba do fstab můžeme zapsat cestu k root oddílu takto:

# <file system>                                                 <dir>    <type>   <options>  <dump> <pass>
/dev/disk/by-id/ata-WDC_WD1502FAEX-007BA0_WD-WMAY02414063-part1   /       ext3    defaults    0      1

Který identifikátor používat?

Podle mně to je jedno. Nejvíce se používají LABEL a UUID. by-id je sice pěkné, ale na druhou stranu, někdy nemá zas tak moc smysl vázat software na konkrétní hardware, protože oproti LABEL nebo UUID se by-id váže na hardware (tedy konkrétní fyzický disk).

Já osobně dávám přednost UUID. Při instalacích je již vygenerován, nemusím nic vymýšlet, nemusím složitě nic popisovat, jen udělám copy-paste do fstab a menu.lst (grubu) a hotovo.

Jak tedy probíhá bootování?

Z dnešního povídání bychom si mohli odnést tři drobnosti:

1) lehčí schema a pochopení bootu:

Bios -> HDD-> LBA0 [grub stage1]
-> LBA1-62 [grub stage1.5]
-> grub stage2 [ /boot/grub/menu.lst = ... root(hd0,0) ... root=UUID=....]
-> kernel -> rozbalení initramfs
-> skripty, jenž převedou UUID do čitelného názvu pro kernel
-> kernel připojí fs v ro režimu -> spouští inittab
-> udev -> generování /dev/ zařízení
-> zpracování fstab + remount / do rw režimu
-> dále se zpracovávají init scripty ...

2) Dále víme, že si musíme hlídat, jaké ovladače máme v initrd

3) V poslední řadě je třeba dávat si pozor, jak máme pojmenované disky v nastavení GRUBu /boot/grub/menu.lst a v /etc/fstab

Závěr

Snad to bylo pro většinu dosti srozumitelné. Příště se podíváme na různé druhy migrace systému, výhody, nevýhody a zkušenosti. Taktéž nás čekají nějaké nejnovější informace o linuxovém RAIDu (novinky poslední doby a praxe).

A aby to bylo kompletní, tak ještě odkáži na jeden pěkný blog zde na ábíčku: UEFI nabootuje kernel bez GRUBu/LILO

       

Komentáře

[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.