Eida.cz - Nativní UEFI multibooty

Při pomyšlení na dualbooty a multibooty se mi nostalgicky vybavuje nejeden den laborování s nyní již neexistujícími single-core počítači, nejvíce asi ten v domě u Verčových, kde jsme s Ketřem docela složitě předělávali stroj tak, aby dokázal správně duálně nahodit Windows 98 a zároveň novější ME, či co to bylo za neřáda. Bylo to trochu složité, muselo se tenkrát hrát s pirátským PartitionMagic a všude se kazilo MBR a pak přišla dlouhá éra XPček, které se začaly snažit všechno sjednocovat pod původní NT styl. Ale to jsou jen vzpomínky.

Časy se trošku mění, písíčka dneska už nikdo nepoužívá a prakticky všechny dnešní x86-64 stroje jsou poháněné moderními UEFI, tedy něčím jako sjednoceným rozšiřitelným firmwarovým rozhraním namísto tradičního BIOSu. Tahle radost, okopírovaná mimochodem z jiných platforem jako OpenBootu, OpenFirmware a pokusech s Itaniem, přinesla spoustu nových možností, jako třeba budoucí platformní nezávislost, podporu obřích disků a další výhody plynoucí z uložení nějakých dat a komunikaci s hardwarem, ale taky třeba možnost kryptograficky ověřit startované systémy z disků nebo sítě. A právě systém startování je zajímavá věc, která může být matoucí pro někoho, kdo pořád žije v klasickém systému myšlení, jako to bylo za časů bootování v MBR.

Startování UEFI systému se od klasického BIOSu vyznačuje tím, že nepotřebuje žádný konkrétní disk s boot sektorem, ale může teoreticky přímo natáhnout konkrétní systémový kernel do paměti, a to buď s parametry specifikovanými v NVRAM, nebo pomocí standardizovaných cest na GPT médiích. GPT, což je něco jako GUID Partition Table, je současný typ tabulky navržený pro moderní disky a zahazuje zbytečnou složitost a limity z MBR, tedy třeba pracuje přímo s LBA značením a téměř nemá limit na počet primárních oddílů na jednom disku, kteréžto v MBR mohly být pouze maximálně čtyři. No a standardizace pro bootování zavádí zvláštní oddíl s id 0xEF, často označovaný jako ESP (EFI System Partition), na kterém je možné specifikovat různé způsoby spouštění OS.

Trochu smutné na tom je, že se tyhle věci ale nedějí úplně automaticky a může být pro někoho matoucí, jak vlastně takový UEFI multiboot připravit, pokud má úplně čisté disky. Tenhle příklad vychází ze skutečnosti, kdy mám na služebním počítači na primárním NVM disku Fedoru 30 a sem tam by se hodilo mít k dispozici pevnou instalaci Kali a taky OpenBSD na druhém, SATA připojeném disku. A tady je to docela zajímavé, protože live boot Kali, nebo i jeho následná přímá instalace, nijak automagicky s UEFI nepočítá, jinými slovy, při zrychlené instalaci není možné Kali z UEFI, natož v SecureBootu, spustit. Zajímavým způsobem se to dá chvilkově obejít otiskem obrazu CD na disk, podobně jako je popsaný postup pro USB, přičemž se zbytek dá využít v union-režimu jako persistentní úložiště. To je docela bezva do chvíle, než je potřeba v rámci rolling distribuce aktualizovat kromě všech normálních balíčků i jádro — to totiž v okamžiku bootu reziduje pouze na té ISO 9660 určené jen ke čtení, takže zůstává stejné jako v okamžiku vytvoření obrazu. Takže jak na to?

Asi nejsnazší je pustit nějaký stávající systém, nebo tady pro ilustrativní virtuální účely živé Kali z CD. Tím se totiž otevře možnost pracovat s dosud čistým diskem, který je zde označen jako /dev/sda. Použití moderního distra hodně zjednoduší a zpřímočaří možnosti, takže než složitě operovat s BSD fdiskem, tady stačí hezky pseudograficky zavolat cfdisk /dev/sda nad čistým diskem a následně jen vybrat odpovídající novou tabulku, tj. gpt. Pokud by disk čistý nebyl, zase se to dá nahradit smazáním jeho prvních sektorů něčím jako dd if=/dev/zero of=/dev/sda bs=512 count=1 a je vymalováno. Protože je tedy v plánu mít tento disk v dualboot režimu Kali a OpenBSD, budou vytvořeny nové oddíly tak, aby to bylo co nejsnažší na používání — na začátku bude krátká oblast, řekněme 100MB, určená pro systém EFI, který se následně vybere v nabídce Type, jako je na posledním obrázku. Ostatní oblasti jsou vybrány pro standardní placatou instalaci Linuxu, tedy cca 1 GB pro /boot, oblast o velikosti 1-2 násobku RAM jako swap a zbytek v rozumné míře jako jedna oblast pro celý linuxový systém, tedy /. Pro OpenBSD postačí mít jen jeden oddíl, jelikož OpenBSD jede na dvě vrstvy a kromě tabulky oddílů pak ještě používá disklabel, který se rozdělí zvlášť. Oblast OpenBSD data je zase možné vybrat v nabídce typů a její id je 0xA6.

Tyhle změny stačí jen zapsat a pak už může následovat pokus o instalaci prvního systému, kterým bude v tomto případě Kali. Na obrázcích je obsažen grafický instalátor v režimu expertgui, na kterém bude zkrátka možná snazší se lépe orientovat. Pr připomenutí první obrázek ukazuje původně prázdý disk s inicializovanou GPT a následující už zachycují jednotlivé kroky při výběru rozdělení disků.

Je dobré si uvědomit, že pokud je v počítači ještě jiný disk (v reálném stroji na NVM s Fedorou), zřejmě zde bude rozpoznán a instalátor se pokusí některé jeho oblasti automaticky (ESP, swap) použít, případně nabídnout nahrazení nebo aktualizaci systému samotného, přičemž Fedora je typicky postavená na LVM svazku, což v ilustrativních screenech nepřekáží. Odpovídající oblasti je nutné správně přiřadit k novému systému a změny zapsat pouze na odpovídající disk. Posledním krokem manipulace s disky je pak instalace GRUBu v režimu UEFI, který se ptá, zda se má vytvořit speciální záznam, nebo se má použít výchozí standardní cesta \EFI\boot\, která bude zajímavá právě v případě OpenBSD. Pro Kali stačí vybrat Ne a vytvoří se záznam UEFI kali, jak je vidno dále.

Výběr položky kali vyvolá GRUB, který, ač byl umístěn izolovaně jen na jeden disk, může v rámci detekce jiných systémů ukazovat možnosti spuštění OS i z jiných disků, což je určitě zajímavé na zamyšlení, třeba zda by toho šlo využít v případě nějakých komplikací. Určitě šlo. Co je ale důležité, prohlédnout si nově vytvořený obsah ESP, viz třetí obrázek výše. V EFI se vytvořila cesta \EFI\kali a jako binárka zde leží 64bitový GRUB.

V tuhle chvíli je možné systém vypnout (nebo spíše jen restartovat) a pro účely pohodlí na chvíli přehodit do klasického BIOSového režimu, tedy v závislosti na tom, zda se instalace OpenBSD bude provádět z flashdisku, nebo z CD.  Tak jako tak, v okamžiku, kdy instalace dojde k výběru rozložení disku, stačí vybrat ten s Kali a díky přípravě by už měla být vidět OpenBSD slice, kterou stačí vybrat. Teprve nad ní se spustí disklabel a nechá uživatele zvolit velikosti vnitřních oblastí a vytvoří správné přípojné body. Pokus někdo spekuluje o tom, proč se to tady jako děje, je to z toho důvodu, že OpenBSD má v rámci bezpečnostních mechanismů celou řadu mountovacích příznaků pro jednotlivé oblasti, které by rozhodně měly být zachovány v produkčních systémech. 

Podpora UEFI startu pro OpenBSD byla přidána někdy, tuším, ve verzi 6.2 s drobnou nepohodlností. Všechno se to ukáže při přepnutí se zpět do UEFI režimu a SecureBootu a startu řekněme toho nového Kali a opětovného prozkoumání ESP.

V ESP nyní kromě kali existuje položka boot, která je víceméně výchozí a OpenBSD ji použilo pro svůj zavaděč. Tohle může být matoucí jak při nativním výběru systému z UEFI rozhraní, nebo taky při nějakých čachrách a instalacích dalších příšer, které tuto cestu mohou přepsat. Proto ta klička s tím, že se vytvoří nová cesta, do které se dá zavaděč OpenBSD zkopírovat pod nějakým rozumným označením a následně aktualizace tabulky firmwaru začarováním efiboormgr --create --disk /dev/sd{písmeno disku} --part {oddíl, číslováno od 1} --label “Čitelný popisek” --loader “\EFI\{Cesta}\BOOTX64.EFI”. Měl by se vypsat aktualizovaný seznam všech možností, což je v případě ilustračního virtuálu v pořadí výchozí cesty (\EFI\boot\) na prvním pevném disku, optické mechaniky, sítě, možnosti EFI shellu, vlastní nabídky s označením kali a vlastní nabídky s označením OpenBSD. Pohodka. Vše zmíněné by pak mělo být vidět po restartu a pokusu o výběr zařízení pro boot.

Pokud naskočí zavaděč OpenBSD, je prakticky vyhráno a druhý nový systém naběhne, jak má. Poněkud nepraktické na tom je, že v tomhle stavu nemusí být na skutečných počítačích správně rozpoznané řadiče, a tedy cesta bootloaderu bude ukazovat na špatné zařízení, ale i tomu se dá pomoct pozdějšími pokročilými úpravami.

UEFI zkrátka není žádná magie a není třeba se toho obávat, je to mechanismus, který má spíše více užitku než zmatení, tedy za předpokladu, že se s ním zachází správně. Ale to je už věc druhá. Taky by bylo jistě přínosné někdy povídat o samotném OpenBSD, jenže ono zkrátka funguje a tak nějak spoustu věcí je tam sebevysvětlujících, takže nevím a jen se tetelím a doufám, že jednoho dne vymýtíme všechny záhady do jedné.