Bootování ze sítě: pxelinux a kořenový adresář na NFS

21. 11. 2012 | Luboš Doležel

Články - Bootování ze sítě: pxelinux a kořenový adresář na NFS  

V tomto seriálu si předvedeme bootování ze sítě v různých variacích. V prvním dílu si vysvětlíme, oč jde a předvedeme si pxelinux v kombinaci s kořenem souborového systému na NFS.

Obsah

• Proč bootovat ze sítě?
• Jdeme na to
• DHCP
• TFTP server
• Zavaděč
• Linux
  • IP adresa
  • Umístění kořene
  • Ostatní věci

Proč bootovat ze sítě?

Osobně používám bootování ze sítě popisované v tomto článku z několika důvodů:

• Efektivnější využití diskového prostoru (při použutí NFS). Volné místo se soustřeďuje na jediném stroji a není roztroušené po různých discích na síti.
• Nižší pořizovací cena, nebo vyšší výkon. Tím, že kupuji jediné úložiště, si mohu dovolit jedno výkonné (např. SSD) místo několika horších, případně ušetřím na tom, že nekupuji několik malých disků, kde je vyšší cena za gigabajt.
• Snadná centrální správa. Nemusím obíhat různé počítače, abych tam provedl aktualizace nebo nainstaloval nový software.

A jaké jsou nevýhody?

• Centrální místo selhání. Pád serveru odstaví klientské stanice. Na druhou stranu, pokud je odstávka jen dočasná, tak je v práci možné pokračovat „jako by nic“ po opětovném naběhnutí serveru.
• Vyšší latence při přístupu. V reálu se projeví při přístupu ke spoustě malých souborů (emerge --sync), pro běžné použití jsem ale nespokojený nebyl.

Kde se může takový systém hodit?

• Jednoduše tam, kde je větší množství desktopů. Tedy firma nebo větší rodina.
• Při stavbě HTPC. HTPC pravděpodobně stejně načítá multimediální data ze sítě, lokální disk je tak na obtíž.
• Jako systém pro LAN párty. (Pokud poohlédneme od omezeného množství her pro Linux.) Když si vyrobíme univerzální systém podporující různé grafické ovladače a s $HOME v RAM disku, nemusí účastníci akce trávit čas instalací a konfigurací her. Všichni prostě nabootují ze sítě. (Ozkoušeno.) Když pak má server nacachovaná herní data, tak může načítání ze sítě být znatelně rychlejší než z lokálního disku.
• Instalace systému na lokální disk. Namísto toho, abychom obíhali všechny stroje v síti s instalačním DVD nebo flash diskem, jednoduše si spustíme instalační program ze sítě.

...a na spoustě dalších míst.

V čem nás bootování ze sítě NEomezuje?

• V cílové platformě. ARM SoC může bootovat z x86 serveru. (I když zde by některé kroky byly odlišné, protože na ARM se nepoužívá BIOS.)
• V operačních systémech, které takto bootujeme. V druhém dílu si ozkoušíme instalaci a boot Windows 7 ze sítě.
• V možnosti dávat každému desktopu jiný operační systém, jiné bootovací menu atp.
• V možnosti dále nabízet boot z lokálního disku jako volbu v menu.

Jdeme na to

Abychom byli schopni řešit případné problémy, je vhodné vědět, jak co funguje. Prvním krokem je mít počítač, který boot ze sítě podporuje. V dnešní době to jsou prakticky všechny základní desky a velká část síťových karet do PCI/PCIe. Obvykle stačí boot ze sítě povolit v BIOSu, na některém hardwaru (kupříkladu notebooky Sony Vaio) je pak ještě nutné dodatečně mačkat F12 nebo jinou klávesu.

Pokud máme natolik starý hardware, že síťový boot není podporován, je tu stále ještě možnost načíst příslušný zavaděč z diskety, CD-ROMu a tak podobně.

DHCP

Prvním dílem celé stavebnice je DHCP server, který poskytne jako součást své obvyklé odpovědi dodatečné údaje. Jakmile se počitač pokouší o boot ze sítě a spustí takzvané Preboot eXecution Environment (PXE), začne se dotazovat DHCP serveru o přidělení IP adresy. Toto je situace, se kterou se jistě setkala spousta uživatelů, aniž by o bootování ze sítě měli ponětí. Řada základních desek má pokus o boot ze sítě jako volbu následující po pokusu o boot z lokálních pevných disků nebo optických mechanik.

Primární věcí, o kterou má PXE od DHCP serveru zájem, je název/cesta k souboru, kde je k dispozici bootloader (zavaděč). Podíváme se na konfiguraci pro ISC DHCP server.

host hera {
    hardware ethernet 00:1B:FC:45:C0:B7;
    fixed-address 10.10.10.2;
    filename "pxelinux.0";
}

Povšimněte si řádku filename. Toto je cesta, která bude použita v dalším kroku, tedy při stahování zavaděče ze serveru TFTP. Pokud máme DHCP server na nějakém obyčejnějším routeru, nabízí se volba next-server, kterou určíme, že se má TFTP klient připojovat k jiné IP adrese, než kde sídlí DHCP server.

Rovnou si ale ukážeme situaci, kdy chceme nabízet boot ze sítě všem strojům, které o to projevují zájem. Tedy nevysílat dodatečné údaje každému DHCP klientovi nebo jen konkrétní PXE adrese, ale jen všem PXE klientům:

class "pxeclient" {
    match if substring(option vendor-class-identifier, 0, 9) = "PXEClient";

    filename "pxelinux.0";
    next-server 10.10.10.15;
}

TFTP server

Proč se používá TFTP server? TFTP je velmi jednoduchý protokol pro přenos souborů, podstatně primitivnější než FTP. Místo TCP používá UDP a je bezstavový. TFTP server obdrží nahodilý požadavek „chci X bajtů ze souboru ABC“ a pošle zpátky výsledek.

TFTP serverů je na výběr více. Osobně mohu doporučit tftp-hpa, ale asi snad jen díky tomu, že umí hacky pro podporu Windows. Jinak na tom vcelku nesejde. Osobně nenechávám na serveru běžet spousty zbytečných procesů, proto jsem rád za možnost spouštět tohoto démona přes (x)inetd. Toto je obsah mého souboru /etc/xinetd.d/tftp:

service tftp
{
        disable         = no
        socket_type     = dgram
        protocol        = udp
        wait            = yes
        user            = root
        server          = /usr/sbin/in.tftpd
        server_args     = -R 4096:32767 -s /diskless -m /etc/tftpd.map
}

Vysvětlíme si server_args. První argument je povolený rozsah zdrojových portů. Přiznám se, že zde si nejsem jist účelností. Druhý argument je kořenový adresář, kde se nacházejí soubory poskytované TFTP serverem. Třetí argument určuje soubor, kde můžeme provádět jisté manipulace s požadavky – na to se podíváme příště a ano, tam je jeden z většího počtu hacků pro Windows

Zavaděč

V našem případě si nainstalujeme zavaděč syslinux a jeho variantu v souboru pxelinux.0 nakopírujeme do adresáře /diskless. Na Gentoo se ukrývá v /usr/share/syslinux. Pokud bychom v tento moment spustili DHCP server, TFTP server a klientskou stanici, dostali bychom tento výstup:

To nám dává tušit, že dalším krokem je sestavit nějakou konfiguraci. Tu si pxelinux stahuje rovněž přes TFTP a v našem případě ji bude hledat v adresáři /diskless/pxelinux.cfg/. Zde máme na výběr několik způsobů, jak konfiguraci zorganizovat (a v tomto pořadí ji pxelinux hledá):

• podle MAC adres,
• podle IP adresy nebo jejího prefixu („prvních číslic“),
• jediná konfigurace pro všechny.

Konfiguraci pro konkrétní MAC adresu uložíme např. do souboru 52-54-00-00-00-aa. IP adresu zapisujeme hexadecimálně – konfiguraci pro stroj 10.10.10.2 tedy uložíme do souboru 0A0A0A02, výchozí konfiguraci pro celou síť 10.10.10.0/24 uložíme do souboru 0A0A0A. Výchozí konfiguraci pro všechny případy uložíme do souboru default.

Obsah souboru může vypadat následovně:

DEFAULT /10.10.10.2/boot/vmlinuz-3.2.11-gentoo
APPEND root=/dev/nfs rw nfsroot=10.10.10.3:/diskless/10.10.10.2 initrd=/10.10.10.2/boot/initrd.img.gz

Na řádku DEFAULT je cesta k jádru relativní ke kořenovému adresáři TFTP serveru (skutečná cesta je tedy /diskless/10.10.10.2/boot/vmlinuz-3.2.11-gentoo). Na řádku APPEND jsou pak argumenty předané jádru. pxelinux načte soubor s jádrem do paměti, případně i initrd (jestliže jej používáme) a předá řízení jádru. Upozornění: pxelinux a další zavaděče nemusejí být v této fázi zrovna dvakrát výkonné. Stahování jádra tedy může trvat déle než obvykle, samotný systém už ale může běžet krásně rychle.

Takto to tedy bylo bez menu. Konfigurace s menu může vypadat následovně:

DEFAULT vesamenu.c32
PROMPT 0

menu title Zeus PXE Boot Menu
MENU WIDTH 80
MENU MARGIN 10
MENU PASSWORDMARGIN 3
MENU ROWS 12
MENU TABMSGROW 18
MENU CMDLINEROW 18
MENU ENDROW 24
MENU PASSWORDROW 11
MENU TIMEOUTROW 20

LABEL bootlocal
        MENU LABEL ^Boot from local disk
        MENU DEFAULT
        localboot 0

LABEL xdmcp
        MENU LABEL ^XDMCP at Zeus
        KERNEL /eros/boot/vmlinuz-3.3.5-gentoo
        APPEND root=/dev/nfs rw nfsroot=10.10.10.3:/diskless/eros ip=dhcp

LABEL nfsroot
        MENU LABEL ^NFSroot only from Zeus
        KERNEL /eros/boot/vmlinuz-3.3.5-gentoo
        APPEND root=/dev/nfs rw nfsroot=10.10.10.3:/diskless/eros ip=dhcp noxdmcp

Hrátky s barvičkami a rozměry tabulky už ponechám na zvědavém čtenářovi. Stejně tak nechám na čtenářovi konfiguraci NFS serveru.

Linux

Při konfiguraci Linuxu a jeho bootu se držím těchto kroků:

• Jádro musí mít podporu nfsroot (File systems -> Network File Systems -> NFS client support -> Root file system on NFS).
• Je příhodné mít v systému nainstalované klientské balíčky pro podporu NFS.
• Pokud nebudeme IP adresu určovat přímo v argumentech jádra, je nutné mít součástí jádra DHCP klienta (Networking support -> Networking options -> TCP/IP networking -> IP: kernel level autoconfiguration).
• Pro bezproblémový boot i vypínání je vhodné nenechat distribuční skripty (nebo NetworkManager) konfigurovat síťová rozhraní. V obou situacích (hlavně ale při vypínání) si může systém odříznout síť, takže by zůstal „viset“.

Instalace systému se mezi distribucemi liší, u Gentoo je to ale prakticky stejné jako normálně (vyrobíme si systém v chrootu a ten pak nasdílíme přes NFS).

Máte-li v plánu mít kořen souborového systému jen ke čtení – vhodné, pokud sdílíte jednu instalaci systému pro více klientských stanic – mohou být nutné dodatečné úpravy v závislosti na vaši distribuci. Obecný postup je to prostě zkusit a pak ladit obtíže, které vyvstanou. Typickou věcí je mít /etc/mtab jako symbolický odkaz na /proc/mounts.

IP adresa

Protože Linux opouští prostředí PXE, které IP adresu má, musí ji Linux opětovně získat. Standardní DHCP klient zde nestačí, protože ten by se musel nejprve stáhnout odněkud ze sítě, kam se ale ještě nedostaneme. Jsou tedy dvě cesty. Tou první je IP adresu určit napevno, což je elegantní řešení, máme-li konfigurační soubor pxelinuxu pro konkrétní IP adresy:

APPEND .... ip=10.10.10.2::10.10.10.1:255.255.255.0

První IP adresa je adresa naší klientské stanice, druhá je výchozí brána a třetí je síťová maska. Nebo prostě napíšeme ip=dhcp a spustí se vestavěný DHCP klient...

Umístění kořene

Linux očekává jako kořenový „disk“ nějaký device node, proto jádru dáváme argument root=/dev/nfs. Samotnou cestu ke sdílenému adresáři pak předáváme v argumentu nfsroot, který má podobu nfsroot=adresa-serveru:sdílený-adresář:volby-nfs s tím, že volby jsou nepovinné. Ve volbách se nacházejí obvyklé věci jako rsize, kterými můžeme mimo jiné „poladit výkon“.

Ostatní věci

Ostatní věci už vyplývají dle našich potřeb. Je pravděpodobné, že budeme do /home připojovat nějaký další adresář. Kreativitě se meze nekladou – jak je vidět v jednom mém konfiguračním souboru výše, můžeme si z počítače udělat skutečného tenkého klienta přes XDMCP (včetně zvuku, ale o tom třeba někdy příště). Zásahem do bootovací sekvence zase můžeme nechat automaticky spustit třeba multimediální centrum XBMC.

V závislosti na použitém jádře a potřebách může být nutné vytvořit initrd s dodatečnými skripty nebo moduly. V zásadě se ale snažím initrd vyhýbat – do jádra dám minimum pro síťový boot a zbytek modulů se načte dle potřeby v době, když už máme připojené /.

Je to snazší, než si myslíte!

Diskuse k tomuto článku

[Pat1]

Zdravím, předně bych chtěl poděkovat za článek. Samotné bootovaní přes síť jsem už v minulosti řešil a došel jsem k podobnému postupu. Nyní jsem však narazil na nový problém. Potřeboval bych zprovoznit síťové bootovaní, pokud možno bez zásahu do nastavení DHCP serveru. Nynější stav je takový že mám pracovní stanice s Windows na hdd a potřeboval bych v případě potřeby bootovat přes síť Linux. Moje představa je taková že bych na hdd nainstaloval zavaděč (syslinux?) který by se pokusil stáhnout další konfiguraci z tftp, pokud se to podaří pokračoval by v zavádění Linuxu přes síť, pokud ne spustí Windows z prvního oddílu.

Problém vidím ve stažení konfigurace z tftp. Pokud jsem správně pochopil fungování zavaděče tak pro komunikaci přes síť používá funkce biosu (případně biosu na síťové kartě) a tím obchází potřebu ovladače pro všechny myslitelné síťové karty. Budou tyto funkce k dispozici pokud bude zavaděč spuštěn z hdd? A je možné napsat konfiguraci tak aby se pokusil stáhnout další konfigurační soubor a v případě neúspěchu (nedostupnosti tftp) pokračoval v bootovaní z hdd? Nebo mate nějaký jiný nápad jak zajistit podobnou funkčnost?

[Luboš Doležel (Doli)]

Asi bych se snažil odrazit od skriptů v iPXE.

[Pat1]

IPXE vypada opravdu zajmave, rozjet s nim bootovani pres sit opravdu neni problem, ale pokud jsem spravne hledal na internetu i v dokumentaci tak neni zadny zpusob jak ho donutit zavest system z lokalniho disku. Zda se ze jedine reseni bude vypalit IPXE na CD a dat v BIOSu na prvni misto boot z CD a nasledne z HDD. Doufam ze pokud selze bootovani pres z CD (pomoci IPXE) selze tak se "vrati" k bootovani z HDD. Ale optimalni reseni to urcite neni (uz kvuli tomu ze ne vsechny dnesni PC maji CD-ROM). Az se k tomu dostanu tak to vyzkousim a poslu k cemu jsem dosel.

[pavlix]

IPXE vypada opravdu zajmave, rozjet s nim bootovani pres sit opravdu neni problem, ale pokud jsem spravne hledal na internetu i v dokumentaci tak neni zadny zpusob jak ho donutit zavest system z lokalniho disku.

iPXE se dá kombinovat s dalšími nástroji, třeba syslinuxem.

[Aleš Kapica]

Proč tak složitě?

U nás to děláme tak, že pokud se nespoustí bezdiskový linux, tak se přes pxelinux natáhne grub2 (který najet přes pxe umí) a skrz něj už si natáhneš lokální systém jaký chceš. Grub2 umí navíc takové triky jako schovávání diskových oddílů & etc.

[Pat1]

Teď používám na jedné síti síťové bootování Linuxu pro klonováni hdd. Výběr jestli bootovat ze sítě nebo lokálně je udělán v nastavení DHCP serveru. V BIOSu je na prvním místě bootovaní ze sítě a až na druhém z hdd. Pokud bios dostane odpověď z DHCP obsahující cestu k souboru na tftp tak bootuje po síti. Pokud ne tak pokračuje z hdd.

Teď bych potřeboval něco podobného, ale nemůžu sahat na nastavení DHCP. Zkoušel jsem IPXE zpouštět z HDD a není s tím problém. Problém je v tom že nevím jak zajistit aby se bootovalo z HDD (Windows na prvni partition) pokud se IPXE nepovede připojit k serveru. Nevím jak od IPXE přejit k něčemju jinému. Vypadá to že image pro bootovaní umí získat jen přes síť, případně musí být vložen přímo do IPXE během kompilace. Teoreticky by tedy mohlo být řešení zakompilovat do IPXE image GRUBu (nebo jakéhokoliv jiného zavaděče) a v případě že se nepovede získat image přes síť spustit GRUB a pokračovat z HDD (To je asi vpodstate to co navrhues).

Chtěl bych prostě dosáhnout toho aby pokud počitač není připojený do sítě, nebo třeba neběží tftp server bootoval z první partition Windows. Pokud ale je připojený do sítě a na tftp najde soubor s nastavením tak jede podle toho.

Nejjednodušší řešení by asi bylo rozhodovat o tom co má bootovat nastavením odpovědi od DHCP, ale ja bych to potřeboval rozjet bez zásahu do nastavení DHCP.

[Aleš Kapica]

Pxelinux umí i bootování z lokálního disku a nic do něj není třeba kompilovat. Pracuje s hotovými moduly a textovou konfigurací.

Pokud se mu nepodaří přes síť spustit IPXE, tak dá rozum, že se mu nepodaří stáhnout ani ten grub.

Při použití grub2, tak jak to máme my, nabootuje při offline použití lokální systém, který byl spuštěn naposled. A to proto, že ten grub2 při posledním startu ty ostatní partice "schoval" tím, že jim přenastavil flag na "hidden" a tu viditelnou nastavil jako bootovací.

Do DHCP není vůbec potřeba vrtat. Kolega, který to využívá ke vzdálené reinstalaci těch strojů si v podstatě vystačí s tím, že přehazuje v menu pro pxelinux co má být zrovna nastaveno jako default. Na spuštění je nastavený timeout.

[Raduz]

Novellovské ZEN Works tohle řešily podobně. Pokud počítač neuměl PXE, nainstalovala se na něj malá service partition a LILO, které tu service partition mělo nastavenou jako default boot. Při startu se z ní nabootovalo, ZEN Works soft na ní zkontroloval na serveru jestli tam na něj nečeká nějaká práce, a pokud žádnou nenašel (nebo se mu nepovedlo z jakéhokoliv důvodu k tomu serveru připojit), spustil LILO a nastavil pouze pro příští boot jako default partition s Windows. Tím bylo zajištěno, že se při dalším restartu po Windows zase ZEN dostane ke slovu. Sice se boot trochu prodloužil, ale fungovalo to.

Jinak pro opensourcový disk imaging s PXE bootem jsem nedávno objevil Fog Project, a musím řict že zatím funguje velice dobře a pohodlně.

[SAL]

Pokial by niekto mal zaujem nabootovat akykolvek "free" OS, tak mozete pouzit priamo boot.salstar.sk. Je tam na vyber niekolko roznych OS v roznych preddefinovanych konfiguraciach. Okrem ineho aj niekolko Live distribucii (napr. pmagic).

V pripade, ze nemate moznost konfiguracie DHCP servra, tak budto pouzijete niektory dostupny image (ISO, USB, floppy), alebo pripadne si mozete ipxe napalit priamo do sietovky a pouzit:

dhcp net0

chain http://boot.salstar.sk/

Pripadne navrhy na dalsie OS su vitane.

[Jakub Lucký]

<paranoia> A kolik je k tomu backdoorů? </paranoia>

Značka PARANOIA není povolena!

A tohle nám paranoikům taky nepřidá (to je z Abíčka)

[pc]

+1

[SALstar]

Paranoici tam maju pravdaze zdrojaky a mozu si to zostavit ("skompilovat") sami.

Ak si pozriete zdrojaky, tak bezne systemy to bootuje priamo z roznych oficialnych mirrorov.

Co sa tyka kickstart skriptov, tie mam stavane hlavne pre seba a pridavaju pravdaze moj ssh kluc a podobne. Ak sa Ti to ale nepaci, mozes pouzit vlastny kickstart (ak uz sa Ti to nechce cele buildovat samemu).

[camel1cz]

Hezký počin... ale to přidávání SSH klíče je teda rána :-O

[waaaaaaaa]

caute,

dhcp aj tftp by mal zvladnut dnsmasq - aspon tak to kedysi pouzival SLAX. Ak mate niekto konfig pre dnsmasq pls pastnite ho sem, dik...

[MLx]

Do standardneho konfigu, kde si nastavujes rozsah, pridas (resp. odkomentujes) 3 riadky:

dhcp-boot=pxelinux.0
enable-tftp
tftp-root=/var/tftp

pxelinux, vesamenu atd. su do /var/tftp prelinkovane, takze ked dojde update, netreba to prenasat rucne.

[Aleš Kapica]

Je to pochopitelně blbost, ale občas tady mívám pocit, jako by mi někdo šmejdil v notebooku. Obvykle se totiž tady cca s dvou až tří měsíčním zpožděním objevují příspěvky na obdobná témata, která zpracovávám do naší wiki.

Bohužel stav dokumentačních článků v ní je takový, že je nelze považovat za dokončené. Snažím se je dělat průběžně, ale nestíhám. Důležité je že všechno běží jak má a bez problémů. Proto mám hodně věcí rozepsaných v poznámkách, které do wiki zapisuji až dodatečně, kdy si jsem víceméně jist, že už jsem v obraze.

Ostatně - v této oblasti snad ani nic dokončit nejde. Kupř. články k diskless řešení jsou momentálně na vedlejší koleji, protože vyšší prioritu mají věci k Puppetu. Jen pro zajímavost - viz naše Manuály.

[hajoucha]

Ahojda, zkoušel jste někdo instalaci (opensuse) po síti tj. boot pxe a navíc s nfs rootem?

V mém případě jsem chtěl na stroji se dvěma síťovkami jednu použít na instalaci ze sítě (vnější) a jednu na NFS, tj. komunikace po vnitřní síti. Instalace proběhne ok, ale detekce síťovek je totální chaos. tj. po rebootu se síťovky přehodí a nfs-root tudíž zatuhne. Dělal jsem to v létě, takže si přesně nepamatuji detaily, ale chystám se to znova udělat do konce tohoto týdne.

[Luboš Doležel (Doli)]

To má snadné řešení. V nainstalovaném systému nastavit pravidla v udevu tak, abychom měli názvy rozhraní dle potřeby, a pak konfigurovat "distribuční cestou" jen síťovku do vnější sítě.

Jestliže je problém v tom, že už jádro nemůže připojit nfsroot, protože ten je "za" eth1 místo výchozího eth0, tak parametr ip= podporuje i název rozhraní.

[Aleš Kapica]

Absolutně bez problému.

Tomu bezdiskovému systému je třeba pouze zamezit aby se pokoušel po startu konfigurovat síťové rozhraní, na kterém je "navěšený" přes NFS kořenový systém.

Nevím jak u opensuse, ale v Debianu se nastaví jména síťových zařízení přes udev (jsou navázána na jejich MAC adresy).

U všech virtuálních diskless strojů mám minimálně dvě síťovky. Na první mi visí NFS a přes druhou komunikují do vnější sítě. Jelikož u nás poměrně hojně využíváme VLAN, má stroj který zajišťuje DHCP pro laboratoře nakonfigurovaných síťovek pět.

[Kvakor]

Ješt je možnost vynutit pořadí tím, že se buďto vygeneruje intramdisk (resp. initramfs), kde je ovladač jen na jednu ze síťových karet (takže bude jediná a tudíž na 100% eth0), nebo se přeloží jádro tak, aby v něm byl ovladač síťovky natvrdo a ne jako modul. Osobně bych doporučoval spíš to druhé (kvůli NFS bootu), pokud není v distribuci nějaký udělátor na vybírání modulů s podporou bootu z NFS.

Jinak čistě teoreticky se dá fungovat čistě ze sítě i bez NFS, jen je pak nutné provést inicilazizaci z uživatelkého prostoru (optimálně initramfs vestavěný do jádra s busyboxem a příslušnými skipty). Root pak klidně může být třeba union tmpfs+squashfs (jako na line CD) nebo nbd se zapnutým copy-on-write (změny se zapisují do souboru bokem), případně třeba i sshfs (pro uživatelské účty, připojovaný až po přihlášení).

[Pavel Píša]

Pokud někoho zajímá plné bootování mnoha počítačů ze společného NFS exportu, tak dokumetace k našemu řešení v laboratořích Katedry řídicí techniky na ČVUT FEL je zde:

http://cmp.felk.cvut.cz/~pisa/linux/diskless_dce_slides.pdf

Úpravy a další pak zde

http://cmp.felk.cvut.cz/~pisa/linux/diskless/

[Roman DAVID]

Jeste bych doporucil pridat/upravit konfiguraci pxelinuxu nasledovne:

DEFAULT vesamenu.c32
TIMEOUT 100
ONTIMEOUT bootlocal
PROMPT 0

a to zejmena, pokud nabizite pxeboot vsem klientum.
Hodi se to napr. v situaci, kdy pripojite pocitac do site, zapnete a jdete si varit kavu.
Pokud je povoleny pxe boot (nektere ntb to maji jako factory default), zastavi se boot na pxe menu, takze kdyz se vratite s cerstve uvarenou kavou, tak zjistite, ze OS jeste nenastartoval. Vyse uvedena konfigurace zpusobi, ze pokud po zobrazeni menu neprobehne zadna interakce od uzivatele, tak se pokracuje v bootovani z lokalniho disku.

[Brumla01]

Díky za článek.

Boot přes PXE používám poměrně dlouho na náběh linuxu na servisovaných pc zakazníků, skrz zálohu dat, diagnsotiku atd.

Znáte nějakou distribuci u nichž by šlo vygenerovat LiveCD, dle požadvaků ( doinstalace balíčků, mount síťových samba atp. )? Následně bych upravený obraz bootoval přes PXE.

[Ivan Vecera]

Dobra otazka, to by me taky celkem zajimalo.

[Aleš Kapica]

Debian?

Pokud máš NFS server, tak je zbytečné vůbec dělat nějaký image. Přes debootstrap a chroot si nainstaluješ co chceš. Jako image u nás používáme pouze iso systemrescuecd.

[Luboš Doležel (Doli)]

Přesně, fungovat bude třeba i Gentoo. Prostě jakýkoliv systém používaný podle článku.

[Brumla01]

Mrknu na, to vypadá to ideálně.

[Smisek]

Jednoznacne mohu doporucit jednoduchou distribuci Slitaz. Bootovani i bez nfs serveru. Konfigurovatelnost i nove balicky, ale pro narocnejsi pozadavky pak uz opravdu zminovany debian. Ale za zkousku to stoji.

[Jiri Slaby]

Suse Studio?

[R]

SystemRescueCd je na taketo veci dobre. Da sa tam jednoducho urobit autorun script.

[diverman]

Ahoj, co treba IPv6? V dobe dochazeni IPv4 adres je prece blbost rozjizdet IPv4.

[Luboš Doležel (Doli)]

Mám obavy, že to ne všechny součásti umí (spíš to neumí). Dokonce ani NFS mi v UDP režimu nefungovalo přes IPv6.

Obecně je toto věc pro lokální sítě a tam je IP adres dost.

[Aleš Kapica]

Problém u diskless stroje s využitím NFS je ten, že tool, který se stará o ten mount neumí nic než IPv4. Rozchodit s IPv6 by to sice šlo, ale už by to vyžadovalo netriviální zásah do ramdisku a žádné výhody z toho.

[Lukáš Zapletal]

Pomaly neni ani tak zavadec jako protokol tftp. Fyi.

[Luboš Doležel (Doli)]

Tak ono by to třeba šlo zrychlit posláním víc požadavků na čtení za sebou. IMO to ty zavaděče dělají sekvenčně a tak se projeví roundtrip.

[R]

Povedal by som, ze to bude silne obmedzene moznostami PXE na konkretnej sietovke.

[Aleš Kapica]

Zrychlit se to dá tím, že se přes tftp stáhne jenom kernel a ramdisk a zbytek už pak jede přes NFS.

[Aleš Kapica]

Tedy přesněji řečeno - zavaděč, který si umí natáhnout přes NFS ten kernel a ramdisk.

[Jiri Slaby]

Jenom dodam, ze u uefi se neposila pxelinux.0, ale primo efi binarka. Treba grub.efi. Coz je trochu problem, pak clovek musi mit rohozene dhcp nastaveni podle mac adres.

[Mintaka]

Zajímalo by mě, proč se ve větším neprosazuje technologie gPXE?

http://etherboot.org/wiki/ gPXE is an open source (GPL) network bootloader. It provides a direct replacement for proprietary PXE ROMs, with many extra features such as DNS, HTTP, iSCSI, etc.

[pavlix]

Technologie? Dnes už spíše iPXE a o tom se píše výše. Jednu dobu fungovala služba http://boot.kernel.org/, dnes funguje alespoň http://boot.fedoraproject.org/.

[Mintaka]

Díky za info. Početl jsem si na Wiki ze iPXE je fork gPXE http://en.wikipedia.org/wiki/IPXE

Už pár let jsem neměl potřebu se v tom vrtat, páč gPXE funguje dobře, ale při příští přestavbě asi přesedlám.

[cakatel na pokracovanie]

Pokracovanie uz nebude? Alebo na vianoce?

[cokop33716]

Dnes už spíše iPXE a o tom se píše výše. Jednu dobu fungovala služba http://boot.kernel.org/, dnes funguje alespoň . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .