Důležité upozornění, pokud po debootsrap plánujete vstup do prostoru vytvořeného systému přes chroot a upgrade/instalaci balíků nástroji Debianu, zajistěte blokování spouštění RC scriptů na stroji distribujícím FS do sítě.
Viz popis
<chroot>/usr/sbin/policy-rc.d
v mojí přednášce uvedené v diskuzi pod minulým článkem. Jinak první instalace/upgrade balíku, který obsahuje rc.scripty ovlivňující stav jádra/síťových služeb nebo spouštějící démony povede k rozložení runtime stavu stroje, nak terém v chrootu pracujeme.
Další naše zkušenost je, že právě komunikace NFS přes UDP dělá problémy a je potřeba (minimálně v sítích s přechody 1GB/s a 100MB/s) použít volbu "tcp". NFSv4 již komunikaci směřuje na TCP defaultně. Je ovšem možné, že někdo má zkušenosti jiné.
Mohu potvrdit problemy jak s NFS3, tak s NFS4 na 1GB aktivnich prvcich (switch 3com, D-Link, Mikrotik). Vypada to, ze switch obcas zahodi nejaky ten paket, ale nechce se priznat proc .... Mozna bude na vine i kabelaz, ta zatim na promereni ceka. U NFS mount nepomohl ani parametr tcp, spis vse jen zhorsil.
"Pamatujte si, že jste v chrootu. Pokud máte otevřeno víc terminálů a nemáte je moc dobře označeny, můžete si zadělat na nezáviděníhodné chvilky." - v Debiane na to existuje súbor /etc/debian_chroot, ktorého obsah sa zobrazí v prompte.
Keďže autor odporúča nfs4, určite by som spomenul parameter fsid v /etc/exports - bez neho si pri exporte viacerých stromov privoláme ťažké chvíle pri zisťovaní, prečo to tak veľmi divne funguje (stalo sa mi :-))
V roce 1995 jsem bootoval plnohodnotný systém ze sítě, normální diskless boot. Na PC nebyly žádné disky, jen síťová karta, takových počítačů bylo asi 200 a jeden Novell server. Stanice bootovaly do Windows 3.11, neuvěřitelně rychle, uživatelé měli restrikce na diskový prostor, vše řešeno starým dobrým Novell 3.12. A pak mi povídejte něco o pokroku. Objevujete dávno objevené.
Ne neobjevuje. Jen Intel prespecifikoval jeden shit od IBM na jiny shit made by Intel a pojmenoval ho jinak. Respektive udelal z nej jeste shit vetsi. Misto toho aby vyrobil neco tak sikovneho jako suni wanboot.
Taky jsme pouzivali network bootovani v Novelu. Sitovky byly osazeny EPROMkama s RPL/RIPL boot rom. Specifikace se datuje nekdy do roku 91-92.
Problem je v tom ze tehdy si clovek musel zajistit EPROMky pro sitovky co nebyla zas az tak samozrejma vec. Nakonec se musely objednat z Nemecka.
Takhle se bootoval i OS/2 ale v praxi jsem to jenom zkousel. Nikdy jsem to nevidel nasazene.
RPL umi stale nektere lepsi network boot moduly. Dokonce jsem videl i na peckach podporu RARP bootu ktery je jinak bezny u Sunu.