Diskless UEFI boot

25.10.2018 19:32 | Přečteno: 3553× | Za vším hledej Linux | | poslední úprava: 26.10.2018 14:02

Tak pravidelné krizové období, které – tak jako každý rok – vrcholí na přelomu září a října, máme konečně za sebou. Letos bylo obzvláště vypečené. Obvykle začíná počátkem srpna a je tak dost času na to, přijít na kloub všem záludnostem, které si aktualizace disklesového systému, nebo nějaká jiná změna vyžádá. Letos tomu bylo jinak. Ještě týden před začátkem semestru byla jedna z laboratoří na DCE staveništěm a nový server na který se měla přestěhovat disklessová infrastruktura na DC, dorazil až 21.9. v pátek odpoledne, a ne v polovině srpna, jak bylo původně v plánu. Ale o tom, tenhle blogpost nebude.

Úvodem…

Kromě serveru dorazila i hromada nových strojů. Na DC se v laborkách používá jenom linux, takže tam nebyl žádný problém. V se v biosu nastavilo výchozí zavádění přes legacy PXE a lokální rozdělení disku, včetně UEFI partice se kompletně zrušilo. Na DCE je tomu jinak. Tam se používají kromě disklessového linuxu také lokálně instalované MS Windows.

Nostalgické okénko

Když jsem před 10 lety na DCE nastoupil, byl disklessový linux v plenkách. Na strojích byl lokálně nainstalován GRUB, který měl podporu pro natažení linuxového jádra a ramdisku po síti. Tohle řešení ale mělo několik pih na kráse – starý GRUB nebyl modulární a musel mít "zadrátovaný" ovladač síťové karty. A s novými počítači přicházely i novější verze síťových karet, pro které bylo nutné dopsat pro starý GRUB nové ovladače.

Od r. 2009 začal v distribucích starý GRUB nahrazovat GRUB2. Ten sice bylo možné natáhnout přes PXE a uměl si také dotahovat přes TFTP další moduly, ale nedalo se přes něj zavést linuxové jádro. Vyřešil jsem to tehdy tak, že jsme začali disklessový linux zavádět přes PXELINUX, a pro zavádění lokálních Windows se jeho prostřednictvím natahoval GRUB2, spouštěný přes PXE. Přes GRUB2 totiž bylo možné před zavedením lokálních Windows přepnout u jednotlivých diskových oddílů typ souborového systému a díky tomu zavádět z jednoho disku různé verze MS Windows, aniž by o sobě vůbec tušily a hrabaly si na data. Pamětníci dobře vědí, jak problematické bývalo soužití některých softwarových balíků v rámci jednoho systému MS Windows – a tohle byl způsob, jak se tomu vyhnout.

S nástupem SSD disků, které měly omezenou kapacitu začal být tenhle luxus zbytečný. Navíc – komu by se chtělo udržovat tolik verzí MS Windows. Takže se změnila výchozí volba na prostý chainload na MBR lokálního disku, odkud se spouštěl lokální systém a zavádění přes GRUB2 se zrušilo.

Upřednostnit UEFI nebo legacy PXE?

S příchodem nových strojů se objevil nový problém. Lokální systém měl být nainstalován na NVME disky a to by u MS Windows 10, pokud by měly startovat přes legacy boot, znamenalo nepřiměřený konfigurační opruz.

Zapnutý legacy mód sice u těchto strojů umožňuje zavádění disklessového systému přes legacy PXE i zavedení lokálního systému přes UEFI. Jenže PXELINUX, zavedený přes legacy PXE neumí spustit UEFI Window Boot Manager – proces zavádění v takovém případě kolabuje s tím, že není k dispozici blokové zařízení ze kterého by bylo možné spustit lokální systém. Pokud bychom tedy měli zavádění přes legacy PXE nastaveno v bootovacím menu jako výchozí volbu, tak bychom se vůbec k zavedení lokálního systému nedostali.

Na druhou stranu, pokud bychom měli jako výchozí volbu pro zavádění lokální boot přes UEFI Windows Boot Manager, tak bychom museli zajistit, aby každý uživatel, který by chtěl najet do prostředí disklessového linuxu, věděl, že si může vynutit boot přes legacy PXE při spouštění stroje stiskem klávesy F12. Pak ovšem musíme do PXE menu přidat jako výchozí položku, která po určitém časovém intervalu provede reboot – aby se i uživatel, který náhodou při spouštění stisknul klávesu F12, dostal na lokální Widle a nekoukal jak vyoraná myš na PXE menu, nevěda kudy dál.

Jenže tohle řešení má zcela fatální nedostatek. I kdyby nakrásně uměl lokální systém zavedený přes UEFI zareagovat na WakeOnLan, přes které bychom ho mohli vzdáleně donutit k restartu, jen stěží bychom si při spouštění stroje mohli vzdáleně zmáčknout klávesu F12.

Takže z praktického hlediska bylo lepší nastavit jako výchozí volbu "UEFI Network PXE Boot" a systém zavádět před UEFI.

Secure Boot

Z mého pohledu jde o zbytečný opruz. Klíčový problém SecureBootu totiž je, že pokud je aktivovaný, lze zavádět pouze bloby podepsané Mrkvosoftem.

Pro hardcore flagelanty existuje řešení – preloader shim, který tuto podmínku splňuje a sám pak umožňuje zavádět bloby, které si podepíšete sami svým vlastním certifikátem. Pokud tedy milujete certifikátové porno, můžete vyrazit tímto směrem.

Proč si ale otravovat život, když se dá Secureboot vypnout, že?

Pokud nevíte jak, navštivte stránku Managing EFI Boot Loaders for Linux: Dealing with Secure Boot, kde má Rod Smith, několik screenshotů, na kterých demonstruje, kde se dá vypnout. A má tam mimo jiné i stránku pro ty, co by přeci jen chtěli Secure Boot používat.

O tom, jak vypnout Secure Boot zde před dvěma lety napsal blogpost doplněný screenshoty, také Grunt. Bios našich strojů od HP vypadá zase trochu jinak.

Lze se do něj dostat kupř. tak, že při spouštění stroje stisknete klávesu Escape, která vyvolá spuštění Startup menu, ze kterého si můžete vybrat co vlastně chcete. Ve výchozím stavu bios zaheslován není. U zaheslovaného biosu musíte po volbě Bios Setup zadat také heslo.

V nastavení biosu se musíte přepnout na záložku "Advanced" a kliknout na položku "Secure Boot Configuration". Zde je nutné změnit aktuální nastavení na "Legacy Support Disable and Secure Boot Disable". Po kliknutí na "Exit" se vás stroj zeptá, jestli má změny uložit, což potvrdíte a necháte stroj restartovat.

Před restartem byste totiž mezi položkami v "UEFI boot order" nemuseli položku "Network boot" najít. Při vypnutí Secure Bootu si od vás může bios vyžádat pro potvrzení číselný kód – musíte opsat číselný pin, který vám zobrazí na monitoru. Je-li akceptován, oznámí stroj zvukovým signálem.

Při restartu opět stisknete klávesu Escape, opět skočíte do nastavení biosu, opět přepnete na záložku "Advanced", ale tentokrát kliknete na položku "Boot Options":

Na screenshotu můžete je vidět, jak vypadá nastavení připravené k uložení. Povolen je pouze "Network (PXE) Boot" a ve menu "UEFI boot order" je položka "Network boot: IPv4 Network" přesunuta na první pozici – hned za ní následuje lokální "Windows Boot Manager". Ostatní položky můžete klidně vypnout.

Poznámka: After Power Loss jsem změnil na Power On, pro případ, že by lokální systémy neuměly spolupracovat přes WakeOnLan – v takovém případě si pak bude možné vynutit hromadný restart všech strojů vypnutím el. proudu.

Volba zavaděče

Předchozí postup nastavení se týkal pracovních stanic, které je nutné postupně oběhnout a nastavit. Naštěstí to stačí udělat pouze jednou. Nyní je na místě se rozhodnout, přes co bude UEFI na pracovních stanicích zavádět operační systém. Máte totiž na výběr hned několik možností:

syslinux.efi – Se určitě vyplatí, pokud již používáte PELINUX, protože můžete použít stejné konfigurační soubory jako při zavádění přes pxelinux.0 u legacy PXE. Ale u nových strojů byl klíčový problém v tom, že PXELINUX umí vypínat počítače pouze přes APM, které novější stroje nemají.

grubnetx64.efi – GRUB2 je mocný nástroj, který nabízí oproti ostatním alternativám mnohem širší paletu možností pro to, co lze se strojem a jeho disky před vlastním zavedením operačního systému udělat. To klade mnohem větší nároky na správnou konfiguraci a zabezpečení položek v souboru grub.cfg, což není triviální – obzvláště pro ty, co obvykle spoléhají na výstup, který vyzvrací grub-mkconfig a nechápou co všechno lze přes příkazový řádek GRUBU2 dělat.

ipxe.efi – iPXE toho oproti oběma výše uvedeným nabízí samo o sobě mnohem méně. Na druhou stranu lze jeho prostřednictvím zavádět operační systém po síti i na strojích co nemají síťovou kartu s podporou PXE. A podporuje také víc síťových protokolů – nejenom PXE a TFTP, ale také HTTP, iSCSI, AoE, FCoE, aj. Osobně jsem s ním nikdy nepracoval, proto vás mohu pouze odkázat na stránku kde můžete najít příklad použití.

Nejdřív jsem zkoušel rozchodit zavádění přes syslinux.efi, pak padla volba na GRUB2, abychom se nakonec opět vrátili k PXELINUX. Proč?

Původně se naše disklessová infrastruktura používala pouze u dvou laboratoří. Obě bootovaly přes PXE a v obou byly pouze 64 bitové stroje – proto jsem umístil soubor pxelinux.0 a jeho základní moduly tenkrát umístil rovnou do kořenového adresáře TFTP serveru. Jenže syslinux.efi používá pro své moduly stejná jména – nejspíš proto, aby bylo možné používat stejné konfigurační soubory. A pokud byl rovněž umístěn do kořenového adresáře, kolaboval na nekompatibilním modulu libutil.c32 Až později jsem zjistil, že cesty, které má syslinux.efi natvrdo nastavené jsou relativní nikoliv vůči kořenu TFTP serveru, ale vůči TFTP cestě, ze které byl soubor syslinux.efizaveden.

Zkusil jsem tedy použít GRUB2. Jak už jsem zmínil v historickém okénku, GRUB2 zaváděný přes PXE jsme již v minulosti používali, takže s ním mám jisté zkušenosti. Pozitivní bylo, že oproti PXELINUXU uměl nové stroje vypnout. V konfiguračním souboru lze psát vlastní funkce, používat podmínky, konfigurovat a používat vlastní proměnné. Také zabezpečení jednotlivých položek v menu funguje pěkně… Jenom to zavádění linuxového jádra přes UEFI PXE stojí upřímně řečeno za starou belu.

Jako obvykle za tím bude nejspíš nejaká prkotina, ale ve srovnání s ním nabízí zavádění přes syslinux.efi mnohem větší komfort – přinejmenším informuje o tom, co zrovna dělá. A uživatelé také mají mnohem menší šanci jeho prostřednictvím nabourat lokální systém.

Nastavení DHCP serveru

Předesílám, že pokud nemáte přístup k DHCP serveru a TFTP serveru, tak toho moc nenaděláte. U nás máme pro DHCP laboratoří samostatný virtuální stroj, který neřeší nic jiného. Virtualizace je v tomto případě velice výhodná, protože každé rozhraní virtuálu visí na samostatné VLAN a není problém si pro každou další VLAN udělat nové síťové rozhraní. Také to usnadňuje testování – stačí pak přes tcpdump monitorovat síťový provoz pouze na příslušném rozhraní.

Testovací prostředí

Ideální je, když máte na svém DHCP serveru k dispozici testovací subnet, na který si můžete navěsit virtuál, se kterým si můžete hrát. Naše disklessová infrastruktura je postavená na virtuálních strojích, které lze ovládat z příkazové řádky. Následujícím příkazem spouštím testovací stroj, navěšený na VLAN č.54, kterou také obsluhuje můj DHCP server. O vytvoření portu na virtuálním openvswitchi se starají dva pomocné skripty – jeden nahazuje příslušný port a druhý ho při vypnutí ruší:

qemu-system-x86_64 -daemonize -S -bios OVMF-pure-efi.fd -machine accel=kvm -name tester -cpu kvm64 -M pc-q35-2.6 -m 4096 -spice port=7123,password=tester -qmp telnet:localhost:12123,server,nowait -monitor telnet:localhost:11123,server,nowait -netdev tap,id=tap.0,ifname=int-test-54,script=/etc/openvswitch/ovs-ifup,downscript=/etc/openvswitch/ovs-ifdown -device virtio-net-pci,mac=be:be:be:00:71:23,netdev=tap.0 -serial file:/var/log/kvm/tester.serial

Při testování UEFI PXE musíte přes parametr -bios předhodit soubor OVMF-pure-efi.fd, který si můžete vykuchat z balíku edk2.git-ovmf-x64 (ke stažení na adrese https://www.kraxel.org/repos/jenkins/edk2). Bez toho se QEMU pokusí zavést systém přes legacy PXE.

Parametr -S zajistí, že se virtuální stroj spustí v pozastaveném stavu. Je to proto, aby bylo dost času na připojení vzdálené plochy přes spice klienta – dokud qemu neběží, tak se ni připojit nelze a bez toho by se vám nemuselo podařit odchytit začátek zaváděcího procesu.

Po připojení spice klienta se mohu připojit telnetem na monitorovací konzoli virtuálu a pak jej dle libosti spouštět, pauzírovat nebo restartovat.

Identifikátor PXE klienta

Každý DHCP klient zahajuje svoji komunikaci s DHCP serverem tím, že na něj pošle síťový paket, jehož součástí je identifikátor, v konfiguraci DHCP dostupný přes option vendor-class-identifier. Z něj lze vyčíst, kdo se ptá a na jaké architektuře běží. Tuto komunikaci můžete sledovat přes tcpdump. U mne běží VLAN 54 přes eth5, takže spustím:

tcpdump -vvv -i eth5

…a pak odstartuji přes monitorovací konzoli virtuál. Pokud bych tuhle možnost neměl, tak bych přesměroval výstup do souboru a šel spustit reálný stroj, který mě zajímá. Pak bych se kouknul, co se zachytilo. Odchycený identifikátor vypadá takto:

…
Vendor-Class Option 60, length 32: "PXEClient:Arch:00000:UNDI:002001"
…

Pět nul signalizuje, že jde o stroj, který se dotazuje přes legacy PXE. Pokud startuje stroj, který se ptá přes UEFI PXE, vypadá identifikátor jinak:

…
Vendor-Class Option 60, length 32: "PXEClient:Arch:00007:UNDI:003016"
…

za řetězcem "Arch" následuje číslo architektury, které vychází ze specifikace RFC 4578. Zbytek, je pro náš účel víceméně nezajímavá informace.

Testovací konfigurace DHCP

Testovací konfigurační soubor pro DHCP server může vypadat kupř. takto:

############
# LABX
############
shared-network LABX {
    subnet 10.0.3.0 netmask 255.255.255.0 {
        default-lease-time 3600;
        max-lease-time 7200;
        option routers 10.0.3.1;
        next-server 10.0.3.4;
        range 10.0.3.5 10.0.3.10;
    }

    group {
        if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00007" {
            filename "/grubnetx64.efi.signed";
        } else {
            filename "/pxelinux.0";
        }
        host tester { hardware ethernet be:be:be:00:71:23; }
    }
}

Poznámka: Mohu-li doporučit, využívejte při svých pokusech s konfigurací DHCP serveru uzavření konfigurace hosta/ů do bloku group. Umožní vám to elegantně oddělit konfiguraci testovacích strojů od těch produkčních. A také vás to ušetří nemilých překvapení, s nimiž jsem se setkal při svých pokusech já.

Než jsem pochopil, jak to funguje, tak jsem přirozeně nejprve zkoušel postupovat podle postupů nalezených jinde. Informace o identifikátoru PXE klienta, které jsem vám předžvýkal kousek výše, jsem našel na FOG wiki. A tam bylo i několik příkladů jak nakonfigurovat DHCP server. Jenže tam chybělo klíčové upozornění: Nastavení class a host má globální platnost.. Co to v praxi znamená?

Především to, že je naprosto jedno kde v konfiguraci příslušnou třídu nastavíte. Uvedené příklady ve mě vzbudily dojem, že pokud nastavím příslušnou třídu (UEFI-64-1) v rámci konfigurace testovacího subnetu, tak pro žádný jiný subnet platit nebude. A skutečně to tak zpočátku vypadalo, neboť jsem řešil pouze dvě VLAN a pro obě byla konfigurace DHCP víceméně stejná.

Na svůj omyl jsem přišel víceméně náhodou a to, když jsem začal zkoumat jak použít při UEFI PXE bootu místo grubnetx64.efi.signed soubor syslinux.efi. Upravil jsem konfigurák testovací VLAN a pak si hrál s virtuálem. Najednou jsem v logu z TFTP serveru zaregistroval, že mi posílá syslinux.efi i na adresy z jiných subnetů! Naštěstí zrovna nabíhala výuka při které studenti pracovali s lokálně instalovanými MS Windows a defaultní konfigurační soubor, který jsem použil, měl v menu pouze jednu položku – zavedení lokálního systému. Takže si nikdo ničeho zvláštního nevšiml. Díky tomu jsem ale zjistil, že pro nastavení class je rozhodující poslední konfigurace, na kterou DHCP server narazí.

Až pak jsem z dokumentace vyčetl, že class mají globální platnost a pro nastavení se aplikuje ta, která vyhoví zvolené podmínce jako první. Bylo tedy nutné postupovat jinak. Výsledek můžete vidět na výše uvedené ukázkové konfiguraci.

Stejně jako class má globální platnost i nastavení host, ale ty lze seskupit přes group do oddělené skupiny pro kterou lze "přerazit" výchozí nastavení volby filename dané třídou. To se pak aplikuje na všechny stroje ve skupině, které svou konfigurací vyhoví. V případě ukázkového konfiguráku je to tedy pouze můj virtuální stroj, který má odpovídající MAC, který by dostal IP adresu z rozsahu 10.0.3.5–10

syslinux.efi

Jak už jsem zmínil, začínal jsem s ním a také jsem u něj skončil.

Celý problém byl v tom, že i když mělo teoreticky stačit v konfiguraci nastavit přes PATH jinou cestu k modulům, nefungovalo to a moje snažení bylo bezvýsledné. Proto jsem dále pokračoval v pokusech se zaváděním přes GRUB2. Teprve při sledování záznamu z TFTP serveru jsem zjistil kde byl problém.

Až když jsem začal sepisovat tenhle blogpost, upravil jsem konfiguraci TFTP serveru tak, abych mohl sledovat, co se vlastně pokouší zavaděče přes TFTP stahovat – ukecaný výstup najdete v souboru /var/log/daemon.log:

main (DHCP) :~# cat /etc/default/tftpd-hpa 
TFTP_USERNAME="tftp"
TFTP_DIRECTORY="/srv/tftp"
TFTP_ADDRESS="0.0.0.0:69"
TFTP_OPTIONS="--secure -v --verbosity 3

Poznámka: Je-li v rámci volby filename uvedeno na začátku cesty lomítko, pak je cesta absolutní, ovšem nikoliv v rámci souborového systému stroje kde běží TFTP server, ale vůči TFTP adresáři.

Při této konfiguraci TFTP serveru, tedy bude absolutní cesta k souboru efi64/syslinux.efi v rámci TFTP tftp:/efi64/syslinux.efi, ale v rámci souborového systému /srv/tftp/efi64/syslinux.efi.

Multi-Arch

V prvé řadě je nutné oddělit pxelinux.0, který obsluhuje legacy PXE, i s jeho moduly od modulů které vyžaduje syslinux.efi. Vytvořil jsem tedy v kořeni TFTP serveru dva nové adresáře. Do adresáře efi64 jsem nakopíroval soubor syslinux.efi (je v instalačním balíku … ), pak jsem upravil konfiguraci DHCP a pak přes výstup TFTP serveru sledoval co bude chtít stahovat.

Při relativním nastavení cesty prohledává syslinux.efi tato místa v uvedeném pořadí:

1. adresář ze kterého byl zaveden bere jako kořenový
2. podadresář boot/isolinux
3. podadresář isolinux
4. podadresář boot/syslinux
5. podadresář syslinux

A na závěr to ještě jednou zkusí v kořeni.

PXELINUX vyžaduje pro své fungování alespoň základní moduly, které musí být umístěny ve stejném adresáři jako zavaděč. Pro syslinux.efi:

• ldlinux.e64
• libutil.c32
• libmenu.c32
• menu.c32

Poznámka: Moduly pro pxelinux.0 se jmenují stejně a to mě mátlo – je to však proto, aby se mohl použít stejný konfigurační soubor jak u legacy PXE, tak při UEFI PXE. Při instalaci balíku syslinux-efi se soubor syslinux.efi nevloží automaticky do kořene vašeho TFTP serveru. Najdete ho v adresáři /usr/lib/SYSLINUX.EFI/efi64/ – resp. …/efi32/, podle použité architektury – a do kořene TFTP serveru ho musíte nakopírovat. Moduly pro syslinux.efi jsou v balíku syslinux-common a po instalaci je u Debianu najdete v adresáři /usr/lib/syslinux/modules/efi64/ (resp. …/efi32/).

Podobně je tomu také u zavaděče pro legacy BIOS pxelinux.0, který se instaluje v balíku pxelinux. Ten najdete v adresáři /usr/lib/PXELINUX/ a jeho moduly, které jsou rovněž v instalačním balíku syslinux-common, v adresáři /usr/lib/syslinux/modules/bios/

Zavaděče, ani jejich moduly nejsou nijak závislé na systémových knihovnách. Můžete klidně použít i soubory z jiné distribuce. A dokonce můžete beztrestně používat soubor zavaděče z balíku jiné verze než jsou ostatní moduly, ale myslím, že v takovém případě byste dříve či později narazili na nějaký problém způsobený nekompatibilitou.

Konfigurační soubory pro PXELINUX

Každý z nich hledá v adresáři ze kterého byl zaveden, podadresář pxelinux.cfg/ a v něm odpovídající nabídku:

1. Nejprve podle MAC adresy /efi64/pxelinux.cfg/01-be-be-be-00-71-23
2. Potom podle IP adresy v hexa:
   • /efi64/pxelinux.cfg/0A0003B4
   • /efi64/pxelinux.cfg/0A0003B
   • /efi64/pxelinux.cfg/0A0003
   • /efi64/pxelinux.cfg/0A000
   • /efi64/pxelinux.cfg/0A00
   • /efi64/pxelinux.cfg/0A0
   • /efi64/pxelinux.cfg/0A
   • /efi64/pxelinux.cfg/0
3. A nakonec zkusí stáhnout výchozí /efi64/pxelinux.cfg/default

Proto použijte místo tohoto adresáře symlink na adresář ve kterém budete mít společnou konfiguraci:

Vytvoření symlinku na adresář pxelinux.cfg v kořeni TFTP serveru

Pozor! Nezapomínejte na to, aby oba zavaděče měly k dispozici všechny moduly, se kterými konfigurační soubory chtějí pracovat!

Globální stavení DHCP

Pokud má být nastavení platné pro všechny subnety, které spravuje vaše DHCP, můžete udělat globální nastavení pomocí class

class "UEFI-64-1" {
        match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00007";
        filename "efi64/syslinux.efi";
}
class "Legacy" {
    match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00000";
    filename "bios/pxelinux.0";
}

Nezapomínejte, že se po každé změně konfigurace musí DHCP server restartovat!

Jak vypínat stroje při zavádění přes PXELINUX

V části věnované volbě zavaděče jsem zmínil, že PXELINUX má u nových strojů problém s vypnutím, protože nemají APM – když jsem zkusil použít modul poweroff.c32, zůstal stroj viset v blíže nespecifikovaném stavu, protože tento modul nepoužívá ACPI.

Na webu sice můžete najít zdrojové kódy pro modul acpioff.c32, jenže ty jsou víc jak sedm let staré a musely by se zkompilovat s aktuální verzí jak pro pxelinux.0, tak pro syslinux.efi. Hledal jsem tedy jiné řešení – jako optimální se mi jevilo zavádět nějaký pidikernel na který by se prakticky ihned po zavedení aplikoval poweroff. Trápil jsem se s tím, než mě k vyhovujícímu řešení přivedl kamarád (díky Milane!!!).

Rozbalil jsem si ramdisk, a do init skriptu přidal ihned za příkaz kterým se namountuje /proc následující řádek:

echo o > /proc/sysrq-trigger

Pak jsem vyházel zbytečnosti, aby se netahalo po síti zbytečně moc dat a vytvořil nový ramdisk. Do menu pak stačilo přidat novou položku, která zavádí systém, který se rovnou vypne.

Poznámka: Ty co neví jak pracovat s ramdiskem odkazuji do naší wiki na stránku Práce v prostředí ramdisku.

GRUB2

Jak už jsem zmínil, sáhnul jsem po něm, když se mi nedařilo nabootovat přes syslinux.efi. V té době jsem ještě netušil jak na klientské stanici správně nastavit BIOS. První co mě zaskočilo, byl fakt že v menu UEFI Order chyběla možnost pro zavádění přes UEFI PXE. Netušil jsem, že ty stroje už nejsou v továrním nastavení, ale že jim mezi tím kolegové zapnuli legacy mód aby vůbec mohli naklonovat lokální systém přes Clonezillu.

Po určitém laborování, jehož výsledek shrnuje úvodní část tohoto blogpostu se mi podařilo UEFI PXE zapnout, ale syslinux.efi se nechtěl spustit. Tak jsem zkusil podle nějakého návodu pro Ubuntu rozhodit GRUB2. Nemusel jsem díky tomu drbat do stávající konfigurace PXELINUXu, protože v té době už začal semestr a zavádění přes legacy PXE u nových strojů fungovalo bez problémů. Díky tomu jsem získal čas, ale i tak bylo nutné situaci co nejrychleji vyřešit.

Stáhnul jsem z netu soubor grubnetx64.efi.signed a voilá! – zavaděč se natáhnul a spustil. Stačilo pouze v adresáři grub vytvořit soubor grub.cfg.

Pak ovšem nastala druhá fáze – PXE boot disklessu. Nastavil jsem položku v menu a zkusil nabootovat. Měl jsem štěstí. Trefil jsem se totiž zrovna do verze, která se – byť s menší prodlevou – spustila. Zjistil jsem při tom, že se do sendviče nepřipojily všechny vrstvy. V parametrech předávaných jádru bylo nutné zpětným lomítkem ošetřit středník.

Zkusil jsem přidat ostatní položky, ale ouha! Zjistil jsem, že starší verzi jádra 4.6 z nějakého důvodu spustit nelze. A teď se dostávám k tomu, proč jsem se nakonec vrátil k PXELINUXU:

1. Nevím proč, ale zavádění linuxového jádra přes PXE trvá u Grubu2 neskutečně dlouho. Čumíte na černou obrazovku a přemítáte, jestli ten stroj něco dělá, nebo ne. Po síti neběhá nic a připadáte si jako idiot. Pak najednou problikne spouštění jádra, jenže než stačíte cokoliv zaregistrovat, je opět černá obrazovka a pak už naskočí grafika. Zkusil jsem nastavit ukecanější režim, ale totéž v bledě modrém. Zkrátka Grub2 při zavádění linuxového kernelu přesměruje výstup kamsi a nevidíte nic.
2. Pokud zůstane proces zavádění viset v ramdisku, jste namydlení, protože nevíte proč a nač se čeká. Čumíte na černou obrazovku a šmytec
3. Na další nemilou věc, kterou bylo nutné ošetřit v souboru grub.cfg jsem narazil při zavádění lokálního systému. Aby GRUB2 spustil lokální systém, tak musí vědět kde najde /efi/Microsoft/Boot/bootmgfw.efi, jenže stačí, aby během zavádění někdo nechal v kompu zapomenutý flash disk a jste nahraní, protože se změní pořadí nalezených disků. Na to jsem ovšem přišel až později. Mnohem záludnější bylo, že se kolegovi v jiné učebně na jiném subnetu podařilo nainstalovat lokální systém tak, že uefi nebylo na prvním diskovém oddíle, ale až na druhém. I to se mi podařilo vyřešit.
4. Pomyslnou hůl nad zaváděním přes GRUB2 zlomil až další požadavek kolegů – chtěli totiž, abych rozchodil přes PXE Clonezillu. V tomto případě jsem skončil na chování popsaném v bodě 2

GRUB2 je prima nástroj a mám ho rád. Líbí se mi i možnosti jeho konfigurace ale pro zavádění disklessových strojů se ukázal jako nepraktický.

Doslov

Tenhle nudný a zcela nezajímavý blogpost jsem s přestávkami smolil téměř dva týdny. A než jsem ho dokončil, tak se několikrát změnilo cílové paradigma i jeho vyznění. Kusy textu bylo nutné psát znovu a za každou větou jsou hodiny času a řada testů. Ty co se jim teď začíná ohrnovat nos bych upozornil, že nastavit službu tak nějak aby fungovala, je snadné. Mnohem těžší je napsat, proč jsem postupoval zrovna tak a ne jinak.

Odkazy

Bootování ze sítě: pxelinux a kořenový adresář na NFS, Doliho článek na tomto webu z 21. 11. 2012

       

Obrázky

Komentáře

[Odin]

Vidis, ze i ty, kdyz chces, dokazes sepsat neco zajimaveho.

Btw je s podivem, ze statem financovane instituce nechaji takoveto reseni pytlikovat mistniho admina misto toho, aby na to najali profesionalni firmu. Desi mne pri pomysleni na kolika statem financovanych institucich probiha paralelne takoveto pytlikovani, kdy kazde reseni funguje plus minus, ale je trochu jine a nestandardni. Pri tom by se to dalo delat unifikovane, robustne a daleko levneji.

[Aleš Kapica]

Pro tebe jsem to nepsal. A tvoje představy o profi produktech jsou krutě zkreslené. Mě spíš děsí, že ty kapitálově silné korporáty s týmy draze placených vývojářů dodávají prakticky totéž, ovšem za zcela jiné peníze. Nejspíš proto, aby se v tom nalešteném hovnu mohli zhlížet takoví jako ty.

[Odin]

Me predstavy nejsou zkreslene. Na rozdil od Tebe s tim mam zkusenosti. Situace, kdy na X skolach a dalsich institucich dochazi k pytlikovani a objevovani obdobnych redundantnich reseni ruznymi kapicami, je smutne plytvani penezi danoveho poplatnika. I ty musis uznat, ze je chybne a drahe vymyslet to same na tisic ruznych zpusobu. Neni lepsi to sverit profesionalovi, ktery to udela poradne a jednou pro vsechny instituce? Vzdyt i tobe by to usetrilo dlouhe trapeni se znovuobjevovanim kola.

Jinak si prosim uvedom, ze tebou opovrhovane a ironizovane korporaty plati dane, ze kterych jsou financovane ty skanzeny statniho vzdelavani. To jen na zaver, aby sis uvedomil, ci chleb zeres...

[Peter Golis]

Pokiaľ to robí sám, dobrovoľne a počas prestojov v práci, tak to negeneruje dodatočné náklady. Chceš to okopírovať a predať na zvyšné školy?

[tomvec]

Myslíš korporáty, které vyvádějí zisky od nás do svých matek nebo daní v daňových rájích?

[ewew]

Už si povedal čo si chcel ? Tak môžeš isť písať chvály.

Chudoba existuje pretože existujú ľudia ako ty.

[Aleš Kapica]

Je vidět, že uvažuješ jako každý bývalý komunistický kádr: všichni lidé jsou stejní, uvažují stejně, jsou stejně pitomí a stejně chytří, stejně nadutí, stejně geniální a tudíž i nahraditelní jinou lidskou entitou.

Jenže tak to není.

Kdyby totiž na těch školách byli stejní lidé jako já, tak je naše vysokoškolské IT dávno někde jinde a ty si strouháš tužku v jiné rozvojové zemi.

[Aleš Kapica]

A než se začneš zase otírat spolu s jinými o naše jméno, tak si laskavě zapiš za uši, že můj otec se od r. 1967 do r. 2015 než šel po letech přesluhování konečně do důchodu podílel prakticky na všech velkých stavebních a strojírenských projektech v této zemi. Od dálničních mostů, přes televizní věže po důlní rypadla. Jenže jména techniků, bez kterých bys při takových stavbách nepostavil ani židli se na pamětní desky nepíšou. Na rozdíl od tebe se ovšem za svoje jméno, stejně jako já, nemusel stydět.

[Max]

Mně by zajímalo, co je konkrétně na této věci pytlíkování? Vždyť jde o obyčejný PXE boot řízený nastavením z dhcp serveru a Aleš jen porovnal různé možnosti bootloaderů, nic víc. Všechno, co popsal, je vesměs standard.
Spíš mi připadá, že tomu nerozumíš a výsledkem toho je představa o jakémsi pytlíkování.
A tu ztrátu času, tím myslíš ten průzkum a otestování různých bootloaderů a nastavení? Vždy to samé probíhá v komerční sféře. Přeci si do firmy nenasadím bez otestování první řešení, které mi přistane v mailu. Vždy je třeba vybírat z většího okruhu a otestovat si více komerčních řešení. Rozdíl je jen v tom, že v případě komerčních řešení musí člověk vložit do rovnice mnohem více hodnot, hlavně ty, co se týkají licencování, maintenance a věcí s tím souvisejících. Má osobní zkušenost pak je, že licenční politika je něco, co mi ve finále przní finální řešení, viz např. můj blog o Oracle (a podobně je to i u jiných řešení pod nějakou licenční politikou).
Zdar Max

[k3dAR]

Neni lepsi to sverit profesionalovi, ktery to udela poradne a jednou pro vsechny instituce?

to by teprve bylo plytvani penezi danoveho poplatnika, protoze by to stalo nejmene 10000x vice nez soucet toho kdyz to ruzni "Kapicove" budou delat kazdej zvlast, vhodnejsi reseni by bylo kdyby se informace od jednoho tohoto "Kapica" dostalo k ostatnim, aha to se vlastne stale v tomto blogu resp. aby se obecne sdileli informace, reseni ci vyvoj, jako napr. https://www.otevrenamesta.cz/

[Aleš Kapica]

… aby se obecne sdileli informace, reseni ci vyvoj, jako napr. https://www.otevrenamesta.cz/

Ano. Ostatně, to byl také důvod proč jsem v mailové konferenci tohoto projektu. Ovšem věci, které se v ní zatím objevily souvisí spíš s úředničinou jako takovou. A o pomoc či spolupráci mě z této strany zatím nikdo nikdy nežádal.

Ale obrátil se na mě s prosbou o radu chlapík od kriminálky, tak jsem mu poradil jak jsem nejlépe uměl a třeba ho to i nasměrovalo tam kam potřeboval. Musím přiznat, že mě udivilo proč v některých (z mého podhledu triviálních) oblastech tápal, protože bylo vidět, že má opravdu bohaté zkušenosti. Ale to už tak někdy bývá, když se nemá s kým člověk poradit. Byl jsem rád, že má o pomoc zájem a vzhledem k tomu, že se pak znovu neozval, předpokládám, že se dobral uspokojivého výsledku.

[chlapík od kriminálky]

tak jsem mu poradil jak jsem nejlépe uměl ...

A opravdu mě to nasměrovalo. Protože však řešíme každý jiný cílový systém v jiném existujícím prostředí, výsledek je samozřejmě jiný. To ovšem jen potvrzuje průběžně uváděné stesky na mrhání peněz daňových poplatníků, protože podporou Linuxu v resortu vnitra a školství (které nové zdatné odborníky na opensource a linux průběžně vytváří) by bylo možné ušetřit mnoho peněz, ale i trápení. Aniž bych chtěl někomu závidět nebo snad dokonce brát business, zkušenost je obecně taková, že firmy nabízejí, až vnucují, pouze jimi vytvořené řešení (s poukazem na dlouholeté zkušenosti - vizte Odin), aniž by samy přemýšlely či si jen připouštěly myšlenky o vhodnosti. Jakékoliv úpravy si nechávají platit (na Kajmanech musí být draho) nesmyslně draho a navíc nechávají zákazníka bez možnosti získané systémy modifikovat (porušení licence), což bývá důvodem dalšího mrhání finančními prostředky, když firma zmizí z trhu a není, kdo by se v tom vyznal - takže se, logicky musí koupit nové, vlastně spíše jen jiné, obdobně nevyhovující řešení.

Vývojáři v oblasti IT si rychle osvojili manýry architektů a projekčních kanceláří a určují cenu nikoliv podle skutečných nákladů, ale podle odhadu hloubky zákazníkovy kapsy a nezřídka jsou ve hře i různá šméčka - vím co vyšetřujeme. Nad to se ještě všichni tváří, že celý systém je od základu pouze jejich autorským dílem, ačkoliv minimálně požadavek, základní zadání a často i prvotní analýzy jsou autorským dílem zákazníka! Ten však nesmí sám ani opravit zjevné chyby dodavatele a navíc zcela ostrouhá, pokud dodavatel stejný systém dodá ještě jiným zákazníkům!

Náš bezdiskový OS byl vytvořen s ohledem na šetření místem a silnou autonomii po zavedení. Takže se vzdáleně podobá Live CD ArchLinuxu (na kterém se podařilo experimentálně ověřit, že takový systém sestavit lze), které lze zavést po síti přímo do paměti počítače (dnes s pamětí nebývají problémy), a po zavedení již není na síti závislý. V našich podmínkách však nehraje žádnou roli uživatelská segregace, protože OS je účelově zaměřen pouze na vytvoření bitového obrazu disku v počítači a to se stejně provádí v prostředí uživatele root. Výhoda je, že při zpracování případu s několika desítkami stop (disky, flešky, CD ...), do vytváření bitových kopií lze dočasně zapojit všechny volné počítače v síti, ať už je na nich nainstalován jakýkoliv OS. Na serveru se opírá o projekty dnsmasq (dhcp, dns, bootp a tftp) a lightpd (http), zároveň byl v rámci http serveru spuštěn lokální repositář Debian Linuxu, protože lokální síť není z pochopitelných důvodů připojena k Internetu. Debian nabízí mj. také netinst.iso, které bylo rovněž zařazeno do konfigurace pxelinux, taže instalaci OS Debian Linux lze provést bez nutnosti shánět a vytvářet spouštěcí flešku. OS může posloužit i jako servisní systém alespoň pro diagnostiku. Celková velikost bez komprimace (ta by měla být součástí verse 2) je cca 900MB a po celou dobu běží z RAMdisku.

Podobně jako autor článku, i my po několika letech používání takového OS musíme reagovat na přibývající množství počítačů, které již legacy mode vůbec neumožňují. Proto si článku a autorovy píle nesmírně vážím, neboť mě opět nasměroval a výrazně zjednodušil experimentování a procházení slepých uliček v rámci základního výzkumu.

Děkuji J.

[Tomáš Pelc]

Díky za zápisek. Tohle je velmi poučné a zajímavé čtení.

[ewew]

Myslím, že tento blog môže byť označený ako kvalitný zápis

[snajpa]

Tento kazdopadne ano, plny souhlas.

[Grudl]

Cože, kapuca kromě shitpostingu i něco umí? Dobře to skrývá za postavu blbce, to se musí nechat

[Aleš Kapica]

Dost na to, abych se nemusel stydět za svou identitu. A teď se jdi postavit do fronty za Odina.

[k3dAR]

btw: nedoplnils "Moduly pro syslinux.efi najdete u Debianu po instalaci balíku … v adresáři … . A pro pxelinux.0 (který je součástí balíku … ) v adresáři … (instalační balík … )"

[Aleš Kapica]

Čas. Tohle už je drobnost kterou doplním, až se k tomu dostanu. Stejně je třeba opravit nějaké překlepy. A pro průměrného admina není problém si to zjistit.

[k3dAR]

Jasne to nemela byt pruda, jen upozorneni
btw:ja pouzivam ~7let teda jen Legacy PXE, postupne s Win instalacema(Xp,Vista,W7,W8,W10), Linux (Live, nfsroot), Clonezilou(nazvy img pro restore generovane do pxemenu), Acronis a par drobnosti pres WinPE...
Naahodou neresil si pxe memtest kterej dle vysledku nastartuje sam Linux, nebo zobrazi error? Mam to rozbehle, ale ten Linux pak ma naborene ACPI

[Aleš Kapica]

Naahodou neresil si pxe memtest kterej dle vysledku nastartuje sam Linux, nebo zobrazi error? Mam to rozbehle, ale ten Linux pak ma naborene ACPI

Ne, protože to nebylo zapotřebí. Stroje zralé na memtest by šly rovnou do reklamace. V podstatě není vůbec důvod se s ním zdržovat, protože některé problémy jsou tak zákeřné, že je stejně neodhalí. V minulosti, když byly ještě paměti drahé, jsem řešil takový problém skoro dva roky, než se ukázalo, že byly na vině hned 2 moduly ze čtyř. A chyba se projevovala jen v případě, že byly přítomny alespoň dva moduly. Takže jednotlivě paměti prošly, ale když jsem je testoval po dvojicích, tak se ukázaly chyby. Pak jsem musel testovat každou s každou, abych vůbec zjistil, které z nich jsou vlastně vadné. A mohl jsem si to dovolit až tehdy, kdy se koupil další stroj co měl DDR3 a další paměťové moduly, jimiž jsem mohl nahradit ty stávající, protože z původního stroje jely všechny virtuály co zajišťovaly laborky a tudíž na něm nebylo memtest možné spustit. A jiný stroj s DDR3 sloty tehdy k dispozici nebyl.

[regine]

Výborné počtení. Díky.

[Grunt]

Grunt pouze dodá tolik že za ty dva roky heslo do BIOSu na svém stroji zapomněl a má sto chutí svůj retardovaný stroj svrhnout ze skály. Zlatý Legacy BIOS. Tyhle UEFI sračky každého jen otravují…

[Max]

heslo do tvého biosu je : babeta
Zdar Max

[Grunt]

Vtipný zas po ránu…

[Bedňa]

Your password is invalid

[lzap]

Grub2 a opatchovany Grub2 jsou v podstate dva ruzne projekty. Ten z RHELu funguje s EFI PXE vyborne.

[lizbee]

i love it! milwaukee newborn photography

[Agent]

Uff... Trochu se mi při čtení zakouřilo z hlavy... Přeci jen nejsem takový odborník. Ale jinak dobrý počteníčko, to jako jo. To by bylo i na článek.