ZitatOriginal von kilroy
Wenn Du alle Ressourcen ausgeschöpft hast, versuche das ganze mal in einer VM und eruiere dann die
Unterschiede zu Deinem bestehenden System. Im Moment bin ich mit meinem Latein am Ende.
Hi kilroy,
ich hab das ganze mal in einer VMWare probiert,
und das gleiche Problem, das kein /dev/pts vorhanden ist.
Gruß,
rfehr
Hi Kilroy!
Auch ich habe nochmal ein frisches Ubuntu in VMware installiert, auch hier die gleichen Probs!
Allerdings habe ich nun auf meinem bisherigen System nochmal das mit wget installierte debootstrap deinstalliert und das "normale" debootstrap aus den Ubuntu-Quellen mit "apt-get install debootstrap" installiert.
Dann funzt es!?!
Bin nun schon wesentlich weiter im Setup, denke auch, daß es so durchläuft...
Naja, bin schon wesentlich weiter, hänge aber nun wohl beim Kernel fest. Ich möchte, sofern möglich, gar keinen eigenen Kernel kompilieren.
Habe mich daher für den Standard-Ubuntu-Kernel "2.6.24-16-generic" entschieden, allerdings funktioniert das einhängen der root-Partition via NFS nicht, das Booten wird abgebrochen mit
cannot open root device "nfs"
or unknown-block
Please append a correct "root=" boot option
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-blockIm Server-Syslog taucht nicht mal der nfs mount-request auf...
Mounten lässt sich das Netboot-Verzeichnis, die Übergabe vom Kernel via TFTP funktioniert auch und DHCP läuft auch. Hängt das Problem am Kernel? Der NFS Mount funktioniert (habe mit anderem Client getestet...)
Muß ich wirklich einen neuen Kernel kompilieren? Meiner Erfahrung nach hat der Ubuntu-Kernel alles was ich brauche.
grüss dich prahn
Er sagt dir doch woran es liegt:
cannot open root device "nfs"
or unknown-block
Please append a correct "root=" boot optionIch zeig es dir mal an einem Beispiel:
Die Datei /var/lib/tftpboot/pxelinux.cfg/default anpassen:
LABEL linux
KERNEL vmlinuz-2.6.27-4-generic #das ist der Standard Ubuntu Ibex Kernel
APPEND initrd=initrd.img.netboot rw root=/dev/nfs nfsroot=Deine.Server.IP:/Pfad/zum/Client/Root/Verzeichnis/auf/dem/Server,v3
IPAPPEND 1
Die NFS Root Freigabe muss natürlich stehen und das initrd.img.netboot für netboot erzeugt worden sein.
Klar, die Anpassungen in /var/lib/tftpboot/pxelinux.cfg/default hab ich natürlich gemacht. Meine default sieht so aus:
label linux
kernel vmlinuz-2.6.24-16-generic
append root=/dev/nfs nfsroot=192.168.4.11:/netboot/hardy
ipappend 1Aber wie muß ich eine initrd erstellen??
Habe lediglich die initrd aus dem netboot-System nach /var/lib/tftpboot/ kopiert.
Muß ich da noch mehr tun??
ZitatOriginal von prahn
Habe lediglich die initrd aus dem netboot-System nach /var/lib/tftpboot/ kopiert.
Muß ich da noch mehr tun??
Ich geh davon aus du hast ein neues Initrd erzeugt und nicht einfach das Image für local boot genommen?
Und du bist dir 100% sicher die Root Freigabe funktioniert? Das würde ich testen - notfalls mit nem Live USB booten und die Freigabe kurz in der Konsole mounten. Oder was du auch machen kannst: du kannst auf dem Server selbst die Client Root Freigabe in ein Verzeichnis mounten.
Dann die fstab auf dem client prüfen - ist sie für pxe angepasst? Und stimmen die <dump> <pass> Werte noch? Kommt gerne mal durcheinander
edit: und wo steht in deiner pxelinux config der initrd Eintrag?
Ne, habe kein neues Initrd erzeugt, das ist es ja...
Wie mache ich das???
Die NFS Freigabe funktioniert, habe das von einem anderen Client aus getestet!
Die fstab am Netboot-Client sieht so aus:
proc /proc proc defaults 0 0
# Root-Verzeichnis (der Vollstaendigkeit halber)
192.168.4.11:/netboot/hardy / nfs defaults 0 0
# loop Device fuer Swap-Datei
/dev/loop0 none swap sw,noauto 0 0
# temporaere Verzeichnisse
none /tmp tmpfs defaults 0 0
none /var/run tmpfs defaults 0 0
none /var/lock tmpfs defaults 0 0
none /var/tmp tmpfs defaults 0 0okay - das geht so:
Die Datei /etc/initramfs-tools/initramfs.conf auf dem Client editieren:
Die Zeile mit "BOOT=local" in "BOOT=nfs" ändern.
Jetzt erzeugt man ein neues initrd:
mkinitramfs -v -r PfadzumClientRootverzeichnis -o initrd.img.netboot -d PfadzumClientRootverzeichnis/etc/initramfs-toolsJetzt dieses initrd.img.netboot nach /var/lib/tftpboot/ auf dem Server kopieren
fertig!
edit1 NFS Eintrag in der fstab sollte zusätzliche Optionen haben als nur die defaults:
IP.ZUM.Server:PfadzumClientRoot / nfs defaults,hard,intr,edit2: und mach den pxelinux config eintrag für initrd.img.netboot wie ich oben geschrieben habe
Okay, sehr gut. Danke! Hat funktioniert.
Der Bootvorgang geht nun weiter, aber nun gibts wohl ein Problem bei der Konfiguration der Netzwerkkarte?! Fehlt ein Modul oder nur der Pfad zum Modul??
FATAL: Could not load /lib/modules/2.6.24-16-generic/modules.dep: No such file or directory
FATAL: Could not load /lib/modules/2.6.24-16-generic/modules.dep: No such file or directory
ipconfig: no devices to configure
/init: .: 1: Can't open /tmp/net-eth0.conf
Kernel panic - not syncing: Attempted to kill initDie angegebene Datei ist da, und auch mit Inhalt gefüllt:
root@vdr:/netboot/hardy/lib/modules/2.6.24-16-generic# ls -al /netboot/hardy/lib/modules/2.6.24-16-generic/modules.dep
-rw-r--r-- 1 root root 432523 Jan 3 15:59 /netboot/hardy/lib/modules/2.6.24-16-generic/modules.dep
Was tun?
hast du bei mkinitramfs an sudo gedacht oder warst du schon root? Hab das vergessen zu erwähen...
tippe ich auf nen lese fehler beim erzeugen des initrd - der normale user konnte da nicht lesen weil sudo fehlte
probier mal folgendes:
mkinitramfs -v -r PfadzumClientRootverzeichnis -o initrd.img.netboot -d PfadzumClientRootverzeichnis/etc/initramfs-tools |morejetzt wird dir seitenweise gezeigt was passiert - irgendwo müsste das modul auftauchen und nen lese Fehler zeigen (can't access datei so und so ) das wär die Bestätigung für das Problem
Dann machst du folgendes:
sudo mkinitramfs -v -r PfadzumClientRootverzeichnis -o initrd.img.netboot -d PfadzumClientRootverzeichnis/etc/initramfs-tools |morejetzt müssten alle Fehler weg sein. Und das Image laufen
Ne, das isses nich... konnte im Terminal noch nach oben scrollen, alles ok.
Bin sowieso immer root, trotz Ubuntu (ich weiß, man sollte nicht...)
Und jetzt?
Hmmm... wenn ich mit chroot /netboot/hardy am Server in das Client-System wechsel und ein depmod ausführe kommt auch:
WARNING: Couldn't open directory /lib/modules/2.6.24-22-generic: No such file or directory
FATAL: Could not open /lib/modules/2.6.24-22-generic/modules.dep.temp for writing: No such file or directoryWas hat das zu bedeuten? Userrechte sehen ok aus:
root@vdr:/# ls -ald /lib/modules/2.6.24-16-generic/
drwxr-xr-x 8 root root 4096 Jan 3 16:31 /lib/modules/2.6.24-16-generic/
root@vdr:/# ls -ald /lib/modules/
drwxr-xr-x 3 root root 4096 Jan 3 14:16 /lib/modules/
root@vdr:/# ls -ald /lib/
drwxr-xr-x 13 root root 12288 Jan 3 15:59 /lib/???
tja und jetzt... s'gibt immer so viele Gründe...
Frage: kannst du dieses Client Image mal lokal booten und dann mkintramfs ausführen auf dem Client?
Der Aufruf sieht dann nur noch so aus:
sudo mkinitramfs -v -o initrd.img.netboot
Hintergrund der Überlegung: bin mir selber grad nicht sicher ob der Paramter "-r" wirklich ein "chroot" auslöst, wenn nicht hast du das initrd auf Basis der Servermodule gemacht (weil root war ungewollter Massen der Server-Root und ned der Client-Root)
Kannst das mal machen?i
Erstmal 1000 Dank für die konsequente + zeitnahe Hilfe hier. Super!!
Wie soll ich das Image denn "lokal booten"???
Die Daten liegen auf meinem Raid im Server? Platte kaufen, Daten rüberkopieren und in den Client einbauen, oder wie? Ist ja doch etwas aufwendig...?!
Habe es anders gemacht:
root@vdr:~# chroot /netboot/hardy/
root@vdr:/# mkinitramfs -v -o initrd.img.netboot
Cannot find /lib/modules/2.6.24-22-generic
Hm, hier sucht er nun nach Modulen vom "Server-Kernel" (2.6.24-22) anstatt nach Modulen vom Client-Kernel...
Fällt mir nix mehr zu ein... 
prahn: das ist eben genau der springe Punkt warum es ned geht: wenn du den Client ned mehr booten kannst MUSST du das chroot auf dem Server erzwingen. Ich hab das selber vergeblich versucht und bin dann zur Variante 2 gegangen: Client ein letztes Mal lokal booten und so ein initrd erzeugt.
probier halt mal so - vielleicht geht es ja:
chroot /netboot/hardy/ && mkinitramfs -v -o initrd.img.netboot ¦more
und sonst weiter probiern - wenn du es geschafft hast müssen die von mkinitramfs abgesuchten Pfade immer /netboot/hardy/bla bla/ lauten und nicht nur /bla bla
Würd mich interessieren wie man es richtig macht, prahn - viel Erfolg!
prahn: kannst mir mal die aktuelle Fasssung deiner initramfs.conf zeigen?
Wenn du die mit debootstrap erzeugt hast fehlen da evtl noch Einträge die mkinitramfs benötigt. Kann es nicht mit Sicherheit sagen - muss die Config dazu sehen.
edit: 2. hab ich mir killroys howto nochmal durchgelesen und festgestellt wieso ER kein initrd braucht - der Grund ist einfach "config-2.6.27.zaphod" <- er baut sich den diskless Kernel selber.
Das kann man so machen, muss man aber nicht (bin immer zu faul zum kernel backen 
) und ubuntu hat das eben beides schon drinn im Kernel - die Aktivierung local boot /diskless boot muss aber noch erfolgen, und genau das erledigt die initrd.
Was mich jetzt interessieren würde ist folgendes: hast du prahn den Abschnitt 7 einfach ausgelassen oder wie bist du da vorgegangen? Weil du hast IMHO grundsätzlich recht wenn du meinst du brauchst nicht nen Kernel zu backen, das läuft mit dem generic hardy Kernel + initrd auf pxe umgestellt
Falls das in deiner initramfs.conf noch nicht stimmen sollte evtl die Modules noch auf netboot umstellen? Wenn du Glück hast bringt das schon die Lösung... danach mkinitramfs durchnudeln lassen - machst notfalls alle 4 Varianten (mit/ohne r-Parameter mit/ohne chroot) irgendeine davon muss zum Teufel nochmal laufen 
Ich habe es noch viel einfacher gelöst: Ich habe einfach die Kernel-Version vom Client auf die Kernel Version vom Server angepasst:
Also "apt-get remove *2.6.24-16-generic*" und "apt-get install linux-image-2.6.24-22-generic linux-backports-modules-2.6.24-22-generic linux-ubuntu-modules-2.6.24-22-generic linux-restricted-modules-2.6.24-22-generic".
Lou: Nochmal Danke für Deinen Beistand. Leider weißt Du (und ich) nun immer noch nicht wie das "richtig" geht...
Somit komme ich nun im Boot-Vorgang eine ganze Ecke weiter:
Loading Kernel Modules -> ist durch
Activating swap -> ist durch
Mounting local filesystems -> ist durch
Aber nun hängt er bei "Configuring network interfaces"?!?!
root@vdr:/# more /etc/network/interfaces
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet dhcpIst doch eigentlich ganz einfach. Zumal DHCP ja bereits funktioniert hat...?! Es ist zum Haare raufen! Was jetzt???
ZitatOriginal 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:
Hmm ja... schau, da gibt es einfach ein Problem wenn du solche Sachen machst: du weisst jetzt nicht ob dein Client sich nicht sonst ein Problem dadurch einfängt. Im Prinzip musst du VOR dem Umbau zu PXE Boot 100% sicher sein, dass dein Client Image in dem Zustand noch local booten könnte. Weil der linux-image Wechsel löst wiederum update-initrd Prozesse aus und so weiter und sofort.
Gut gemeinter Rat: spar dir das auf für später, wenn du PXE Booten an sich 100% im Griff hast.
Jetzt zum mkinitrd Problem aus der chroot Umgebung: Hab beim googeln festgestellt, dass die meisten Anleitungen nach dem chroot noch proc einhängen und erst dann mkintramfs auslösen. Liegt es daran? Es klingt plausibel, weil /proc wird wie der root in der 0 0 Stage eingehängt aber eben VOR dem root!
Wobei ich beim googeln auch Dutzende von Problemposts gefunden habe wo mkinitramfs in der chroot Umgebung nicht klar kam. Vielleicht ist das Tool nicht wirklich dafür gemacht ich weiss es nicht... evtl probierst du update-initramfs aus? Vorher erst mal die manpage dazu auswendig lernen...
An den interfaces liegt es nicht soviel ist klar - es steht deswegen an weil dein Client-Root nicht eingängt werden kann. Das wiederum liegt am initrd.
Hab interessenshalber selber mal update-initramfs ausprobiert in ner chroot Umgebung:
chroot /Pfad/zu/deinem/ClientRoot
update-initramfs -k der.kernel.den.du.fuer.pxe.verwendest -c -v
exit
Teste das bitte mal? -c macht dir n'neues initrd
Hat soweit funktioniert, aber das Ergebnis ist das gleiche... es gibt wieder Probleme beim Booten. Habe den Netboot-Test nun in ner VM gemacht, hier das Ergebnis:
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
Tja, verstehe gar nicht warum das so kompliziert ist. Habe das Ende des Sommers schon mal am Laufen gehabt, weiß nur nicht welches Manual ich damals benutzt hatte...?! Bin langsam schon frustriert...
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!