Jak funguje a jak nastavit bootování aneb GRUB 1, 2, MBR, UEFI

GRUB

Při startu počítače je potřeba nějak dostat do paměti linuxové jádro a initramdisk, předat mu parametry a spustit ho. Existuje na to mnoho způsobů, které tu zmíním pro úplnost, zabývat se jimi dnes nebudeme:

• Přímý boot z diskety (již nepodporováno)
• Natažení z jiného operačního systému: loadlin pro DOS/Windows 95/98/ME – natáhne jádro ze souboru na disku a spustí ho
• Natažení z Linuxu: kexec – natáhne jádro ze souboru na disku a spustí ho
• Natažení přímo z „BIOS“ flashky na základní desce
• Natažení firmwarem jako EFI payload (to si vysvětlíme později v tomto článku)
• Natažení pomocí nějakého zavaděče který se už dneska příliš nepoužívá, například LILO nebo rodina SYSLINUX
• Na non-x86 architekturách natažení pomocí uBootu nebo nějakého proprietárního zavaděče

Dnes se v naprosté většině případů používá zavaděč GRUB. Dalo by se říct, že je to v podstatě celý „operační systém“ obsahující konzoli a grafický výstup, ovladače RAIDu, LVM, ovladače všech možných souborových systémů (takže může linuxové jádro natáhnout v podstatě odkudkoli), USB sériových portů, na kterých může jeho konzole běžet, a obsahující pokročilé funkce jako „pokud se nepodařilo nabootovat výchozí operační systém, spusť automaticky záložní“ (viz například příkaz grub-reboot). Nám pak zobrazí menu a případně konzoli, kde se dá zvolit, co a jak budeme bootovat.

Existují dvě verze zavaděče GRUB. Ta starší byla v distribucích ve výchozím stavu používána zhruba do roku 2010 a říká se jí GRUB 1, GRUB 0.99 nebo grub-legacy. Ta nová se jmenuje GRUB 2.

Následně budu vždy popisovat i jak věci fungovaly v GRUBu 1, i když se může zdát, že je zbytečné zabývat se něčím, co se již přes 10 let nepoužívá. Stále se totiž občas setkávám s jistým zmatením a nepochopením ohledně způsobů konfigurace GRUBu 1 a 2. Doufám, že uvedení historického kontextu pomůže věci vyjasnit. Popis se bude vztahovat na Debian, ale pokud vím, tak ostatní distribuce to mají většinou stejné.

GRUB – konfigurace

Pokud GRUB jen tak spustíte, zobrazí příkazový řádek a musíte mu ručně říct, co má udělat (najít jádro, nahrát ho do paměti a spustit). To je samozřejmě nepraktické dělat při každém spuštění počítače, proto existuje konfigurační soubor, ve kterém jsou v podstatě napsané příkazy, které se mají provést, a následně je v něm definováno známé menu s položkami co se mají bootovat a mezi kterými si můžete vybrat.

GRUB 1 – příklad konfiguračního souboru

Konfigurace pro GRUB 1 sídlí v souboru /boot/grub/menu.lst. Takhle vypadá jednoduchý konfigurák a opravdu to bootuje nejnovější Debian (zkopíroval jsem ho z VPS u networkpresence.com.au, kde z nějakých důvodů stále používají grub-legacy):

default=0
timeout=40

title       Debian GNU/Linux, kernel 5.10.0-16-amd64
root        (hd0,0)
kernel      /boot/vmlinuz-5.10.0-16-amd64 root=/dev/vda1 ro
initrd      /boot/initrd.img-5.10.0-16-amd64

title       Debian GNU/Linux, kernel 5.10.0-16-amd64 (single-user mode)
root        (hd0,0)
kernel      /boot/vmlinuz-5.10.0-16-amd64 root=/dev/vda1 ro single
initrd      /boot/initrd.img-5.10.0-16-amd64

Tento soubor zobrazí menu se dvěma řádky, počká 40 sekund, a pokud uživatel nic nestiskne, automaticky nabootuje první řádek. Příkazy jsou poměrně sebe-vysvětlující, co znamená root (hd0,0) si probereme později.

GRUB 2 – příklad konfiguračního souboru

Konfigurace GRUB 2 sídlí v souboru /boot/grub/grub.cfg nebo /boot/efi/EFI/debian/grub.cfg (případně samozřejmě jiné názvy pro jiné distribuce – zde je cílem, aby mohl snadno koexistovat dualboot) v určitých konfiguracích UEFI, což si vysvětlíme v druhé části článku. Takhle vypadá nejjednodušší konfigurák, tentokrát jen s jednou položkou v menu:

set timeout=20

menuentry 'Debian GNU/Linux' {
    set root='hd0,msdos2'
    linux /boot/vmlinuz-5.16.0-0.bpo.4-amd64 root=/dev/sda2
    initrd /boot/initrd.img-5.16.0-0.bpo.4-amd64
}

Jak vidíte, změny mezi verzemi 1 a 2 jsou spíše kosmetické v syntaxi (tabulátory vs. složené závorky, set proměnné místo příkazu…).

GRUB – automatické generování konfiguračního souboru

Jak vidíte výše, položky menu obsahují nahardcodované některé údaje, které se v průběhu životnosti systému mění – zejména název souboru s jádrem a initramdiskem, které obsahují konkrétní číslo verze. Pokud systém aktualizujeme, chtěli bychom, aby se tato položka změnila, případně aby nové jádro přibylo nahoru a stará jádra byla v nabídce pod tím, kdyby nové jádro nefungovalo, tak aby šlo vybrat staré.

Další věc je multiboot – pokud máte třeba dualboot s Windows nebo jinou linuxovou distribucí, lidé by rádi, aby se to samo detekovalo a GRUB pak nabídl jako další řádek v menu tyto jiné operační systémy.

Pro položku ukazující na poslední a předposlední jádro existuje v Debianu mechanismus: perlový skript linux-update-symlinks po každé instalaci jádra udržuje v /  symlinky /vmlinuz, /vmlinuz.old, /initrd.img a /initrd.img.old ukazující na poslední a předposlední verze jádra a initramdisku (předposlední verze se hodí, pokud se při upgrade něco rozbije; můžete zkusit nabootovat starší funkční verzi a problém opravit). V konfiguráku GRUBu tak klidně můžete napsat linux /vmlinuz, ovladače souborových systémů v GRUBu samozřejmě symlinky normálně podporují, a celé to bude fungovat.

Problém nastane, pokud máte /boot na samostatném oddílu, například protože máte / šifrované. Pak to nejde, protože symlink je v /  a odkazuje třeba na /boot/vmlinuz-5.17.0-2-amd64, což je ale jiný souborový systém. To se dá vyřešit v konfiguračním souboru /etc/kernel-img.conf (ve výchozím stavu neexistuje) – pokud ho vytvoříte a napíšete do něj image_dest=/boot, tak se symlinky budou vytvářet v /boot  a zase to bude všechno v pořádku.

Standardní způsob řešení tohoto problému ale je nechat celý konfigurační soubor pro GRUB vygenerovat automatem podle šablony. Výše uvedené jsem tedy psal jednak pro kontext, případně abyste uměli výsledek automatu debugovat, a taky proto, že pravidelně někdo v diskuzích vyjadřuje přání, že si chce konfigurační soubor pro GRUB psát ručně, no tak jsme právě popsali, jak si to přání splnit.

Generátor konfiguračních souborů pro GRUB se jmenuje update-grub a spouští se automaticky při instalaci balíčků, které mohou chtít soubor změnit (nejčastěji nového jádra), případně ho můžete spustit ručně, pokud jste nějaké změny provedli sami (nejčastěji změna konfigurace v /etc/default/grub). Ve skutečnosti si přečteme v manuálové stránce, že generátor se jmenuje grub-mkconfig a update-grub je pouze alias:

update-grub is a stub for running grub-mkconfig -o /boot/grub/grub.cfg to generate a grub2 config file.

Každopádně já spouštím update-grub. Myslím, že některé distribuce založené na Red Hatu update-grub neměly a bylo nutné spustit grub-mkconfig s uvedenými parametry.

Generátor musí kromě seznamu jader někde také sehnat, co jim má dát jako parametr root= a případně další parametry, které si administrátor systému přeje. root= se dělá automaticky pomocí grub-probe --target=device /, což jsem si přečetl v souboru /etc/grub.d/10_linux a následně v /usr/sbin/grub-mkconfig, kde se kořenový souborový systém definuje.

Další komponenta je balík os-prober, který projde všechny oddíly na systému, podívá se, jaké jsou na nich operační systémy a také je přidá do konfigurace GRUBu jako další položky. Já nikde dualboot nemám, takže s tím nemám zkušenosti. Tedy přesněji mám s tím zkušenosti jen děsivé, kdy os-prober procházel tyto oddíly tak nešťastně, že na ně zapisoval (například přehrával žurnál), ačkoli byly namountované odjinud (například zevnitř virtuálu nebo po síti), a tím způsoboval poškození souborového systému. Proto balíček os-prober nemám vůbec nainstalovaný.

GRUB 1 – automatické generování konfiguračního souboru

Generátor konfiguračního souboru potřebuje někde sebrat šablonu a parametry, které má do konfiguračního souboru zapsat – nejběžnější parametr, který nastavuji, jsou parametry jádra, ale může to být třeba i rozlišení grafického menu nebo rychlost sériového portu. V GRUB 1 se to řešilo tak, že se parametry nastavovaly jako zakomentované řádky v již zmíněném /boot/grub/menu.lst, generátor následně parametry z komentářů vyparsoval a nezakomentovanou část souboru přepsal. Pro historický záznam zde uvádím kompletní /boot/grub/menu.lst opět z uvedené VPS:

default=0
timeout=40
### BEGIN AUTOMAGIC KERNELS LIST
## lines between the AUTOMAGIC KERNELS LIST markers will be modified
## by the debian update-grub script except for the default options below

## DO NOT UNCOMMENT THEM, Just edit them to your needs

## ## Start Default Options ##
## default kernel options
## default kernel options for automagic boot options
## If you want special options for specific kernels use kopt_x_y_z
## where x.y.z is kernel version. Minor versions can be omitted.
## e.g. kopt=root=/dev/hda1 ro
##      kopt_2_6_8=root=/dev/hdc1 ro
##      kopt_2_6_8_2_686=root=/dev/hdc2 ro
# kopt=root=/dev/vda1 ro

## default grub root device
## e.g. groot=(hd0,0)
# groot=(hd0,0)

## should update-grub create alternative automagic boot options
## e.g. alternative=true
##      alternative=false
# alternative=true

## should update-grub lock alternative automagic boot options
## e.g. lockalternative=true
##      lockalternative=false
# lockalternative=false

## additional options to use with the default boot option, but not with the
## alternatives
## e.g. defoptions=vga=791 resume=/dev/hda5
# defoptions=

## should update-grub lock old automagic boot options
## e.g. lockold=false
##      lockold=true
# lockold=false

## Xen hypervisor options to use with the default Xen boot option
# xenhopt=

## Xen Linux kernel options to use with the default Xen boot option
# xenkopt=console=tty0

## altoption boot targets option
## multiple altoptions lines are allowed
## e.g. altoptions=(extra menu suffix) extra boot options
##      altoptions=(single-user) single
# altoptions=(single-user mode) single

## controls how many kernels should be put into the menu.lst
## only counts the first occurence of a kernel, not the
## alternative kernel options
## e.g. howmany=all
##      howmany=7
# howmany=all

## should update-grub create memtest86 boot option
## e.g. memtest86=true
##      memtest86=false
# memtest86=true

## should update-grub adjust the value of the default booted system
## can be true or false
# updatedefaultentry=false

## should update-grub add savedefault to the default options
## can be true or false
# savedefault=false

## ## End Default Options ##

title       Debian GNU/Linux, kernel 5.10.0-16-amd64
root        (hd0,0)
kernel      /boot/vmlinuz-5.10.0-16-amd64 root=/dev/vda1 ro
initrd      /boot/initrd.img-5.10.0-16-amd64

title       Debian GNU/Linux, kernel 5.10.0-16-amd64 (single-user mode)
root        (hd0,0)
kernel      /boot/vmlinuz-5.10.0-16-amd64 root=/dev/vda1 ro single
initrd      /boot/initrd.img-5.10.0-16-amd64

### END DEBIAN AUTOMAGIC KERNELS LIST

Tento přístup má výhodu v tom, že je všechno „hezky pohromadě“ a že si můžete okolo toho (mezi ty komentáře, kterými je označená oblast souboru, která se přepisuje) přímo dopsat vlastní volby a příkazy podle libosti. Ovšem má nevýhodu v tom, že je v jednom souboru obecná konfigurace a současně automaticky vygenerovaná konfigurace, která se sama přepisuje – pokud pro správu konfiguračních souborů používáte nějaký systém (ať už git nebo nějaký automatický deployment), je toto docela peklo řešit. Další problém je, že update-grub je zde monolitický shellový skript v /usr/sbin/  a vy tak nemáte v podstatě žádnou možnost v něm cokoli změnit, aniž by se to při upgradu přepsalo.

GRUB 2 – automatické generování konfiguračního souboru

Generování konfigurace v GRUB 2 je řešeno podstatně modulárněji. Skript update-grub, resp. grub-mkconfig, je jen wrapper, který načte obsah /etc/default/grub a následně volá podle abecedy skripty z /etc/grub.d/  a jejich stdout přidává do generovaného konfiguráku.

Celé se to tedy provozuje takto:

• V /etc/default/grub  nastavíte globální věci – parametry jádra, rozlišení grafiky, sériovou konzoli…
• Pokud potřebujete modifikovat jednotlivé vygenerované položky, tak změníte /etc/grub.d/10_linux. To jsem potřeboval jednou v životě.
• Pokud máte vlastní položky, tak je přidáte do /etc/grub.d/40_custom.
• Spustíte update-grub.

Výhodou je, že jsou to všechno samostatné konfigurační soubory v /etc  a lze je tedy libovolně upravovat a spravovat, nevýhodou je nutnost znalosti této mírně složitější problematiky.

GRUB – nejčastější změny konfigurace

Pojďme se podívat na nejčastější věci, které nastavuji:

• Jako první věc nastavím v /etc/default/grub  následující parametry jádra: GRUB_CMDLINE_LINUX_DEFAULT="net.ifnames=0 biosdevname=0". Bez toho by se síťová rozhraní jmenovala velmi komplikovaně a jejich názvy by se měnily třeba v okamžiku, kdy někdo do volného PCIe slotu zastrčí novou grafickou kartu. Takto se vždy jmenují síťovky eth0 a wlan0, problém zase může nastat, pokud mám dvě ethernetové síťovky, to se pak jmenují náhodně eth0 a eth1 a je potřeba to svázat dle MAC adresy.
• Dále používám tohle na počítačích se sériovou konzolí:

  GRUB_CMDLINE_LINUX_DEFAULT="console=ttyS0,115200"
  
  GRUB_TERMINAL="console serial"
  GRUB_SERIAL_COMMAND="serial --speed=115200 --unit=0 --word=8 --parity=no --stop=1"

• V případě problémů s grafickou kartou můžeme zkusit nastavit jednak GRUB do textového módu:

  GRUB_TERMINAL=console
  GRUB_GFXMODE=text

  a jednak nastavit všechny možné parametry jádra, co jsem postupně nasbíral, které vynutí konzoli jádra v textovém módu:
  
  

  GRUB_CMDLINE_LINUX_DEFAULT="nomodeset nosplash i915.modeset=0 nouveau.modeset=0 gfxpayload=vga=text nofb"

  Když už jsme u toho, v jednom případě bylo dokonce nutné blacklistovat moduly (to už se nijak netýká GRUBu, ale mám to napsané v poznámkách u toho, tak to sem taky přidám):
  
  

    blacklist cirrus
    blacklist ttm
    blacklist drm_kms_helper
    blacklist drm
    blacklist gma500_gfx # for Intel GMA500

  Možná, že některé z uvedených parametrů už neplatí, já jsem je nastřádal postupně za 10 let praxe.
• A jako poslední je zaheslování grubu (což chtěl zákazník, ačkoli jsem to nevyhodnotil jako příliš možný vektor útoku):

  /etc/grub.d/10_linux:142 přidat --unrestricted aby to bootovalo bez hesla
  
        echo "menuentry '$(echo "$title" | grub_quote)' ${CLASS} \$menuentry_id_option 'gnulinux-$version-$type-$boot_device_id' --unrestricted {" | sed "s/^/$submenu_indentation/"
  
  /etc/grub.d/40_custom:
  set superusers="root"
  password_pbkdf2 root grub.pbkdf2.sha512.10000.bagrbagrbagrbagrbagrbagr
  
  přičemž ten hash vygenerovalo grub-mkpasswd-pbkdf2

GRUB – použití ruční konzole, pojmenování disků

Pro opravu nebootujícího počítače je vhodné umět použít konzoli GRUBu. Z konzole se dají procházet soubory na disku. Typicky chceme najít jádro, nahrát ho do paměti a spustit, takto systém nabootujeme ručně a následně se ho můžeme pokusit opravit.

Konzoli spustíme z menu klávesou c, případně pokud je systém opravdu hodně rozbitý (GRUB nenašel konfigurační soubor s menu), tak se menu vůbec nezobrazí a konzole se spustí rovnou. První věc, co v konzoli napíšeme, je ls, což nám zobrazí disky, které GRUB vidí. Na rozdíl od linuxové notace typu /dev/sda2 se v GRUBu disky označují například (hd0,msdos2) (druhý oddíl prvního disku, „MBR“/DOS tabulka oddílů) nebo (hd0,gpt2) (druhý oddíl prvního disku, GPT tabulka oddílů). Pokud má GRUB nahrané potřebné moduly, tak mezi disky přímo uvidíme například i LVM svazky, pokud LVM používáme.

Pokud napíšeme ls (hd0, a dva tabulátory, tak nám to dokonce vypíše typ souborového systému, UUID a další informace. Můžeme udělat třeba ls (hd0,gpt2)/home/blabla a normálně vidíme soubory. Naším cílem je najít jádro, takže třeba ls (hd0,gpt2)/vmlinuz (jinak normálně funguje doplňování tabulátorem) a následně ho nahrát i s parametry, to už jsme viděli výše v příkladu konfiguračního souboru:

grub> linux (hd0,gpt2)/vmlinuz root=/dev/sda2
grub> initrd (hd0,gpt2)/initrd.img
grub> boot

Alternativně nemusíte uvádět vždy číslo disku a oddíl v cestě, ale můžete zadat příkaz set root='hd0,gpt2' a pak psát již jen jména souborů.

Další situace, se kterou se můžeme potkat, je, že GRUB nenajde konfigurační soubor s menu – to se projeví tak, že na nás kouká rovnou konzole. Soubor můžeme načíst ručně – configfile (hd0,msdos2)/boot/grub/grub.cfg  – a menu se objeví. Jiní diskutující na Rootu popisovali, jak se dostat z ještě horšího stavu s grub rescue.

Bootování PC

Nyní musíme vyřešit, jak vlastně GRUB při startu počítače spustit, aby se vůbec mohly stát všechny ty výše popsané věci. Stejně jako u dvou generací GRUBů, i tady jsou dva způsoby, jeden je označovaný jako BIOS/MBR/legacy a druhý jako (U)EFI. Zde přechod teprve probíhá, na mnoha stále používaných počítačích lze mezi způsoby přepínat, jen nejnovější počítače typicky podporují již jen EFI boot.

Bootování pomocí BIOS/legacy

Legacy boot je tu s námi snad od prvního IBM PC. Funguje tak, že firmware počítače (ne úplně přesně zván BIOS) načte do paměti první sektor (512 bajtů) pevného disku a spustí ho. Nic víc.

Výhodou tohoto postupu je, že je tak jednoduchý, že je na něm málo věcí k pokažení, i když i takoví se najdou – například jsou BIOSy, které odmítnou sektor načíst, pokud není na disku validní tabulka oddílů s oddílem označeným jako bootovacím.

Nevýhodou je, že do 512 bajtů, z nichž je navíc jen 446 bajtů dostupných (zbytek je tabulka oddílů), se nevejde v podstatě žádný užitečný kód – což zavaděče řeší tak, že tento kód načte nějaký další kód, a ten teprve je užitečný. Ovšem do těch 446 bajtů (u GRUBu se to nazývá stage 1 nebo boot.img) se nevejde ani ovladač souborového systému, takže další stage nejde načíst ze souboru, ale musí se to vyřešit nějak jinak.

Další problém je, že tento BIOS běží v reálném módu procesoru a celé je to tak velmi omezené a špatně se tam programují nové věci. Postupně přibyla podpora pro disky SATA, pro emulaci USB klávesnice (to dělá volba USB legacy support, kterou jste určitě už potkali v setupu počítače) a další, každopádně pokud vím, neexistuje například podpora NVMe disků a byly tam nějaké problémy s disky s velikostí nad 2 TiB.

Nealokované místo před prvním oddílem

Jak jsem psal, do prvního sektoru načteného BIOSem se nevejde ovladač souborového systému, další kód můžeme načítat pouze pomocí natvrdo nastavených adres na disku, nic složitějšího dělat nemůžeme. GRUB toto řeší tak, že se uloží do nealokovaného místa mezi 1. sektorem a počátkem prvního oddílů. První sektor tak vlastně načte data hned za sebou.

Zde hned nastává problém, že zhruba do roku 2012 byl výchozí stav v cfdisku a některých instalátorech linuxových distribucí, že první oddíl začínal na 64. sektoru. Před prvním oddílem tak bylo tedy pouze 64×512 = 32 KiB prostoru a nastával problém, že pokud GRUB vyžadoval nějaké komplikovanější nastavení (např. boot z RAIDu nebo z LVM), tak se tam nevešel a bylo potřeba dělat příšerné hacky s různým přesouváním sem a tam. Zhruba od roku 2012 se již začátky oddílů zaokrouhlují na celé megabajty a do megabajtu se GRUB vejde, pokud se vyházejí moduly, které jsou pro daný počítač úplně zbytečné (například všechny souborové systémy, kromě toho, který se opravdu používá), což dělá  grub-mkimage.

grub-mkimage

GRUB je kompletně modulární – všechny ovladače (souborové systémy, USB zařízení, bootování různých operačních systémů vyžadujících speciální postup…) jsou v souborech .mod. Moduly najdete v adresáři /usr/lib/grub/x86_64-efi/ používáte-li UEFI, případně /usr/lib/grub/i386-pc/ používáte-li „legacy“ boot. Na mém systému mají všechny moduly dohromady asi 3 MB. Z názvu modulů si můžete udělat představu, co asi tak dělají. Například se jmenují: exfat.mod, luks2.mod, mdraid1x.mod,  usbserial_ftdi.mod.

V průběhu instalace GRUBu se tyto moduly zkopírují do /boot/grub/<architektura>/. To je kvůli tomu, aby byly dostupné, i když je třeba adresář /usr/lib/grub/ na šifrovaném disku nebo je dokonce /usr/ třeba připojené přes NFS po síti.

Pro nabootování GRUBu potřebujeme vytvořit tzv. grub image (označovaný také core.img). To je samotné jádro GRUBu plus potřebné moduly, které jsou v něm zapečené. Dále je v něm zapsáno, kde najde konfigurační soubor, protože ten je na nějakém normálním souborovém systému. grub image tedy musí mít zapečený modul minimálně pro tento systém. Na druhou stranu už nemusí mít zapečené moduly pro další věci které budeme požadovat (například nabootování linuxového jádra, což je modul linux.mod), protože moduly je možné nahrávat i za běhu, a jakmile jsme dokázali otevřít systém souborů, kde sídlí /boot/grub, můžeme je dodatečně nahrát za běhu (příkazem insmod v konzoli/konfiguračním souboru).

Výrobu grub image dělá program grub-mkimage a při běžné administraci není potřeba ho spouštět ručně, protože ho volá skript grub-install se správnými parametry. Můžete si dát grub-mkimage --help a vidíme, že se programu má předat jako parametr seznam modulů, které má do výsledného image zapéct, a také informace o tom, kde má hledat moduly a konfiguraci (to bude lépe vidět z příkladu v následující kapitole).

Instalace GRUBu (BIOS boot)

Verze GRUBu pro „legacy“ bootování sídlí v Debianu v balíčku  grub-pc.

Instalaci provedeme příkazem grub-install /dev/sda. Přidáním parametru -v navíc uvidíme, co se, velmi podrobně, děje. Musí se stát několik poměrně odvážných věcí.

# grub-install -v /dev/sda
grub-install: info: executing modprobe efivars 2>/dev/null.
grub-install: info: Looking for /sys/firmware/efi ...
grub-install: info: ... not found.
grub-install: info: Looking for /proc/device-tree ...
grub-install: info: ... not found.
Installing for i386-pc platform.

Zde se detekovalo, že nebudeme instalovat pro EFI, a budeme instalovat pro BIOS/legacy boot – to je to i386-pc (EFI by bylo  x86_64-efi).

[...]
grub-install: info: copying `/usr/lib/grub/i386-pc/mdraid1x.mod' -> `/boot/grub/i386-pc/mdraid1x.mod'.
grub-install: info: copying `/usr/lib/grub/i386-pc/exfat.mod' -> `/boot/grub/i386-pc/exfat.mod'.
grub-install: info: copying `/usr/lib/grub/i386-pc/ext2.mod' -> `/boot/grub/i386-pc/ext2.mod'.
grub-install: info: copying `/usr/lib/grub/i386-pc/usbserial_pl2303.mod' -> `/boot/grub/i386-pc/usbserial_pl2303.mod'
grub-install: info: copying `/usr/lib/grub/i386-pc/lvm.mod' -> `/boot/grub/i386-pc/lvm.mod'.
grub-install: info: copying `/usr/lib/grub/i386-pc/btrfs.mod' -> `/boot/grub/i386-pc/btrfs.mod'.
grub-install: info: copying `/usr/share/grub/unicode.pf2' -> `/boot/grub/fonts/unicode.pf2'.

Zde vidíme, že program provedl překopírování modulů z /usr/lib/grub  do /boot/grub jak jsem popsal výše.

grub-install: info: grub-mkimage --directory '/usr/lib/grub/i386-pc' --prefix '(,msdos2)/boot/grub' --output '/boot/grub/i386-pc/core.img'  --dtb '' --sbat '' --format 'i386-pc' --compression 'auto'  'ext2' 'part_msdos' 'biosdisk'

Nyní byly detekovány potřebné parametry systému a byl s nimi spuštěn program grub-mkimage. Uváděné parametry znamenají:

• --directory '/usr/lib/grub/i386-pc'  – adresář, ze kterého se budou brát moduly pro zapékání
• --prefix '(,msdos2)/boot/grub'  – adresář, ve kterém se mají hledat moduly a konfigurační soubor. Protože ho bude hledat GRUB, je to v grubovém formátu cest/oddílů, který jsme popsali v kapitole o grub konzoli. Toto znamená druhý oddíl (DOS/MBR rozdělení) disku ze kterého GRUB nastartoval.
• --output '/boot/grub/i386-pc/core.img'  – kam se má uložit vytvořený grub image
• --format 'i386-pc'  – bude se generovat image pro BIOS/legacy boot
• --compression 'auto'  – grub image může být komprimovaný
• 'ext2' 'part_msdos' 'biosdisk'  – toto je seznam modulů, které se do něj mají zapéct

grub-install: info: the total module size is 0x3f34.
grub-install: info: reading /usr/lib/grub/i386-pc/kernel.img.
grub-install: info: locating the section .text at 0x0.
grub-install: info: locating the section .rodata at 0x5968.
grub-install: info: locating the section .data at 0x6a40.
grub-install: info: locating the section .bss at 0x7260.
grub-install: info: reading /usr/lib/grub/i386-pc/fshelp.mod.
grub-install: info: reading /usr/lib/grub/i386-pc/ext2.mod.
grub-install: info: reading /usr/lib/grub/i386-pc/part_msdos.mod.
grub-install: info: reading /usr/lib/grub/i386-pc/biosdisk.mod.
grub-install: info: kernel_img=0x55b676a7e2b0, kernel_size=0x7244.
grub-install: info: the core size is 0x5a81.
grub-install: info: reading /usr/lib/grub/i386-pc/lzma_decompress.img.
grub-install: info: reading /usr/lib/grub/i386-pc/diskboot.img.
grub-install: info: writing 0x200 bytes.
grub-install: info: writing 0x65a1 bytes.
grub-install: info: copying `/usr/lib/grub/i386-pc/boot.img' -> `/boot/grub/i386-pc/boot.img'.

Zde proběhlo binární zapečení (v podstatě linkování) modulů.

grub-install: info: grub-bios-setup  --verbose     --directory='/boot/grub/i386-pc' --device-map='/boot/grub/device.map' '/dev/sda'.
grub-install: info: reading /boot/grub/i386-pc/boot.img.
grub-install: info: reading /boot/grub/i386-pc/core.img.
grub-install: info: Opening dest `hostdisk//dev/sda'.
grub-install: info: saving <1,0,512>.
grub-install: info: saving <2,0,512>.
[...]
grub-install: info: saving <103,0,512>.
grub-install: info: saving <104,0,512>.
Installation finished. No error reported.

Na závěr se spustil další program – grub-bios-setup. Ten není v $PATH, takže pro jeho nápovědu musíte spustit s celou cestou /usr/lib/grub/i386-pc/grub-bios-setup --help. Jak vidíme, program načte vytvořené images – boot.img je první sektor který BIOS načítá, a core.img je grub image s moduly který jsme vytvořili v předchozím kroku – a sektor po sektoru je zapíše přímo na /dev/sda. To je ta děsivá část, ale doufejme, že se v předchozích krocích správně detekovalo, že se jedná o nealokované místo před prvním oddílem, a nepřepíšete si tak souborový systém!

Administrace systému s BIOS boot

Jako správce systémů často stojím před úkolem nakopírovat systém na nějaký nový disk a udělat ho bootovacím, případně upravit bootování po nějakém zásahu (výměna disků, změna konfigurace RAIDu…), opravit nebootující systém po havárii a obnově ze zálohy nebo opravit GRUB který byl přepsán při instalaci jiného systému (Windows v dual bootu). Ačkoli všechny výše uvedené příkazy lze teoreticky provést z jiného systému, například z live CD nebo v případě virtuálního stroje namountováním souborového systému do hypervizoru, osobně jsem se o to zatím raději nepokoušel, protože mají mnoho parametrů, které je potřeba zadat správně.

Vždy raději provedu do systému chroot a grub-install spustím z tohoto chrootnutého systému. To je samozřejmě často komplikované, protože se pro chroot musí nastavit všechny souborové systémy ( /proc, /sys, /dev a nově i /run) a navíc si netroufám provádět chroot přímo z hypervizoru, případně svého notebooku (připojením disku do USB-SATA redukce v případě fyzického serveru), protože je-li systém backdoornutý, může z chrootu utéci. Instalace a opravy se tak komplikují.

Bootování pomocí UEFI

Na rozdíl od BIOSu, který uměl pouze načíst první sektor a spustit ho, UEFI umí načíst soubor z oddílu FAT a spustit ho. Odpadá tak harakiri se zapisováním binárních dat přímo někam na /dev/sda. Dále takto načtený GRUB image může být větší, takže není potřeba dělat vlastní image pomocí grub-mkimage, a můžeme mít přímo z distribuce zkompilovaný image se všemi moduly, který jen zkopírujeme. Dále si takto načtený GRUB umí přímo sáhnout pro konfigurační soubor na tomto oddíle FAT, takže odpadá i ten druhý důvod, proč musíme sestavovat na cílovém počítači vlastní image, totiž zapečení cesty ke konfiguračnímu souboru a modulům.

Celá instalace tak spočívá ve zkopírování dvou souborů na FAT a volitelně zapsání nějakých informací do konfigurace („BIOSu“) v paměti typu flash na základní desce (o tom později). Toto zkopírování souborů lze udělat z libovolného jiného operačního systému a není potřeba řešit žádný  chroot.

Další výhoda, kterou ale ocení spíš tvůrci firmwarů a programátoři GRUBu, je, že se startuje v normálním 32bitovém nebo 64bitovém režimu procesoru a ne 16bitovém real mode, takže věci nějak normálně fungují.

EFI system partition

Výše jsem uvedl, že UEFI při bootování načítá soubory z oddílů FAT. Tento oddíl může být ve formátech FAT12, FAT16 nebo FAT32 (já jsem vždy dělal mkfs.vfat) a dělám jej řádově 100–200 MB velký, protože disky jsou levné a velké, i když by stačilo pár MB. Oddíl musí mít nastavený typ, podle kterého UEFI pozná, že tam má hledat FAT a na něm bootovací soubory:

• V případě rozdělení disku „MBR“ („DOS label“) má mít typ „0×EF“, ale já mám třeba live flashku, kde je typ „0×0C“ („W95 FAT32 (LBA)“), a taky to funguje. Mým cílem totiž bylo mít flashku, která se současně chová jako plně kompatibilní flashka.
• V případě GPT rozdělení disku má mít typ „EFI System“.

Oboje nastavíte například v cfdisku pomocí tlačítka Type.

Na Linuxu se standardně tento oddíl mountuje do /boot/efi, například následujícím řádkem souboru  /etc/fstab:

UUID=ABCD-1234 /boot/efi vfat defaults 0 0

Názvy bootovacích souborů, removable instalace

Ve výchozím stavu se bootuje soubor EFI/BOOT/BOOTX64.EFI na tomto oddíle. (FAT nerozlišuje velikosti písmen, takže to může být i malými písmeny) Soubor je binárka PE32, tedy stejný formát jako Windows EXE, ale jedná se pouze o formát obálky binárního souboru, nečekejte, že to půjde spustit ve Wine a něco to bude dělat:

EFI/BOOT/BOOTX64.EFI: PE32+ executable (EFI application) x86-64 (stripped to external PDB), for MS Windows

Pokud instalujete zavaděč (což ve skutečnosti může znamenat, že prostě kopírujete soubor na FATku) do této cesty, tak se tomu říká removable instalace. Je to totiž výchozí název bootovacího souboru, který nevyžaduje žádné předchozí nastavení počítače – což je přesně to, co chcete dělat na removable („live USB“) médiích – přijít k počítači, zastrčit a bootovat.

Na druhou stranu toto není výhodné, pokud máte dual-boot: operační systémy si budou tento soubor navzájem přepisovat, stejně jako se v případě legacy bootu hádají o obsah MBR. Proto existuje druhá možnost: soubor můžete umístit jinam a firmwaru počítače řeknete, kde je a jak se má jmenovat. Při startu počítače si pak můžete vyvolat přímo hardwarové boot menu a tam si ho vybrat. Osobně bych ale i v případě dual bootu preferoval GRUB a systémy spouštět z něj, protože to hardwarové menu má každý počítač jiné, a je složité nastavit timeout, která volba bude výchozí, nebo třeba jednorázově nabootovat bez obsluhy jinou volbu a když to selže, tak nabootovat předchozí.

Každopádně uvedené se dělá tak, že se soubor umístí třeba do EFI/debian/grubx64.efi a následně se firmwaru počítače řekne, že existuje; že o tom ví zjistíte příkazem  efibootmgr -v:

# efibootmgr -v
BootCurrent: 0000
Timeout: 0 seconds
BootOrder: 0000,0006
Boot0000* debian    HD(1,GPT,8ecc7ca0-4666-4c3d-bbf4-12a8bc260f5d,0x800,0x82000)/File(\EFI\debian\grubx64.efi)
Boot0006* Windows Boot Manager  HD(1,GPT,8ecc7ca0-4666-4c3d-bbf4-12a8bc260f5d,0x800,0x82000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)

Zde vidíme dvě položky, Debian a Windows. Tímto příkazem lze i položky přidávat a mazat, měnit jim pořadí, ale nikdy jsem to nedělal.

Instalace GRUBu na EFI – distribuční

Verze GRUBu pro UEFI bootování sídlí v Debianu v balíčku  grub-efi-amd64.

Instalace GRUBu „oficiálním“ ne-removable způsobem se spustí příkazem grub-install stejně jako minule:

# grub-install -v /dev/nvme0n1
grub-install: info: executing modprobe efivars 2>/dev/null.
grub-install: info: Looking for /sys/firmware/efi ...
grub-install: info: ...found.
Installing for x86_64-efi platform.

Nyní jsme uhádli, že budeme instalovat pro UEFI. V případě, že se to nedetekuje automaticky, je možné zavolat grub-install --target=x86_64-efi. To se také hodí, pokud na EFI systému vyrábíme disk, který budeme chtít bootovat pomocí legacy (zadáme i386-pc target).

[...]
grub-install: info: copying `/usr/lib/grub/x86_64-efi/part_gpt.mod' -> `/boot/grub/x86_64-efi/part_gpt.mod'.
[...]

Opět proběhne zkopírování všech modulů.

grub-install: info: grub-mkimage --directory '/usr/lib/grub/x86_64-efi' --prefix '(,gpt2)/grub' --output '/boot/grub/x86_64-efi/core.efi'  --dtb '' --sbat '' --format 'x86_64-efi' --compression 'auto'   'ext2' 'part_gpt'
[...]
grub-install: info: locating grub_vprintf at 0xa95e (0x1000).
[...]
grub-install: info: relocating an R_X86_64_64 entry to 0xc46b at the offset 0x953.
[...]
grub-install: info: adding a relocation entry for 0x3115.
[...]

Zde proběhlo slinkování grub image „na míru“.

grub-install: info: writing 0x21000 bytes.
grub-install: info: No Secure Boot: installing core image.
grub-install: info: copying `/boot/grub/x86_64-efi/core.efi' -> `/boot/efi/EFI/debian/grubx64.efi'.
grub-install: info: Registering with EFI: distributor = `debian', path = `\EFI\debian\grubx64.efi', ESP at hostdisk//dev/nvme0n1,gpt1.
grub-install: info: executing modprobe efivars 2>/dev/null.
grub-install: info: setting EFI variable Boot0000.
grub-install: info: setting EFI variable BootOrder.
Installation finished. No error reported.

Nakonec byl grub image zapsán – zkopírován do souboru /boot/efi/EFI/debian/grubx64.efi a tento soubor byl zaregistrován jako bootovací položka. Výsledný soubor má na mém počítači asi 135 kB.

Instalace GRUBu na EFI – removable ruční, monolitický GRUB

Výše jsem jako jednu z výhod prezentoval, že přes EFI můžeme bez problému zavádět několika-megabajtové binárky, a tak již není nutné sestavovat si GRUB vždy z modulů na míru, abychom ušetřili místo. Distribuce tak dodávají sestavený grub image, kterému říkají „monolitický“, a jedná se o EFI binárku GRUBu, která obsahuje většinu existujících modulů.

Například na Debianu ji najdeme v souboru /usr/lib/grub/x86_64-efi/monolithic/grubx64.efi a má 1,7 MB (srovnejte s 135 kB ve výše uvedeném příkladu, nicméně co to znamená? megabajt místa na disku je nic, a zpomalení bootu způsobené nahráváním většího souboru je taky zanedbatelné). Pokud si věci ze článku rovnou zkoušíte, můžete srovnat výpis příkazu lsmod v GRUB konzoli na míru sestaveného GRUBu a monolitického GRUBu – u něj hned budete muset zagooglit, jak udělat ekvivalent linuxového lsmod | less, protože se vám nevejde na obrazovku. Odpověď:  set pager=1.

Nyní tedy zlatý hřeb večera, ruční instalace GRUBu na nový disk, flashdisk atd. Vyrobíte oddíl FAT typu EFI system, vytvoříte na ní adresář /EFI/Boot/, a zkopírujete do něj soubor /usr/lib/grub/x86_64-efi/monolithic/grubx64.efi pojmenovaný jako bootx64.efi. Žádný chroot, žádné zajišťování místa před prvním oddílem, žádné sestavování grub image.

Druhý důvod, proč jsme vyráběli vlastní grub image, byl, že jsme do něj potřebovali zadat cestu ke konfiguračnímu souboru – takto nainstalovaný GRUB po spuštění nabídne jen konzoli. Monolitický GRUB v Debianu má v sobě zapečenou cestu, kde soubor hledá, je to soubor /EFI/debian/grub.cfg na tom EFI oddílu, ze kterého nabootoval.

Předpokládám, že ostatní distribuce to budou mít podobně, jen se ten adresář nebude jmenovat debian. V tomto souboru si můžete ručně napsat menu, třeba podle příkladu uvedeného na samotném začátku tohoto článku. Další možnost je v tomto souboru pouze načíst soubor /boot/grub/grub.cfg vygenerovaný distribucí, tím budeme mít všechna ta automaticky nalezená jádra a operační systémy atd. To se řeší tak, že se do tohoto souboru zapíše:

search.fs_uuid 9f070ae6-7995-4b3a-8eea-b8b66d7da2da root
set prefix=($root)'/grub'
configfile $prefix/grub.cfg

přičemž uvedené UUID oddílu kde je /boot můžeme zjistit například příkazem ls -l /dev/disk/by-uuid/, nebo blkid, nebo  lsblk -f.

32bitové EFI

Musíme si ukázat jeden problém: ve výše uvedeném textu jsme používali název binárky bootx64.efi. Z názvu lze asi odhadnout, že je 64bitová. Bohužel existují počítače, které, byť mají 64bitový procesor, mají UEFI, které podporuje pouze 32bitové programy. Zatím jsem se s tím setkal výhradně u levných tenkých notebooků s Intel Atom. Abychom dokázali spustit takový počítač, potřebujeme 32bitový EFI GRUB. Oproti již prezentovanému tedy musíme udělat následující změny:

• Cesta, která se ve výchozím stavu bootuje, se nejmenuje EFI/boot/bootx64.efi, ale  EFI/boot/bootia32.efi.
• Balíček s GRUBem, který instalujeme v Debianu, se nejmenuje grub-efi-amd64, ale  grub-efi-ia32.
• Soubor s monolitickým GRUBem se nejmenuje /usr/lib/grub/x86_64-efi/monolithic/grubx64.efi, ale  /usr/lib/grub/i386-efi/monolithic/grubia32.efi.

Mimochodem pokud chcete mít nainstalované obě varianty současně, všimnete si, že balíčky grub-efi-amd64 a grub-efi-ia32 jsou ve vzájemném konfliktu. To ale nevadí, vedle balíčku grub-efi-amd64 si můžete nainstalovat balíček grub-efi-ia32-bin, který obsahuje třeba ten uvedený monolitický soubor. Ty balíčky bez -bin především určují, která verze se spustí ve výchozím stavu, když budete spouštět věci jako  grub-install.

Memtest

Populární program Memtest se zavede jako operační systém a provádí testování operační paměti. Do paměti zapíše různá data a následně je čte a kontroluje, zda se nezměnila. Tím se odhalí hardwarové problémy. Je vhodné ho nechat proběhnout když si koupíte nový počítač nebo paměť, nebo pokud máte s počítačem podivné problémy, které by mohly být způsobeny vadnou pamětí.

Problém s open-source programem Memtest86+ je, že je napsán tak, že využívá 16bitové rozhraní BIOSu, a v režimu UEFI tak vůbec nemůže fungovat. Při psaní článku jsem zjistil, že autoři ho nyní portují a vydali beta verzi, u které je ale napsáno, že je experimentální a není vhodná pro ostré nasazení. Co ale dělat, pokud chcete testovat RAM a máte počítač, který již „legacy boot“ vůbec nepodporuje?

Já používám closed-source MemTest86. Jeho verze zdarma má mírně omezenou funkcionalitu, avšak mně vždy zcela dostačovala.

Z jejich webu si stáhneme .zip, který má 9 MB, a po rozbalení dostaneme 525 MB velký soubor memtest86-usb.img, který obsahuje trochu dat a pak 500 MB nul :-). Jedná se o image určený pro zkopírování (například pomocí dd) na flashdisk. My tomu ale možná nechceme obětovat celou flashku, případně chceme Memtest spouštět z disku na již nainstalovaném systému. Proto image rozbalíme: pomocí kpartx -a memtest86-usb.img namapujeme přes loopback oddíly které v image jsou, pomocí mount /dev/mapper/loop0p1 /mnt/foo oddíl připojíme (zajímavostí je, že image obsahuje dva oddíly se stejným obsahem, jeden je typu Microsoft basic data a jeden typu EFI System. Není mi jasný důvod tohoto řešení, ale pokud bych někdy potkal počítač, který nedokáže detekovat EFI System oddíl, tak bych zkusil toto) a zjistíme, že obsahuje soubory s pro nás již známými názvy, EFI/BOOT/BOOTX64.efi a EFI/BOOT/BOOTIA32.efi. Tyto soubory si můžeme zkopírovat třeba do /boot/efi na našem systému.

Jak tyto soubory spustit, pokud chceme Memtest spustit pouze jednorázově na vyžádání? Opět nám pomůže GRUB. Pomocí příkazu chainloader umí spustit libovolnou jinou EFI binárku. Čili:

grub> chainloader (hd0,msdos1)/někam/kam/jsme/to/nakopírovali.efi
grub> boot

Při testování v QEMU mi však takto spuštěný Memtest zobrazil rozsypaný čaj. Problém jsem vyřešil vynucením spuštění GRUBu v textovém režimu, dle již uvedeného:

GRUB_TERMINAL=console
GRUB_GFXMODE=text

Pak už se o grafiku nehádali.

Testování v QEMU

Zmínil jsem testování v QEMU. Pokud si chcete s problematikou probíranou v tomto článku hrát, nebudete mít přece pět počítačů a běhat mezi nimi s flashdisky.

QEMU podporuje UEFI a jak to zařídit je popsané na wiki ArchLinuxu. My na Debianu budeme muset jen upravit cesty.

Za prvé, implementace UEFI se jmenuje OVMF. V Debianu je to stejnojmenný balíček. Po jeho instalaci budeme mít soubor /usr/share/OVMF/OVMF_CODE.fd, který obsahuje zkompilovanou tuto implementaci.

Za druhé, budeme potřebovat soubor s „NVRAM“, ve kterém se ukládají třeba ty záznamy o operačních systémech nainstalovaných mimo výchozí bootovací removable cestu. Protože se do souboru může zapisovat, pořídíme si jeho lokální kopii: cp /usr/share/OVMF/OVMF_VARS.fd my_uefi_vars.fd. Zákeřné je, že bez tohoto souboru to nevypíše žádnou chybu, jenom to prostě nenabootuje, ani výchozí removable cestu, a na tom jsem se na delší dobu zasekl. A nyní již můžeme spustit QEMU, a dáme tomu třeba disk počítače, na kterém to spouštíme (jen si dejte pozor, pokud máte počítač nastavený tak, že začne automaticky bootovat a na disk zapisovat; pak by se vám poškodil souborový systém):

# qemu-system-x86_64 -enable-kvm -m 1G -drive if=pflash,format=raw,readonly,file=/usr/share/OVMF/OVMF_CODE.fd -drive if=pflash,format=raw,file=my_uefi_vars.fd -hda /dev/nvme0n1

K čemu takovou věc použít? Tak třeba pro instalaci a nastavování live flash disků. Nebo pokud jste na vzdáleném serveru provedli nějaké změny konfigurace a chcete si ověřit, že vám to po restartu nabootuje – tak to nejdřív zkusíte v QEMU.

Pokud chcete přímo spustit EFI binárku z disku, můžete ji předat parametrem  -kernel:

# qemu-system-x86_64 -enable-kvm -m 1G -drive if=pflash,format=raw,readonly,file=/usr/share/OVMF/OVMF_CODE.fd -drive if=pflash,format=raw,file=my_uefi_vars.fd -kernel /mnt/foo/muj_memtest.efi

Při tomto testování jsem narazil na jednu překvapivou vlastnost Linuxu – přimountoval jsem oddíl EFI, něco tam změnil, odmountoval, pro jistotu zadal sync, ale změny se stále neprojevily – přesněji řečeno, například na /dev/sda1 jsem je viděl, ale na /dev/sda byla stále předchozí verze. Vypadá to, jako kdyby linuxová cache držela zvlášť data pro /dev/sda1 a /dev/sda a navzájem se to nezneplatňovalo když se jeden změní. Aby se změny skutečně projevily, cache jsem kompletně vyprázdnil pomocí:

# echo 3 > /proc/sys/vm/drop_caches

Linux jako EFI payload

V celém článku jsme vždy spouštěli GRUB a až ten následně našel linuxové jádro a spustil ho. Přímo jádro je možné převést do formátu .efi a pak se zavede přímo, bez GRUBu. Osobně jsem nikdy neměl důvod to dělat, a tak s tím nemám zkušenosti. Pouze zmiňuji, že zde taková možnost je.

Místo GRUBu si taky můžete pořídit jiný zavaděč. V projektu systemd je prý všechno, takže mají samozřejmě i zavaděč: systemd-boot. Je to takové minimalistické, možná se vám to bude líbit.

SecureBoot

Další často probíranou funkcí UEFI je tzv. SecureBoot. Funguje to tak, že si vygenerujete klíče, nahrajete je do zmíněného „NVRAM“ prostoru, kde je uložena konfigurace UEFI (nejspíš nějaká flash paměť připájená na desce), a následně počítač bude spouštět pouze .efi binárky, které jsou podepsané tímto klíčem (tato EFI binárka – což může být třeba GRUB – pak samozřejmě nesmí jen tak z disku načíst jádro, ale musí opět zkontrolovat, že je nějakým způsobem podepsaná). Alternativně nemusíte generovat klíče vlastní, ale můžete použít klíče autorů distribuce. Výhodou pak je, že nelze udělat útok kdy někdo pozmění obsah disku a nainstaluje tam backdoor.

Kolem této technologie panují různé celkem pochopitelné obavy, že výrobce počítače zakáže lidem, kteří si počítač koupili, přidat si vlastní klíč, a bude bootovat pouze operační systémy podepsané jím nebo například Microsoftem. Dostali bychom se tak do situace, která je dnes bohužel standardem na trhu s chytrými telefony.

Osobně též se SecureBootem nemám žádné zkušenosti.

Závěr

Ukázali jsme si, jaké technické důvody vedly ke vzniku současných způsobů bootování – GRUB 2 a UEFI boot – a ukázali jsme si, jak takové systémy správně administrovat a řešit problémy, pokud nějaké nastanou.