[HOWTO] VDR NFS Client auf Ubuntu 8.04 LTS mit debootstrap Installation - obsolet

Zitat

Original von prahn
NFS: Server 192.168.4.11 not responding, still trying
NFS: Server 192.168.4.11 not responding, still trying
NFS: Server 192.168.4.11 not responding, still trying

Tönt jetzt aber mehr nach nem Problem mit dem Server -> was sagt das Server syslog? Zum Beispiel muss der dhcp Daemon den Handshake mit dem Bootsever machen und die Anfrage vom PXE Client abarbeiten: DHCP-Request -> DHCP-Offer

Ich weiss auch nicht wie gut das in ner VM läuft...

Ich kann dir nur raten die Setting durhc zu schauen

Frage: Kann dein Client ab USB Sticks booten? Evtl haust du das Client Image einfach mal auf nen Stick und bootest es so lokal am Client, erzeugst endlich eine lauffähige initrd und hast damit nen Teilerfolg. Kannst dann immer noch rumüben wie man ein initrd auf dem Sever macht mittels chroot.

Ok, das mit dem USB-Stick ist ne Idee... mal sehen wann ich dazu komme.
Mein Syslog am Server sagt Folgendes:

Jan  4 16:22:27 vdr dnsmasq[6124]: DHCPDISCOVER(eth0) 00:0c:29:cf:39:a4 
Jan  4 16:22:27 vdr dnsmasq[6124]: DHCPOFFER(eth0) 192.168.4.53 00:0c:29:cf:39:a4 
Jan  4 16:22:29 vdr dnsmasq[6124]: DHCPREQUEST(eth0) 192.168.4.53 00:0c:29:cf:39:a4 
Jan  4 16:22:29 vdr dnsmasq[6124]: DHCPACK(eth0) 192.168.4.53 00:0c:29:cf:39:a4 
Jan  4 16:22:29 vdr dnsmasq[6124]: TFTP sent /var/lib/tftpboot/pxelinux.0 to 192.168.4.53
Jan  4 16:22:29 vdr dnsmasq[6124]: TFTP error 0 TFTP Aborted received from 192.168.4.53
Jan  4 16:22:29 vdr dnsmasq[6124]: TFTP failed sending /var/lib/tftpboot/pxelinux.0 to 192.168.4.53
Jan  4 16:22:29 vdr dnsmasq[6124]: TFTP sent /var/lib/tftpboot/pxelinux.0 to 192.168.4.53
Jan  4 16:22:29 vdr dnsmasq[6124]: TFTP sent /var/lib/tftpboot/pxelinux.cfg/default to 192.168.4.53
Jan  4 16:22:29 vdr dnsmasq[6124]: TFTP sent /var/lib/tftpboot/vmlinuz-2.6.24-22-generic to 192.168.4.53
Jan  4 16:22:30 vdr dnsmasq[6124]: TFTP sent /var/lib/tftpboot/initrd.img-2.6.24-22-generic to 192.168.4.53
Jan  4 16:22:42 vdr mountd[11025]: authenticated mount request from 192.168.4.53:818 for /netboot/hardy (/netboot/hardy)

Sieht doch eigentlich ok aus, oder?

Ist initrd.img-2.6.24-22-generic sicher das Netboot Initrd?

Wie ist die Log Ausgabe auf dem Client von diesem Boot Vorgang?

Ich kann dir nur empfehlen das Image mal ab USB zu booten. Das gibt dir auch Sicherheit bezüglich der neuen Kernel Module.

kilroy: wäre praktisch wenn das so laufen würde, wär aber um ein kleines Howto froh wie das zu machen ist. In den anderen Howtos von dir wurde es entweder via Kernel bauen gelöst oder via generic-kernel und neuem initrd.

Edit: hab in den Bookmarks noch den Link gefunden wo das stand:

An den Hinweis von MAK hab ich gehalten, anders wollte es bei mir nicht laufen

Finde die Idee gut - betrifft ja nur den Boot-Server Teil der Installation, wenn ich dich richtig verstehe. Als Boot-Client würde sich Hardy ode Intrepid immer noch gut machen.

Kennt jemand eine Möglichkeit, ein Client Boot Image für gleichzeitige Nutzung durch mehrere User fit zu machen? Das Problem dabei ist: Soviel ich weiss werden gewisse Dateien vom Root des 1. Nutzers gelockt, die sind während der Zeit nur durch ihn zugänglich. Ein 2. Root (bootetet dieses Image ab einem anderen Rechner) hat keine Chance diese gelockten Dateien zu verwenden. Hat das schon jemand probiert und eine Lösung gefunden? Vorteile solcher Client Images wäre die simple Updatverwaltung, weil jeder User genau dieses Image nutzt.

Müsste diese hier sein von Kron: [HOWTO] Diskless NFS-Clienten unter Debian mit eigenen Confdir und standartkernel - Ich passe meine PXE Installation mal darauf an, danke!

Zitat

Original von prahn
Ich habe es noch viel einfacher gelöst: Ich habe einfach die Kernel-Version vom Client auf die Kernel Version vom Server angepasst:

Aber nun hängt er bei "Configuring network interfaces"?!?!

Code

root@vdr:/# more /etc/network/interfaces
auto lo
iface lo inet loopback


auto eth0
iface eth0 inet dhcp

Ist doch eigentlich ganz einfach. Zumal DHCP ja bereits funktioniert hat...?! Es ist zum Haare raufen! Was jetzt???

Falls du es nicht schon selbst herausgefunden hast:
der client darf sich keine neue IP mehr anfordern oder setzen. Du solltest eth0 auf manual setzen.

Zitat

Originally posted by diedl2003
Falls du es nicht schon selbst herausgefunden hast:
der client darf sich keine neue IP mehr anfordern oder setzen. Du solltest eth0 auf manual setzen.

das wuerde mich auch mal interessieren, wie das eigentlich gedacht ist. Seit debian sarge behelfe ich mir immer durch folgendes Script in '/etc/rcS.d/S40netfix':

awk '


BEGIN {
    while ("/sbin/ifconfig" | getline line > 0) {
        if (match(line, "^eth0")) {
            ++rootnfs
        }
    }
    close("/sbin/ifconfig")


    if (rootnfs) {
        print "why to reconfigure eth0 for diskless systems here??"


        print "eth0=eth0" >> "/etc/network/run/ifstate"
        close("/etc/network/run/ifstate")
    }
}'

auf diese Weise wird verhindert, dass das folgende Script '/etc/rcS.d/S40networking' fuer NFS Systeme das Interface neu aufsetzt. Was fuer diskless ja herzlich sinnfrei ist:)

Ich versteh' nicht wieso das nicht irgendwann mal offiziell gefixt wird.

- sparkie

Zitat

Originally posted by kilroy
Der Eintrag von

Code

iface eth0 inet manual

in /etc/network/interfaces sorgt doch dafür, dass das Netzwerk nicht noch einmal eingerichtet wird...

ok, das ist richtig. Die Frage ist halt, was sich 'S40networking' eigentlich dabei denkt auf einem diskless System das eigene Interface wegzuschalten:)

Unabhaengig davon, was in '/etc/network/interfaces' konfiguriert ist.

Ich erstelle meine diskless-Clients, indem ich einfach ein Disk-Root-FS auf den NFS Server kopiere, pxeboot, /etc/fstab anpasse - fertig!
Dann muss ich in Zukunft halt ' /etc/network/interfaces' auch noch anpassen. Oder ich lasse meine Automatik von oben drin, die selbst weiss, was sie tun muss.

Vielen Dank fuer den Tipp!

Zitat

Originally posted by kilroy
Da /dev/root per nfs gemountet ist, sollte eigentlich nichts passieren. Wie gesagt: Nur ein kurzer Blick...

genau hier scheint aber u.U. irgendwas nicht immer so zu klappen wie gewuenscht. Kommt auf die ToDo Liste! Bin grad leider an einer anderen Baustelle:D

Ich brauch' ja nur mein Script oben wegzulassen und zu schauen, was er im von dir gezeigten Code dann so macht:)

danke fuer die Tipps auf jeden Fall

Zitat

Originally posted by sparkie

genau hier scheint aber u.U. irgendwas nicht immer so zu klappen wie gewuenscht. Kommt auf die ToDo Liste! Bin grad leider an einer anderen Baustelle:D

so die To_Do Liste wird gerade abgearbeitet:)

der AUfruf von check_network_file_systems() erfolgt sinnigerweise nur beim 'stop' nicht beim 'start' im Script '/etc/rcS.d/S40networking'. Bug oder Feature?

D.h. der konfiguriert ohne meinen Fix von oben gnadenlos das Interface neu. Oder man traegt halt alternativ wirklich 'manual eth0' ein.

Mich wuerde mal interessieren, was mit den Services passiert, die von einem 'ifup' getriggert werden. Da bei NFS das Interface von Anfang an oben ist und bleibt, braucht man hier wieder eine Spezialbehandlung. Naja ist wieder eine andere Baustelle.