Společnost Amazon miliardáře Jeffa Bezose vypustila na oběžnou dráhu první várku družic svého projektu Kuiper, který má z vesmíru poskytovat vysokorychlostní internetové připojení po celém světě a snažit se konkurovat nyní dominantnímu Starlinku nejbohatšího muže planety Elona Muska.
Poslední aktualizací začal model GPT-4o uživatelům příliš podlézat. OpenAI jej tak vrátila k předchozí verzi.
Google Chrome 136 byl prohlášen za stabilní. Nejnovější stabilní verze 136.0.7103.59 přináší řadu novinek z hlediska uživatelů i vývojářů. Podrobný přehled v poznámkách k vydání. Opraveno bylo 8 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
Homebrew (Wikipedie), správce balíčků pro macOS a od verze 2.0.0 také pro Linux, byl vydán ve verzi 4.5.0. Na stránce Homebrew Formulae lze procházet seznamem balíčků. K dispozici jsou také různé statistiky.
Byl vydán Mozilla Firefox 138.0. Přehled novinek v poznámkách k vydání a poznámkách k vydání pro vývojáře. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 138 je již k dispozici také na Flathubu a Snapcraftu.
Šestnáctý ročník ne-konference jOpenSpace se koná 3. – 5. října 2025 v Hotelu Antoň v Telči. Pro účast je potřeba vyplnit registrační formulář. Ne-konference neznamená, že se organizátorům nechce připravovat program, ale naopak dává prostor všem pozvaným, aby si program sami složili z toho nejzajímavějšího, čím se v poslední době zabývají nebo co je oslovilo. Obsah, který vytvářejí všichni účastníci, se skládá z desetiminutových
… více »Richard Stallman přednáší ve středu 7. května od 16:30 na Technické univerzitě v Liberci o vlivu technologií na svobodu. Přednáška je určená jak odborné tak laické veřejnosti.
Jean-Baptiste Mardelle se v příspěvku na blogu rozepsal o novinkám v nejnovější verzi 25.04.0 editoru videa Kdenlive (Wikipedie). Ke stažení také na Flathubu.
TmuxAI (GitHub) je AI asistent pro práci v terminálu. Vyžaduje účet na OpenRouter.
25.10.2018 19:32
| Přečteno: 3658×
| 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.
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.
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.
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.
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.
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.
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í.
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.
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í konfigurační soubor pro DHCP server může vypadat kupř. takto:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
############
# 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
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.
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í:
boot/isolinuxisolinuxboot/syslinuxsyslinuxA 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:
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.
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:
/efi64/pxelinux.cfg/01-be-be-be-00-71-23/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/efi64/pxelinux.cfg/defaultProto 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!
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!
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.
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:
/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.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ý.
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.
Bootování ze sítě: pxelinux a kořenový adresář na NFS, Doliho článek na tomto webu z 21. 11. 2012
Tiskni
Sdílej:
Už si povedal čo si chcel ? Tak môžeš isť písať chvály.
Chudoba existuje pretože existujú ľudia ako ty.
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/
… 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.
Myslím, že tento blog môže byť označený ako kvalitný zápis
"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 … )"
to nemela byt pruda, jen upozorneni 
Naahodou neresil si pxe memtest kterej dle vysledku nastartuje sam Linux, nebo zobrazi error? Mam to rozbehle, ale ten Linux pak ma naborene ACPINe, 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.
Výborné počtení. Díky.
26.10.2018 14:39
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
26.10.2018 18:33
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
27.10.2018 13:40
Agent
| blog: Life_in_Pieces
| HC city
29.10.2018 14:01
29.10.2018 17:00
26.10.2018 10:16
27.10.2018 15:43