Zavedení linuxového jádra

Zavaděč (angl. loader), je ve své podstatně jednoúčelový operační systém, který má za úkol:

1. natáhnout do paměti počítače jádro (angl. kernel) operačního systému,
2. a při spuštěním předat případné parametry.

Podporuje-li síťové rozhraní stroje PXE, nic dalšího zavaděč nepotřebuje, protože si vše potřebné dotáhne po síti. Ovšem pokud stroj síťové připojení k dispozici nemá, musí obsahovat moduly, které mu umožní identifikovat lokální blokové zařízení a přečíst souborový systém na kterém je uloženo.

Jádro se od zavaděče liší tím, že po spuštění zůstane v běhu a na základě příkazů z prostředí operačního systému obsluhuje hardware. Zavaděč jádro si ho z úložiště vytáhne ve formě samorozbalovacího archívu, jehož jméno podle obvyklého úzu začíná řetězcem vmlinuz, ale může se jmenovat libovolně. Podstatné je pouze to, aby ho zavaděč v rámci souborového systému úložiště našel. Při spuštění..

1. ..se rozbalí do paměti a převezme od zavaděče případné konfigurační volby.
2. Následně se pokusí identifikovat a připojit úložiště, kde je operační systém,..
3. .. a z něj spustit spouštěč dalších procesů - init.

RAM disk

Monolitické jádro

Má veškeré potřebné ovladače na tvrdo zakompilované do jádra. Může být velmi malé a výkonnější než jádro modulární, ale pro diskless vhodné není.

Modulární jádro

počítá s tím, že se kromě jádra vybalí do RAM také tzv. RAM disk, který kromě modulárních ovladačů může obsahovat také skripty a další software potřebný k připojení systémového disku. Má zakompilované jen základní ovladače, potřebné k jeho rozbalení a připojení. Další moduly se do jádra zavádějí jen když jsou zatřebí. Použití je tedy mnohem flexibilnější. Součástí ramdisku totiž mohou být i nástroje co umožňují řešit problémy, které se vyskytnou během zavádění - proto je následující manuál věnován práci v prostředí ramdisku.

UEFI

O spuštění zavaděče se dříve staral BIOS, ale Microsoft, který formou vázaného prodeje masově propagoval MS Windows, si od verze 8 vynutil UEFI do kterého protlačil ověřovací mechanismus – tzv. secure boot – který před zavedením kódu kontroluje, zdali je podepsán "tím správným klíčem", protože jedině tak byl schopen zajistit tomu, aby zavaděč do RAM natáhnul infikovaný kernel. Uživatelům linuxu, to ale přineslo jen další opruz – obzvláště v mezidobí, kdy měly některé stroje dodané s MS Windows UEFI, u kterého nebylo možné secure boot vypnout.

Zavaděče používané v rámci disklessové infrastruktury DC a DCE

V současné době se pro zavádění po síti využívají tyto zavaděče:

pxelinux

Je zavaděč, který jsme dlouhé roky využívali jak pro zavádění přes Legacy PXE (pxelinux.0), tak pro zavádění přes UEFI PXE (syslinux.efi). Jeho předností byla jednoduchá konfigurace a hlavně to, že se v obou případech pracovalo se stejnými konfiguračními soubory. Jenže vývoj této aplikace skončil v roce 2014 u novějších laboratorních strojů, pořízených v září 2019, už nebylo možné tenhle zavaděč používat, protože neumí při zavádění přes UEFI použít APCI pro vypnutí. Přesto se, v rámci disklessové infrastruktury DCE a DC, tenhle zavaděč dál využívá pro zavedení jádra přes Legacy PXE. Na výsledek zavádění použitý zavaděč nemá vliv, protože se konfigurace už nepředává coby parametr linuxového jádra jako kdysi. Jádro si ji stahuje do ramdisku až na základě toho, co přidělí DHCP.

Zavádějí se takto i některé virtualizované stroje, aby se QEMU nemusel předávat lokální blob s UEFI.

GRUB2

U laboratorních strojů zaváděný přes UEFI PXE se využívá grubnetx64.efi, protože umí vypínat stroje přes ACPI. Kromě toho lze v rámci souboru grub.cfg využít skriptování, takže se udržuje pro všechny stroje pouze jeden konfigurační soubor.

Výhodné je i to, že se dá proces zavádění přerušit a mít k dispozici všechny funkcionality, jako má lokálně instalovaný zavaděč, takže je možné opravit i stroje s poškozeným lokálním zavaděčem.

A je to výhodné i pro testování, protože lze vygenerovanou položku pro zavedení disklessového systému podle potřeby doplnit o parametr, který se má před spuštěním předat jádru.

Zavádění po síti

Zavádění po síti má oproti lokálnímu zavádění především tu výhodu, že můžeme operativně měnit zaváděné soubory, aniž by bylo nutné cokoliv instalovat na lokální disk, protože se zavaděč stáhne z úložiště do RAM po síti přes Preboot Execution Environment – PXE, což je funkcionalita firmware síťové karty.

Podmínkou je funkční a spolehlivá síť. Také zavaděč s podporou PXE, aby mohl po síti do RAM natáhnout linuxové jádro s ramdiskem.

PXE

Funguje to tak, že..

1. Ethernetové zařízení, které podporuje PXE, vyšle do sítě broadcastový paket
2. Ten odchytí DHCP server. Vyhledá pro MAC adresu ze které byl paket odeslán odpovídající konfiguraci a vrátí zařízení, které paket vyslalo zpět informace nezbytné pro nastavení sítě. Mezi nimi může být i adresa TFTP (či HTTP) serveru a cesta k zavaděči, kterou lze v konfiguraci DHCP měnit na základě identifikátoru PXE klienta, předaného v proměnné vendor-class-identifier
3. PXE klient nastaví síť a předá získané informace BIOSu/UEFI, který skrze ni natáhne do RAM zavaděč a dál již pokračuje zavádění v jeho režii.
4. Zavaděč, má-li podporu PXE, si natáhne přes TFTP konfigurační soubor a případně i další moduly, nezbytné pro zavedení operačního systému.

Pokud má zařízení k dispozici lokální blokové zařízení, na kterém je nainstalován zavaděč, nepotřebuje ethernetové zařízení s podporou PXE, ani DHCP server, protože konfiguraci sítě lze jádru předat prostřednictvím konfiguračního souboru zavaděče ještě před zavedením jádra do RAM.

UEFI PXE

Funguje úplně stejně, jenom se posílá jiný identifikátor.

A pokud není v nastavení UEFI pracovní stanice vypnutý secure boot, lze spustit jen kód zavaděče podepsaný Microsoftem.

Lokálně instalovaný zavaděč

Je nutný u Half-Diskless strojů, které musí být schopny najet i bez ethernetové konektivity. V současné době se se používá převážně GRUB2, který má zaváděcí proces velmi podobný tomu, jak funguje zavádění linuxového systému. Také spuštěný binární kód zavaděče musí mít k dispozici ovladače, které mu umožní spuštění zaváděcího procesu. Kromě jádra zavaděče to musí být:

1. modul, který rozpozná lokální blokové zařízení
2. modul, který umí přečíst tabulku rozdělení disku
3. a modul, který umí načíst data z jeho souborového systému

Pokud něco z toho chybí, zavádění selže. U starších zavaděčů to většinou znamenalo fatální problém, ale GRUB2 je modulární a přes integrovaný shell lze konfiguraci, ještě před spuštěním zaváděcího procesu, v takovém případě upravit.

Umístění lokálně instalovaného zavaděče

BIOS

V legacy módu se načítá první sektor blokového zařízení (tzv. MBR - Master Boot Record), kde je informace o tom, odkud a kolik bajtů dat má natáhnout do paměti – pokud ji BIOS najde, načte z ní do paměti zavaděč, kterému předá řízení.

Kód zavaděče, včetně ovladačů, se musí vejít do prostoru mezi tabulkou rozdělení disku a začátkem prvního diskového oddílu.

Sestavuje se na míru, při instalaci. V podstatě obsahuje pouze jádro zavaděče, základní moduly a ovladače, které zpřístupní adresář kde jsou uloženy ostatní moduly. Zbytek se dotáhne až na základě konfiguračního souboru grub.cfg (GRUB legacy používal menu.lst).

Pokud se používá pro zavádění BIOS je třeba hlídat aby: sahal při zavádění na správné zařízení použité disky ve stroji neměly v MBR nějaké zbytkové záznamy, které by mohly zmást BIOS byla po aktualizaci zavaděče aktualizována také část, která je uložena na blokovém zařízení, odkud ji načítá BIOS Chybí-li ovladač v jádře zavaděče, potřebný pro zpřístupnění souborového systému se zbývajícímu moduly, pak nelze problém vyřešit jinak, než pomocí zavedení prostřednictvím jiného zavaděče a nebo opravou záznamu na blokovém zařízení přes chroot z prostředí linuxového live CD.

UEFI

Počítá s tím, že je zavaděč umístěn na diskovém oddíle efi se souborovým systémem FAT. Slabinou tohoto souborového systému ovšem je, že na něj může zapsat každý uživatel, proto zůstává v prostředí MS Windows tenhle diskový oddíl skryt, aby si BFU nějakým nedopatřením nerozbil zavádění.

Sestavení sendviče a zavedení systému

Pokud disklessový systém nenajíždí a zůstává viset v ramdisku, je na 99.99% chyba někde jinde, než v disklessové infrastruktuře

• • V jedné laboratoři se proprietární binární aplikace pro vizualizaci molekul hroutí, ale v jiné funguje normálně – tahle situace řešení nemá, protože ji způsobuje zastaralý integrovaný grafický čip, kterému chybí požadovaná instrukce.
  • Disklessové turtleboty, které komunikují přes Wi-Fi, měly problém s tím, že nenašly připojení. Ukázalo se, že je „na vině” funkcionalita 5G sítě která způsobuje, že stroj po nahození wifi prozkoumává okolní síť, což při vyšším zatížení sítě vedlo k timeoutu a přerušení zaváděcího procesu. – Řešení problému bylo komplikované mimo jiné i tím, že tyhle stroje nemají klávesnici, která by umožnila při takové situaci zkontrolovat co se děje v ramdisku.

Když systém nenajíždí...

...a zůstává viset v ramdisku, nebo s černou obrazovnou, jsou na místě následující otázky:

• Co je jinak?
• Týká se to všech strojů, jenom jednoho a nebo se to děje náhodně?
• A ty stroje, u kterých se to děje, jsou zcela nové, nebo již používané?

V tom musíme mít jasno a pokud se ten problém týká jen určité skupiny strojů, je potřeba najít společného jmenovatele.

Snaží se stroj po zapnutí použít PXE?

Pokud ne, může být příčinou reset BIOSu, po kterém se nastaví do výchozího (default) nastavení. A to se může dost lišit, podle typu stroje:

• U některých strojů BIOS/UEFI v defaultu najíží jen z lokálního blokového zařízení. Takový stroj se ani nesnaží použít PXE, ale rovnou najíždí lokálně instalovaný operační systém – pokud ho má k dispozici.
• U některých typů od HP je default UEFI, které má aktivní secureboot. Stroj sice použije UEFI PXE, zavádění se zdá normální, ale secureboot nedovolí stažené linuxové jádro spustit, proto začne startovat lokálně instalovaný operační systém – pokud ho má stroj k dispozici.
• U starších strojů fy. Dell, které měly jako default standardní BIOS, bylo vypnuto UEFI, takže místo UEFI PXE (které obsluhuje GRUB2) startovaly přes Legacy PXE (které obsluhuje pxelinux) – zde bylo řešení jednodušší. Varianta zavádění přes pxelinux nebyla odstavena, tak jak to bylo původně v plánu, ale konfigurace upravena tak, aby se zavádělo aktuální jádro. Stroje totiž zůstávaly „viset” jen kvůli tomu, že se spouštělo již zastaralé linuxové jádro.

Nejčastější příčinou problému jsou studenti. Vytahují napájecí kabely laboratorních strojů ze zásuvek aby si mohli zapojit adaptéry svých notebooků a nechápou, že pokud ten stroj nemá napájení, dodává energii pro udržení systémového času a nastavení BIOSu jen malá knoflíková CMOS baterie, která není věčná a čím častěji a déle je takový stroj bez proudu, tím dříve odejde. Takže u staršího stroje může i relativně krátká doba bez vnějšího napájení vést k tomu, že se jeho BIOS ocitne ve výchozím stavu.

Proto je třeba sledovat, co dělá stroj po spuštění a pro jistotu spustit i stroj jiný a sledovat i jejich chování. Pokud se oba budou chovat stejně, použijí PXE přes které stáhnou linuxové jádro, ale po spuštění zůstanou viset v ramdisku, je velmi pravděpodobné, že je nějaká chyba v konfiguraci.

A k tomu už musíme vědět odkud stroj stahuje svou konfiguraci a na základě čeho. V prvé řadě tedy zkontrolujeme zda není chyba:

• v NFS exportu, nebo..
• v konfiguraci zavaděče, který může spouštět jinou verzi jádra, než s jakou se počítá v zaváděném systému

Za normálního provozu je prakticky vyloučeno, že by chyba byla právě zde, protože se odladěná konfigurace nemění, ale během přípravy nové verze systému se taková chyba snadno vloudí, proto je důležité vědět, jaký konfigurační soubor stroj stahuje, abychom zjistili z jakých vrstev se skládá systémová sendvič.

Konfigurace se stahuje v ramdisku, skriptem nfsroot a ukládá jako soubor /run/nfsroot a na stejném místě je k nalezení i ve spuštěném systému, ale tam ho může číst jen superuživatel a je potřeba znát heslo lokálního uživatele root aby se na něj dalo přepnout:

~$ su -
~# grep ^# /run/nfsroot
...

Místo utility grep lze samozřejmě použít i běžný editor. V konfiguraci jsou i různé komentáře, které nám umožní zjistit co vlastně stahujeme. Chyba totiž může nastat i na straně TFTP serveru. Po zavedení jádra totiž může stroj získat obecnou konfiguraci, která se stahuje na základě IP adresy brány, ale také svou vlastní specifickou konfiguraci, která má vyšší prioritu a stahuje se buď: na základě parametru name=, předaného jádru zavaděčem, nebo.. na základě hostname, který stroji přidělí DHCP server

Pokud máme podezření, že si stroj stahuje jinou konfiguraci než by měl, můžeme jádru předhodit parametrem name= jiný konfigurační soubor, protoře má přednost.

Lze to udělat tak, že se přeruší odpočítávání zavaděče GRUB2, pomocí klávesy ↑ nebo ↓, a když najedeme na příslušnou položku, otevřeme klávesou e obsah k editaci. Ten výchozí vypadá obvykle takto:

linux /boot/vmlinuz boot=nfs root=/dev/nfs
initrd /boot/initrd.img

Ale může se lišit, pokud se natahuje jiná než výchozí verze jádra. Pokud se konfigurace stahuje na základě parametru name=, obsahuje název konfiguračního souboru, bez přípony .conf Pokud tenhle parametr chybí, a chceme najet výchozí konfiguraci, použijeme IP adresu DHCP serveru v rámci příslušného subnetu. Např.:

linux /boot/vmlinuz boot=nfs root=/dev/nfs name=192.168.1.18
initrd /boot/initrd.img

TFTP server pracuje se symlinky, takže soubor /srv/tftp/192.168.1.18.conf v úložišti může být ve skutečnosti symlink, který odkazuje na jiný soubor.

Ověřujeme konfiguraci

Pokud zavádění zůstává viset v ramdisku, musíme zkontrolovat co se děje před spuštěním – to je opět spojeno s úpravou konfigurace zavaděče před zavedením jádra. K dispozici je hned několik bodů přerušení, které umožňují zjistit, kdy přesně nastává problém. Více o nich bude řeč v kapitole Práce v ramdisku. Ale pro základní ověření situace stačí:

linux /boot/vmlinuz boot=nfs root=/dev/nfs break=init

Tím přerušíme zavádění těsně předtím, než dojde k zavedení systému z již sestaveného sendviče. Pokud je vše ok, a vyskočíme příkazem exit, pokračuje jádro spuštěním systému, ale pokud je někde chyba může systém skončit ve stavu, který vyřeší jen vypínač

Výchozí položka v souboru grub.cfg

Half-Diskless stroje disklessové infrastruktury, které využívají lokální blokové zařízení pouze k uložení nakešovaných vrstev, mají jednoduchou konfiguraci:

...

V obou případech se odkazuje na symlink, který se operetivně mění, podle verze nakešovaného ramdisku a jádra uvedené v konfiguraci zaváděného systému.

Uvědomte si, že při aktualizaci na novější verzi jádra stahuje aktualizované soubory na lokální úložiště jádro předchozí. Nové jádro se tedy použije až po restartu.

---