[gelöst] Thin-Client bleibt beim booten stehen

ratibor · 7 Okt. 2009

Hallo,

ich habe ein System über LTSP mit einem Server (an dem ich auch arbeite) und drei Thin-Clients. Zwei der Clients booten über Etherboot, was auch ohne Probleme funktioniert. Der dritte Client bootet mit PXE und bleibt irgendwann bei folgenden Meldungen stehen:

Code:

IP-Config: eth0 hardware address 00:15:58:0e:63:59 mtu 1500 DHCP RARP
[    4.324928] eth0: Media Link On 100mbps full-duplex

die Datei lts.conf sieht folgendermaßen aus:

Code:

# This is the default lts.conf file for ltsp 5.
# For more information about valid options please see: 
# /usr/share/doc/ltsp-client/examples/lts-parameters.txt.gz
# in the client environment

[default] 
    SERVER = 192.168.2.100
    XSERVER = auto
    XDM_SERVER = 192.168.2.100
    X_MOUSE_PROTOCOL   = "PS/2"
    X_MOUSE_DEVICE     = "/dev/psaux"
    X_MOUSE_RESOLUTION = 400
    X_MOUSE_BUTTONS    = 3
    XKBLAYOUT = de
    USE_NFS_SWAP = Y
    SOUND=False
    #SCREEN_01 = startx
    RUNLEVEL = 5
    #LOCALDEV=False
    #CONFIGURE_X=False
    X_COLOR_DEPTH=16


[00:08:54:07:c0:68]
    X_MODE_0 = 1024x768
    LDM_SESSION="/usr/bin/startkde"
    LDM_AUTOLOGIN = True
    LDM_USERNAME = "gast1"
    LDM_PASSWORD = "gast1+"
    LDM_DIREKTX = True

[00:08:54:07:c0:67]
    X_MODE_0 = 1024x768
    LDM_SESSION="/usr/bin/startkde"
    LDM_AUTOLOGIN = True
    LDM_USERNAME = "gast2"
    LDM_PASSWORD = "gast2+"
    LDM_DIREKTX = True

[00:15:58:0E:63:59]
    LDM_AUTOLOGIN = True
    LDM_USERNAME = "gast3"
    LDM_PASSWORD = "gast3+"

dhcpd.conf in /etc/ltsp sieht so aus:

Code:

#
# Default LTSP dhcpd.conf config file.
#

authoritative;

subnet 192.168.2.0 netmask 255.255.255.0 {
    range 192.168.2.100 192.168.2.110;
    option domain-name "homebase";
#    option domain-name-servers 192.168.2.1;
    option broadcast-address 192.168.2.255;
    option routers 192.168.2.1;
    next-server 192.168.2.100;
#    get-lease-hostnames true;
    option subnet-mask 255.255.255.0;
    option root-path "192.168.2.100:/opt/ltsp/i386";

   host erni {
	#filename "/ltsp/i386/vmlinuz";
	server-name "kermit";
	hardware ethernet 00:08:54:07:C0:68;
	fixed-address 192.168.2.101;
	}

   host bert {
	#filename "/ltsp/i386/vmlinuz";
	server-name "kermit";
	hardware ethernet 00:08:54:07:C0:67;
	fixed-address 192.168.2.102;
	}

   host grobi {
	filename "/ltsp/i386/pxelinux.0";
	server-name "kermit";
	next-server 192.168.2.100;
	hardware ethernet 00:15:58:0E:63:59;
	fixed-address 192.168.2.103;
	}

    if substring( option vendor-class-identifier, 0, 9 ) = "PXEClient" {
        filename "/ltsp/i386/pxelinux.0";
    } else {
        filename "/ltsp/i386/nbi.img";
    }
}

und die Datei default in /var/lib/tftpboot/ltsp/i386/pxelinux.cfg sieht so aus:

Code:

prompt 0
label linux
  kernel vmlinuz-2.6.26-2-486
  append rw root=/dev/ram0 initrd=initrd.img vga=normal
  #append init=/linuxrc rw root=/dev/ram0 initrd=initrd.img-2.6.26-2-486


#DEFAULT vmlinuz ro initrd=initrd.img quiet root=/dev/nfs ip=dhcp boot=nfs

Falls Ihr noch andere Daten brauch, kein Problem.
Vielen Dank schon mal für die Hilfe.

Gruß
Wolfgang

TomcatMJ · 7 Okt. 2009

Hi!

ratibor schrieb:
...

und die Datei default in /var/lib/tftpboot/ltsp/i386/pxelinux.cfg sieht so aus:

Code:

prompt 0 label linux kernel vmlinuz-2.6.26-2-486 append rw root=/dev/ram0 initrd=initrd.img vga=normal #append init=/linuxrc rw root=/dev/ram0 initrd=initrd.img-2.6.26-2-486 #DEFAULT vmlinuz ro initrd=initrd.img quiet root=/dev/nfs ip=dhcp boot=nfs

Da dürfte der Denkfehler in der append-Option deiner pxelinux.cfg liegen. Du setzt dort das Root-Device von wo aus dein kernel die initrd laden will auf die RAM-Disk die ja noch gar nichts drin hat zu diesem Zeitpunkt. Da solltest du lieber den NFS-Server oder einen tftp-Server für nehmen und erst in der fstab innerhalb der initrd dein Root-Device dann auf die Ramdisk umverlagern sobald die von dir gewünschten Daten dort über einen entsprechenden Befehl der initrd dort überhaupt erstmal reinkopiert wurden.
Ergo: Du solltest dich für nfs oder tftp entscheiden,dort den Kernel und die initrd ablegen und die initrd so anpassen daß die gewünschetn Inhalte in die RAM-Disk kopiert werden um danach dann dort in der initrd das Root-Device dorthin um zu verlegen.

Bis denne,
Tom

ratibor · 7 Okt. 2009

TomcatMJ schrieb:
Ergo: Du solltest dich für nfs oder tftp entscheiden,dort den Kernel und die initrd ablegen und die initrd so anpassen daß die gewünschetn Inhalte in die RAM-Disk kopiert werden um danach dann dort in der initrd das Root-Device dorthin um zu verlegen.

In der Dokumentation zu ltsp5 bei:
http://www.ltsp.org/~sbalneav/LTSPManual.html#id2700641 steht, dass statt NFS inzwischen NBD verwendet wird. Macht das einen Unterschied oder gibt es mehr Sinn, wieder auf NFS umzustellen?

Ich muss auch zugeben, dass ich das zwar versucht habe, es aber nicht geklappt hat.

Gruß
Wolfgang

TomcatMJ · 8 Okt. 2009

Hm,naja,das kommt wohl drauf an was im verwendeten Kernel einkompiliert wurde. Ich selbst nutze PXELINUX ja nicht für den LTSP sondern für meinen MosNis (siehe dazu in der Linupedia,die Hauptwebsite ist gerade wieder frisch in der Mache*g*) und da habe ich auch ein paar Live-Systeme zu Wartungszwecken integriert bei denen eben NFS-Support ebenso wie TFTP, HTTP und FTP als Root-Device für den Bootvoprgang im jeweils verwendeten Kernel unterstützt ist.

Was nicht als Quelle des Root-Devices im Kernel unterstützt wird kann man dann eben auch nicht als solches benutzen. Mit iSCSI, SAN-Systemen (außer sie unterstützen oben genannte Protokolle) und Konsorten als Root-Device für den Netzwerkboot habe ich diesbezüglich auch noch nicht experimentiert, daher kann ich dazu auch nun nicht viel qualifiziertes zu sagen. Aber da hier noch mehr Leute sind die PXELINUX auf die ein oder andere Art (wohl am ehesten auch mit LTSP) nutzen wird sich hier sicherlich noch wer anderes finden der dazu hier etwas posten wird

*mal zu den LTSP-Usern hier rüberwink um sie herzuwinken*

Da mir hier aber eben dieser prinzipielle Fehler mit der RAM-Disk als Root-Device zum Bootzeitpunkt auffiel wo ja bis dahin erstmal noch gar nichts drin sein kann hatte ich hier halt auch auf diesen Punkt mal hingewiesen. Dürfte ja z7umindest schonmal ein Fehlersuchansatzpunkt sein und ist besser als gar keine Antwort,oder?

Bis denne,
Tom

ratibor · 8 Okt. 2009

Hallo oder Hurra!!!

das Problem ist gelöst, allerdings auf eine eher unkonventionelle Art:
Ich habe einfach eine andere Netzwerkkarte eingebaut, die Datei default in /var/lib/tftpboot/ltsp/i386/pxelinux.cfg wieder in ihren Ursprungszustand versetzt

Code:

DEFAULT vmlinuz ro initrd=initrd.img quiet root=/dev/nfs ip=dhcp boot=nfs

und in den Dateien /etc/ltsp/dhcpd.conf sowie lts.conf die MAC-Adresse entsprechend angepasst.

Oh wunder, es läuft.

Vielen Dank vor allem an Tomcat für die Anregungen, immerhin habe ich dabei noch einiges über NFS und NBD gelernt.

Gruß
Wolfgang

TomcatMJ · 9 Okt. 2009

Hm,das liest sich nun so als wäre das Kernelmodul was deine vorherige Netzwerkkarte benötigt einfach nich in der initrd vorgesehen gewesen. Dazu gäbe es noch einen Trick um diese Netzwerkkarte doch noch nutzen zu können:

Du musst einfach das entsprechende Kernelmodul (welches natürlich zur verwendeten Kernelversion passen muss) in genau das Verzeichnis aus dem der Kernel per PXELINUX geladen wird und fügst bei den Parametern für den kernel ein

Code:

insmod=$BENÖTIGTESKERNELMODUL

hinzu wobei $BENÖTIGTESKERNELMODUL natürlich durch den Kernelmodulnamen ersetzt werden muss.
Ein Beispiel für eine Karte die das e1000.ko (so ist der Dateiname des Moduls) Kernelmodul benötigt: wäre z.B. in einer der Beispieldateien der PXE-Bootmenüs des MosNis zu finden.
Der Relevante Auszug daraus zum veranschaulichen wäre folgende APPEND Parameter-Zeile:

Code:

 APPEND initrd=openSUSE/10.1/64Bit/initrd splash=silent showopts insmod=e100  insmod=e1000 insmod=8139too insmod=forcedeth  install=nfs://192.168.2.1/Installserver/openSUSE/10.1/64Bit/

wobei die Dateien e1000.ko e100.ko 8139too.ko und forcedeth.ko im selben Verzeichnis liegen wie der verwendete Kernel, der dabei ja durchaus woanders liegen darf als die initrd (wozu sonst kann man einen ganzen Pfad angeben bei der Angabe wo die initrd zu finden ist?

)

Aber die Hauptsache ist ja nun daß dein System wie gewünscht endlich läuft, alles weitere hier war somit als noch nachgereichte Zusatzinfo zu sehen für ein genaueres Verständnis des PXE-Bootmechanismus und die möglichen Features diverser Kernel die man so laden kann

Bis denne,
Tom

ratibor · 9 Okt. 2009

Hallo Tomcat,

Vielen Dank noch mal für den Hinweis.
Ich werde das bei Gelegenheit einfach mal testen und kann Dir dann ja Rückmeldung geben, ob es bei mir funktioniert hat. Kann aber ne Weile dauern bis ich dazu komme.
Gruß
Wolfgang

[gelöst] Thin-Client bleibt beim booten stehen

ratibor

Member

TomcatMJ

Guru

ratibor

Member

TomcatMJ

Guru

ratibor

Member

TomcatMJ

Guru

ratibor

Member