pxe vs local boot hiba

Hálózatok általános

sziasztok!

van egy pxe-boot-os környezetem, ahol a gépek helyi merevlemezről is tudnak indulni, meg hálózatról is (ez utóbbi telepítés, stb. célokra). kb. 30 gépből, amik tök egyforma fusi gépek, előfordul néha-néha, hogy a helyi boot indításakor (pxelinux bootoltatja) a következő jelenség áll elő. indítja a helyi boot-ot, kiírja, hogy "booting from local hardware" vagy mi, majd itt meg is áll. konkrétan meg is fagy. a jelenség azért zavaró, mert szeretném bennhagyni a boot sorban a hálózati boot lehetőségét és szeretném az egyszerű usernek is a keze alá tenni a boot-ot rendesen, tehát ne legyen ilyen "fagyás".

szerintetek hol a szöszben akadhat el a dolog?? a jelenség után a gép restartja (már reset gomb sincs és a gép ilyenkor fagyott...) megoldja a dolgot, de elég idegesítő egy helyzet (pont, hogy előnyt akartam a netes boottal, plusz szolgáltatást :) de ez a random megállás nem túl csábos (a többletet ettől még megkapja, ez leginkább kozmetikai bug... de az).

van valakinek hasonló tapasztalata? mi lehet a hiba forrás? pxelinux? pxe boot rom a hálókártyán? a bios? a vinyó (ez csak nem, hiszen pxe nélkül semmi baja)? debugolni nehéz, mert a kiírt szöveg előtt, után, közben, nem csinál semmit ugye. a pxe linux image meg adott, nem csináltam vele semmit...

  • 2064 megtekintés

( hellnet | 2009. 07. 24., p – 18:52 )

Erdemes lenne megnezni meg azt esetleg, hogy general-e halozati forgalmat egyaltalan mikor "megfagy" bootolaskor.

( janoszen v | 2009. 07. 24., p – 19:00 )

A PXE ROMra gyanakszom. Arra figyelj, hogy az asztali PC-kben levő PXE ROMok a nagy méretű DHCP packeteket néhány esetben nem jól kezelik. Így pl. default gatewayt, stb. ki lehet hagyni. ISC DHCPD-ben ezt egy jól szituált feltétellel meg tudod oldani. Ezen felül nézd meg a dhcpdump nevü csomagot Linux alatt, az egy hasznos eszköz valamint nézd meg a syslogban, hogy a TFTP szerver mit szeretne kiszolgálni (az atftpd pl oda loggolja, hogy mit kért a kliens).

sajna én is erre felé gondolkozom (mármint a pxe rom). a baj csak az, hogy ha kiderül, hogy az a ludas, akkor leszek igazán meglőve. viszont adtál egy jó tippet, a dhcp csomagokat. meg fogom nézni nem lehet-e kigyomlálni, bár tartok tőle, hogy nem igen. továbbá nem nagyon van rá befolyásom... a dhcpdump is jól fog jönni (ha már eszembe jutattad kipróbálgattam, mert kb annyit tudtam róla, hogy van). a syslogban nem volt hasznos infó. azokat a szervízeket, amik a gépet a pxe rom bootjáig eljuttatják megnézem log szinten (illetve megnézettem mással). a baj az, hogy a "boot" ritka kivételtől eltekintve jó elsőre és nem kell várjon sokat a dhcp és a tftp kapcsolatokra. a baj pont akkor van, amikor kilép a pxe romból, és "rombol tovább" :) a merevlemezes boothoz. és ugye valószínü, hogy ezért nem kiabál a hálóra se, mert hiszen akkor már minek. :/

remélem valaki más is tapasztalt ilyet és előbb utóbb fellelek valami megoldást, mert a szép reményeket kissé meglocsolja ricinussal ez a jelenség

--
xterm

Valami Windowsos DHCP szervered van esetleg? Talán olyat tudnál játszani, hogy proxyzod a DHCP kéréseket... de ismerni kellene az infrastruktúrádat, anélkül ugyanis kicsit nehéz lesz értelmes tanácsot adni.

dhcpdump: a manpage erősen ajánlott, az ott levő példa gyk 1:1 kimásolható debug célokra.

További tippjeim:

Ha a gép valami SOHOnál komolyabb switchbe van dugva és van STP (spanning tree)lehet az a kellemetlen szitu, hogy amíg a spanning tree följön, az fél - egy perc. A PXE chip DHCP timeoutja lehet úgyszintén 1 perc. Vagy följön időben vagy nem, viszont addig pedig a hálókártya nem kap linket. Megoldás: vagy beállítod a BIOSban, hogy várjon többet vagy bekapcsolod a portfast opciót, ez esetben viszont kínosan ügyelned kell arra, hogy nehogy valami oda nem illő bridgelés legyen a gépben, ugyanis akkor fénysebességgel megérkezik az eternal doom egy packet storm formájában. A kockázatok és mellékhatások tekintetében kérjük, kérdezze meg hálózatosát vagy kedvenc netes fórumát. (Avagy ennyire értek én is hozzá.)

A dhcpdumppal nézd meg, hogy mi megy, mi jön. Nem túl bonyolult értelmezni, azonban ha bootolni akarsz róla, akkor nézd meg, hogy a next server és a filename ki legyen töltve. Azt is nézd meg, hány option van benne. A fölöslegeseket ki lehetne túrni a packetből. Proof of conceptnek berakhatnál egy Linuxos DHCP-t minimalconfiggal közvetlenül a gépre kötve, hátha kiderül valami.

Ha esetleg olyat látsz, hogy két DHCPACK vagy hasonló jön vissza, akkor nézz körül, láttam néhány olyan beteg howtot, ami két DHCP szerver fölconfolását javasolta. Ez minden esetben kerülendő, egy DHCPvel kell mindent megoldani.

Aztán van olyan az Intel márkájú S5000PAL jelzésű alaplapokon, hogy mint az őrült rángatják magukra a 192.168.30.32-es IP címet. Az arpwatch ezzel rendszeresen telekakilja nekem a logot. Ha esetleg ebben a tartományban vagy, akkor ezt nézd meg. Az arpwatch egyébként is egy hasznos dolog.

Vannak mindenféle packet generátorok, fogd meg a nem működő gép MAC addressét és generálj vele DHCP packetet, nézd meg, úgy működik-e. Ha semmi más nem segít, akkor előveheted a jó öreg wiresharkot és elkezdheted a hálózatot elemeire szedni amíg meg nem oldódik a probléma. Avagy: derüjjön ki.

Ha esetleg nem boldogulsz, adott esetben keress meg magánban, hátha még eszembe jut valami.

nagyon szépen köszönöm az igazán részletes kifejtést! pár szót az eszközökről, mert ez lemaradt, igaz. a pxe kliens egyen géppark, fusi, integrál intel kártyával. a dhcp szerver linuxos (talán deb, de nem 100, hogy tényleg deb. régen az volt). a swichek, routerek, stb. szóval a hálózat gerincét képviselő eszközök cisco kütyük.

viszont kezdem úgy érezni (talán a meleg is közrejátszott), hogy félreérthető voltam. kérlek cáfold meg, ha nem: a pxe boot rendben lemegy, majd amikor "tennivaló nincs", indulna a local boot. és itt akad el. amennyire tudom, addig számít a forgalom a kártyán, ameddig az image-t meg nem kapja. utána akár ki is húzhatom a madzagot, a menüben mászkálhatnék, bootolhatnám a gépet a local boot opcióval, stb.

mivel hétvégén nem foglalkozom vele, ezért ez majd csak leginkább jövő hétre tolódik. de mivel lesznek újabb gépek így felvértezve, ezért kibukhat a dolog. meglátjuk... viszont a dhcp kéréseket figyelni fogom, ha van benne fölös, akkor azt kukázzuk, ha nélkülözhető.

--
xterm

a gép bebootol, pxe indul, user meglátja a menüt. itt a default egy local boot (normál üzemi működés esete). ha lejár a választás ideje, akkor jön a local boot. itt megjelenik a felirat, hogy booting from local harddisk, vagy hasonló (a lényeg, hogy jelzi, hogy boot lesz). és itt áll meg. ha nem lenne ip címe, akkor nem lenne pxe boot által felhúzott menüje se. és a sima local boot úgy is magára ránt majd ipcímet, ha az os beindul. a bot sorrend megváltoztatása esetén, a boot normálisan lezajlik. ez utóbbi arra enged következtetni, hogy nem a gépen levő os a ludas.

--
xterm

Tehát a boot menüt a PXE szolgáltatja? Namost kicsit inkonzisztens nekem a kép, a pxelinux tudtommal nem tud menüt varázsolni. Vagy hogy is van ez? Nem véletlenül a BIOS menüje az, ami ott megjelenik?

Ha ellenben pl Grub 2-t használnál, akkor megérteném, mert azzal nekem is voltak netbootos problémáim (nevezetesen belefagyott a kernel bootolásába).

Na ezt nem tudtam. Ez esetben érdemes megcsinálni Grub 0.97-el, hátha javul egy keveset. Egyébként ha már maintenance mode, nem lenne érdemes csak azokat a gépeket PXEbootoltatni, amiket amúgy is újra kéne telepíteni? Ehhez ugyan hozzá kell nyúlni a DHCP szerverhez, de akár megérheti.

Szerk: ezt a bugot érdemes lehet megnézni.

Közben találtam még hibaleírást, ahol a következőt írják:

Seems that syslinux is not able to boot NTFS partitions.

Én úgy érzem, hogy a pxelinux localboot opciója még egy kissé kiforratlan. :)

Grub: gyakorlatilag van egy halom eszközöd, amit be tudsz bootolni PXE-ről. Tulajdonképpen ezeknek annyit kell tudniuk, hogy a PXE chip TFTPről lerángatja, majd el is indítja őket. A Grubnak is van ilyen lehetősége. Semmi mást nem csinálsz, csak leforgatod, majd ahová a pxelinux.0-t tennéd, oda teszed a pxegrub fájlt és a DHCP szerverben ennek megfelelően átírod az útvonalat. Erről van a neten egy vagon howto, érdemes átrágni magad rajta. Ami a Windowsos boothoz kell Neked, az pedig a chainloader.

Mint írtam, 0.97-es grubot telepíts, a 2-essel nem fog menni a PXE-ről linux kernelt bootolunk. Nekem legalábbis belefagyott. Tekintve, hogy a Grub 2 (sajnos) még experimental, ez nem is meglepő.

Tényleg jó volna egyébként tudni, hogy milyen rendszert akarsz milyen módszerrel telepíteni.

átolvasgatom és tovább lapozgatok a javaslataid alapján, majd végzek kísérleteket a grubos ügyben is. elvégre nekem az is bőven jó, csak működjön. a jelenség különben érdekes, mert ahol előjön, ott sem mindig. amolyan esetleges (30-ból mondjuk egy restart gépenként és mondjuk 2 marad így. újabb restart és egy se, stb).

jelenleg a fog project beüzemelése folyik. tehát gép klónozás. nagyon jól működik amúgy, látszólag semmi hiba a folyamatban. de épp ezért rossz, hogy a fenti, magát a klónozást és ennek központi managelését nem érinti. csak eseti local boot falióra van... (winxp-ket és linuxokat klónoz, indít így a cucc)

--
xterm

1. Bebootol egy miniatűr linux, ami megnézi a particiós táblát, hogy rendben van-e. Ha nem, legyakja és fölmásolja saját magát valamint telepít egy GRUBot, amiben egy jelszóval védett opció az újratelepítés.
2. Lersyncelődik egy WinPE/BartPE az egyik particióra valamint maga a Windows telepítő egy másikra.
3. Újrabootolunk a PE-be, ami belerúg a telepítőbe, hogy települjön föl a 4. particióra.
4. Újraindul a gép, most már a telepítés alatt levő Windowsba bebootolva, unattended telepítés üzemmóddal.