Frage zu Netboot

Elchi · 13. Dezember 2005

Hi, Danke für die Antworten, hab jetzt mal weiter gemacht und bin schon ne Ecke weiter.
Also den DHCP und TFTP Server hatte ich ja gestern schon drauf gemacht und die liefen ja bis auf diese 50sek. Verzögerung. Hab mich vorhin nochmals ein weniger schlauer gelesen und mir erst mal das Syslinuxpacket wegen der pxelinux.0 besorgt und folgendes erledigt. Pxelinux.0, einen Thineis erzeugten Kernel samt Rootfs nach /var/lib/tftpboot kopiert.

[root@charly tftpboot]# ll /var/lib/tftpboot
insgesamt 1880
-rw-r--r-- 1 root root 683996 Dez 12 12:17 kernel
-rw-r--r-- 1 root root 13148 Sep 2 21:16 pxelinux.0
-rw-r--r-- 1 root root 1223032 Dez 12 12:17 rootfs.img

Dann darin ein DIR pxelinux.cfg angelegt mit dem Inhalt:

[root@charly tftpboot]# ll /var/lib/tftpboot/pxelinux.cfg
insgesamt 4
-rw-r--r-- 1 root root 165 Dez 12 12:17 C0A80124
-rw-r--r-- 1 root root 0 Dez 13 13:58 default

Die C0A80124 entspricht der IP die der DHCP Server meinem Client übermittelt, die default ist bisher leer. In der C0A80124 steht dies:

# add tar_verbose to append line to make inittar verbose
TIMEOUT 0
DEFAULT kernel
APPEND noapic load_ramdisk=1 initrd=rootfs.img inittar=1,mode=755 root=/dev/tmpfs

So und nun noch der entscheidende Punkt damit es nicht mehr 50 Sek dauert, in der dhcp.conf muß auf jeden Fall der Eintrag filename "pxelinux.0" stehen, nun dauert es eine Sek., also in der Form:

host vdrclient {
hardware ethernet 00:02:B3:8A:1F:34;
fixed-address 192.168.1.36;
option host-name "vdrclient";
filename "pxelinux.0";
}

So nach einem Neustart des Clienten kommt das:

DHCP MAC ADDR: 00 02 B3 .. .. ..
CLIENT IP: 192.168.1.36 MASK: 255.255.255.0 DHCP IP: 192.168.1.33
GATEWAY IP: 192.168.1.1

PXELINUX 3.11 2005-09-02 Copyright (C) 1994-2003 H. Peter Anvin
UNDI data segment at: 00099240
UNDI data segment size: 4D30
UNDI code segment at: 0009DF70
UNDI code segment size: 1F40
PXE entry point fount (we hope) at 9D9F:0106
My IP address seems to be C0A80124 192.168.1.36
ip=192.168.1.36:0.0.0.0:192.168.1.1:255.255.255.0
TFTP prefix:
Trying to load: pxelinux.cfg/01-00-02-b3-..-..-..
Trying to load: pxelinux.cfg/C0A80124
Trying to load: pxelinux.cfg/C0A8012
Trying to load: pxelinux.cfg/C0A801
Trying to load: pxelinux.cfg/C0A80
Trying to load: pxelinux.cfg/C0A8
Trying to load: pxelinux.cfg/C0A
Trying to load: pxelinux.cfg/C0
Trying to load: pxelinux.cfg/C
Trying to load: pxelinux.cfg/default
Could not find kernel image: linux
boot:

Wobei er bei jeder Stelle der HEX IP ca. 1 Minute wartet. Auch ist mir spanisch warum ip=192.168.1.36:0.0.0.0:192.168.1.1:255.255.255.0 sprich die Subnetmask 0.0.0.0 sein soll. Und warum das Kernelimage "linux" heißt, das muß er ja irgendwo hernehmen.
So jetzt seit ihr wieder gefragt, vielleicht hab ich was vergessen, bin dann erstmal weg.

Elchi

Zitat

Schau mal, ob eine Versionsnummer des Boot-Codes der Karte ausgegeben werden. Die kritische Versionsnummer damals war IMHO 0.99. Hier gibt es ein Update, das auch für deine Karte passen sollte. Schau aber noch mal genau nach.

Also die meldet sich so:

Wintel Boot Agent V 3.0.03
PXE 2.0 Build 078 (WfM2.0) RPL V2.73

Meinste ich soll mal flashen?

andreas_h · 13. Dezember 2005

Probieren würde ichs. Ist 'ne andere Versionsnummer als die, die bei mir Probleme machte. Das Update beinhaltet aber auf jeden Fall einen Boot-Agent Version 4.x (statt 3.0.3) und ist PXE 2.1 kompatibel (gegenüber 2.0).

knebb · 13. Dezember 2005

Zitat

Original von kilroy
Die Optionen werden aber erst übertragen, wenn der Client die IP mit DHCPREQUEST an der Server zurücksendet hat und dieser mit DHCPACK bestätigt (s.o.).

Nada.
Zitat aus dem entsprechenden RFC 2131:

Zitat

DHCPOFFER - Server to client in response to DHCPDISCOVER with
offer of configuration parameters.

DHCPREQUEST - Client message to servers either (a) requesting
offered parameters from one server and implicitly
declining offers from all others, [...]

Alles anzeigen

"With offer of configuration parameters", nicht ausschließlich IP-Adresse. Da dem PXE-Boot notwendige Parameter fehlen, wartet er darauf, ob nicht doch noch ein anderer DHCP-Server ihm diese anbietet. Die Parameter sind bereits in dem ersten DHCPOFFER enthalten.
Sonst müßte der Server diese Parameter erneut anbieten.

Iss so

Nochmal:
Wenn PXE-Boot aktiviert ist, benötigt es natürlich auch entsprechende Parameter. Mindestens muß da "filename" übergeben werden. Diese Datei holt er sich dann von einem (notwendigen) tftp-Server und bootet damit.

Wenn das nicht gegeben ist, wartet PXE eben 30Sekunden, bevor es aufgibt.

Nochmal: Entweder alle Parameter mit übergeben oder PXE deaktivieren.

knebb · 13. Dezember 2005

Zitat

Original von Elchi
So und nun noch der entscheidende Punkt damit es nicht mehr 50 Sek dauert, in der dhcp.conf muß auf jeden Fall der Eintrag filename "pxelinux.0" stehen, nun dauert es eine Sek., also in der Form:

Sach ich doch...aber mir glaubt ja keiner

Meine Datei pxelinux.cfg/default

Code

label rescue
 kernel linux
 append initrd=initrd ramdisk_size=65536 install=nfs://192.168.0.1/srv/ftp/pub/linux/suse/netinstall/SLES9_32 rescue=1


implicit       0
display        message
prompt         1
timeout        200
notice         2

Zitat

Wobei er bei jeder Stelle der HEX IP ca. 1 Minute wartet.

Das sieht mir ja fast so aus, als würde Dein tftp-Server nicht sauber funktionieren.
Probier' das mal mit einem tftp-Client, ob er Dir die Dateien ausliefert.

Ansonsten muß ich jetzt wech. Wenn's nicht klappt, nochma melden.

kilroy · 13. Dezember 2005

Zitat

Original von knebb
Zitat aus dem entsprechenden RFC 2131:

"With offer of configuration parameters", nicht ausschließlich IP-Adresse. Da dem PXE-Boot notwendige Parameter fehlen, wartet er darauf, ob nicht doch noch ein anderer DHCP-Server ihm diese anbietet. Die Parameter sind bereits in dem ersten DHCPOFFER enthalten. Sonst müßte der Server diese Parameter erneut anbieten.
Iss so

Das hat Recht. Und da er offenbar keinen Filenamen übergeben hat, kam es zu der
Verzögerung. Ist mir dei seiner dhcpd.conf nicht ins Auge gefallen. Danke für die Klarstellung.

Elchi:
Ein Beispiel bzgl. tftp Client findest Du u.a. hier

knebb · 13. Dezember 2005

Zitat

Original von kilroy
Danke für die Klarstellung.

Schön, jemanden von meiner MEinung überzeugt zu haben <BASEBALLSCHLÄGER WIEDER WEGSTECK>

Elchi · 13. Dezember 2005

Zitat

Sach ich doch...aber mir glaubt ja keiner

Hab ich jemals dran gezweifelt

Zitat

Das sieht mir ja fast so aus, als würde Dein tftp-Server nicht sauber funktionieren.
Probier' das mal mit einem tftp-Client, ob er Dir die Dateien ausliefert.

Hab also noch den TFTP Client tft-0.40 drauf gemacht und als Root mal "tftp 192.168.1.33 -c get kernel" ausgeführt und siehe da Root hat ein Kernel in seinem Heimatdir bekommen. Also scheint der Server zuklappen auch wenn ich den Client auf dem gleichen Rechner wie den Server ausgeführt habe, das ist ja eigentlich Wurst.
Muß in der default was drin stehen, da die ja eh erst als letztes gehandelt wird.

Elchi

Elchi · 13. Dezember 2005

Zitat

ip=192.168.1.36:0.0.0.0:192.168.1.1:255.255.255.0 sprich die Subnetmask 0.0.0.0

Nein die 0.0.0.0 sollte nicht die Subnetmask sein, sondern die des DHCP/TFTP Servers. Hat jemand ne Idee warum da 0.0.0.0 steht? Ist doch klar das er dann nichts findet.

Elchi

knebb · 13. Dezember 2005

Zitat

Original von Elchi
Muß in der default was drin stehen, da die ja eh erst als letztes gehandelt wird.

Ja, Server scheint zu klappen. Kannst Du auch die Datei Default holen? Und was passiert, wenn Du manuell die (nicht vorhandenen) 0b... holen willst?

Aber es liegt dann wohl am PXELinux. Ist mir zwar unklar, weil er zu diesem Zeitpunkt die Config ja noch garnicht gelesen hat...welche Version hast Du? Gibt's da (siehe README oder ChangeLog) irgendwelche Änderungen?

Komisch, komisch.

MAK · 14. Dezember 2005

@ Elchi

Welchen tftp-server verwendest du? Für pxe wird der tftpd-hpa - HPA's tftp server empfohlen.
Hast du mal den Link beachtet im letzten Post von kilroy? Probier mal die da von mir gepostete dhcpd.conf.
Gruß MAK

Elchi · 14. Dezember 2005

Hi, so weiter geht´s. Hab nochmal das Log befragt:

Zitat

charly in.tftpd[4567]: tftp: client does not accept option

Dabei hab ich im Netz gefunden, das es was mit der Option
server_args = -s /var/lib/tftpboot
auf sich haben soll.

Ohne geht´s natürlich nicht. Also als nächstes die Karte vorsichtshalber auf V4.1.15 geflasht, aber gleicher Zirkus. Leider gibt mir der tftp Server keine Version raus, wie entlocke ich ihm das? Ist der von MDK Cooker.
Dann wieder im Netz nach einer dhcpd.conf gesucht, die oben erwähnte wollte nicht trotz Anpassung, sicher nur nen Syntax Fehler. Hab dann die hier probiert und nun geht´s mit einemAffenspeed bis zum Boot Promt, er meint kann Kernel Image nicht finden, hab dann einfach den Thineis Kernel nach linux umbenannt und schon rauscht er bis zu einem Kernel Panic durch.

Zitat

Please append a correct "root=" boot option
Kernel Panic: VFS: unable to mount root fs on 03:03

Dabei wird das übergeben:
APPEND noapic load_ramdisk=1 initrd=rootfs.img inittar=1,mode=755 root=/dev/tmpfs

Natürlich meltet das Log weiterhin charly in.tftpd[4567]: tftp: client does not accept option, trotz Booten´s.

Wo hat sich hier ein Fehler eingeschlichen?

Elchi

kilroy · 14. Dezember 2005

Zitat

Original von Elchi
Leider gibt mir der tftp Server keine Version raus, wie entlocke ich ihm das? Ist der von MDK Cooker.

Code

[root@trillian root]# in.tftpd -V    
tftp-hpa 0.36, with remap, with tcpwrappers

oder

Code

[root@trillian root]# rpm -qi tftp-server
Name        : tftp-server                  Relocations: (not relocatable)
Version     : 0.36                              Vendor: Mandrakesoft
Release     : 1mdk                          Build Date: Di 04 Mai 2004 18:50:46 CEST
...

Zitat

Dabei wird das übergeben:
APPEND noapic load_ramdisk=1 initrd=rootfs.img inittar=1,mode=755 root=/dev/tmpfs

Ich hab's ohne initrd laufen (root=/dev/nfs). Ist der Kernel denn geeignet, mit root über nfs
zu arbeiten oder wird das mit dem initrd "übergangen"?

Elchi · 14. Dezember 2005

Zitat

[root@trillian root]# in.tftpd -V
tftp-hpa 0.36, with remap, with tcpwrappers

Ok hast gewonnen, dachte -v sei der Schlüssel bzw. --help

tftp-hpa 0.40, with remap, with tcpwrappers

Also wäre das richtig so.

Zitat

Ich hab's ohne initrd laufen (root=/dev/nfs). Ist der Kernel denn geeignet, mit root über nfs
zu arbeiten oder wird das mit dem initrd "übergangen"?

Ich denke mal das rootfs.img spiegelt ein / im Ram wieder, also nix per NFS. Warum er hängen bleibt ist noch herauszubekommen.

knebb · 14. Dezember 2005

Zitat

Original von ElchiIch denke mal das rootfs.img spiegelt ein / im Ram wieder, also nix per NFS. Warum er hängen bleibt ist noch herauszubekommen.

Warum er hängen bleibt? Wahrscheinlich steht da was von "no init found" oder so.

Du mußt ihm natürlich auch sagen. welches Dateisystem er als / mounten soll. Die temporäre Sache macht er automatisch. Aber das RICHTIGE Rootfs braucht er halt auch. Also sowas wie server:/pfad/zum/rootfs

Elchi · 14. Dezember 2005

Zitat

Warum er hängen bleibt? Wahrscheinlich steht da was von "no init found" oder so.

Nein.

Zitat

Aber das RICHTIGE Rootfs braucht er halt auch. Also sowas wie server:/pfad/zum/rootfs

Nein, Thineisfair läuft komplett im RAM, also root=/dev/tmpfs, nix Server.

knebb · 14. Dezember 2005

Zitat

Original von Elchi
Nein, Thineisfair läuft komplett im RAM, also root=/dev/tmpfs, nix Server.

Ändert nix daran, daß er ein Dateisystem irgendwoher bekommen muß. Und dafür mußt Du den richtigen Parameter angeben. Dann läuft das auch. Wenn, ja wenn, der Kernel entsprechend konfiguriert ist.

Aber das sind jetzt Sachen, da mußt Du selber durch- weil das spezielle Kernelwünsche sind

Elchi · 14. Dezember 2005

Kennst du thineisfair? Das sollte sich eigentlich allein kümmern, der Konfigurator gibt nur an was er will.
Das schöne ist ja, von CD aus klappts aber.
Aber Danke erstmal für eure tatkräftige Unterstützung.

Elchi

Sevo · 14. Dezember 2005

Hab den Thread irgendwie übersehen,
Also:

Zitat

APPEND noapic load_ramdisk=1 initrd=rootfs.img inittar=1,mode=755 root=/dev/tmpfs

ist richtig. Liegt die rootfs.img auch im selbern Verzeichnis wie der Kernel? (Die Pfade müssen relativ zum tftpboot Verzeichnis sein)

Ich vermute mal dass das Image nicht richtig übertragen wird. Ganz am Anfang muss "loading kernel ......" und "loading rootfs.img ......." kommen. Ist das bei dir der Fall?

Kannst du mal die letzten Zeilen (ca. 10) vor dem Fehler posten? Erstmal rausfinden ob er das Image überhaupt entpackt.

Gruß,
Sevo

Elchi · 14. Dezember 2005

Zitat

Liegt die rootfs.img auch im selbern Verzeichnis wie der Kernel

Ja.

Zitat

Ich vermute mal dass das Image nicht richtig übertragen wird. Ganz am Anfang muss "loading kernel ......" und "loading rootfs.img ......." kommen. Ist das bei dir der Fall?

Mhm, das geht alles zu fix, ein Drücken auf PAUSE bringt nichts, Keyboard blockiert natürlich. Gibt´s noch ne Möglichkeit, Monitor festhalten oder so
Also was ich sehen kann, ne Ramdisk wird erzeugt.

Mal was anderes, kann es sein das ich vor lauter Aufregung ein opt Packet was für Netboot nötig ist, vergessen hab? Bei CdBoot braucht es ja auch das opt_hd.

Elchi

Sevo · 14. Dezember 2005

Hi Elchi!

Zitat

Mhm, das geht alles zu fix, ein Drücken auf PAUSE bringt nichts, Keyboard blockiert natürlich. Gibt´s noch ne Möglichkeit, Monitor festhalten oder so :Di

Du kannst "console=ttyS0,9600n8" anhängen und entweder am COM1 mitloggen, oder das Ganze mal in VmWare probieren. VmWare kann alles was über Seriell rausgeht in eine Datei loggen.

Zitat

Also was ich sehen kann, ne Ramdisk wird erzeugt.

der bleibt doch beim Kernel Panic stehen, dann solltest du die letzten Zeilen davor auch lesen können. Da steht nämlich alles darüber ob richtig entpackt wurde und so.

Zitat

Mal was anderes, kann es sein das ich vor lauter Aufregung ein opt Packet was für Netboot nötig ist, vergessen hab? Bei CdBoot braucht es ja auch das opt_hd.

Nein, da der Kernel immer der selbe ist. Die Funktion ist in den Kernel einkompiliert, da in dem Stadium er ja noch nicht auf die (durch die Konfiguration) veränderlichen daten, also das Image zugreifen kann. Bei CD-Boot wird auch zuerst das Image (mit Syslinux und daher Treiberunabhängig, da BIOS Funktion) in den Speicher/Ramdisk geladen und erst danach der Treiber. Da, wie du schreibst, CD-Boot funktioniert, wird es entweder an der PXE/TFTBOOT/DHCP Konfiguration oder an der Netzwerkkarte liegen. Hast du mal ne andere NIC probiert?

Gruß,
Sevo

Frage zu Netboot

Jetzt mitmachen!

Teilen