Woher RootFS (Netzwerkboot)

Ich habe die Daten des laufenden Client Systems per NFS auf den Server kopiert. Du kannst
vorher alle unnötigen Prozesse stoppen und Module entladen. Probleme mit /dev hatte ich
keine. Siehe auch hier.

Ich hab das mit meiner SuSE so gemacht:
1. System normal auf platte installieren (wichtig: mit Kernelsourcen)
2. Kernel entsprechend anpassen (DHCP bei boot, RootNFS etc.) Kernel kompilieren und Module backen.
3. init S um in Singleusermode zu wechseln
4. cd / ; tar cvzf /tmp/system.tgz --exclude=/tmp --exclude=/proc ---exclude=/sys *
5. Das tar-Archiv auf den NFS-Server packen und dort mit tar xvzfp system.tgz auspacken.
6. nfsroot/etc/fstab anpassen
7. (ganz wichtig) Im initscript das initialisieren der Netzwerkkarten abschalten. Ich hab dazu im netzwerkscript, welches die Interfaces initialisiert an oberster Stelle ein exit 0 eingebaut. Sonst reinitialisiert der init Prozess das Netzwerkinterface und verliert dabei mal eben nebenbei sein root-FS...

[edit] hatte bei punkt 4 das sternchen vergessen. Kann übrigens sein, dass bei den excludes die führenden / weggelassen werden müssen. Einfach ausprobieren und schauen, ob /tmp etc. ausgelassen werden. So werden auf jeden Fall alle Symlinks und /dev nodes richtig mitkopiert. (Ist ja auch der Sinn eines Tape Archives

[und noch ein edit] - das Schöne an dieser Methode ist, dass du auch direkt ein Backup von deinem Client-System hast...

Zitat

Original von xnalpf
7. (ganz wichtig) Im initscript das initialisieren der Netzwerkkarten abschalten. Ich hab dazu im netzwerkscript, welches die Interfaces initialisiert an oberster Stelle ein exit 0 eingebaut. Sonst reinitialisiert der init Prozess das Netzwerkinterface und verliert dabei mal eben nebenbei sein root-FS...

Warum sollte das denn passieren? Das Netzwerkinterface bekommt bei mir per DHCP die
(gleiche) IP zugewiesen. Warum sollte das root-FS weg sein?

Kann natürlich sein, dass dies SuSE-Spezifisch ist. SuSE macht im init-script einen kompletten Interface reset inklusive releasen der IP und laden des Moduls. In diesem Moment verliert das System den Kontakt zum NFS-Server bevor das Script zum Starten des Interfaces geladen werden kann. Und das war's dann. Wie gesagt. Kann SuSE-spezifisch sein, ist mir aber glaube ich mit LinVDR über NFS auch so passiert. Andere Alternative ist natürlich, das Netzwerkinterface im System gar nicht erst einzurichten. Dann wird es nur beim booten per DHCP einmalig im Kernel-Level konfiguriert und bleibt danach von den init-scripten unangetastet.

Debian meckert, dass das Interface schon konfiguriert sei - weiter nichts. Allerdings war bei mir eine statische IP eingetragen... drum keine Garantie, dass das immer so ist.

Du brauchst keine initrd. Die initrd macht nur sinn um Kernelmodule zu laden, die für das mounten und booten des rootfs notwendig sind. Das ist aber definitiv schon im Kernel drin - nämlich der Netzwerkkartentreiber und die BootDHCP Konfiguration. Danch ist dein rootnfs gemountet und du kannst die Kernelmodule für jede x-beliebige Hardware über deine init-scripte laden. Eine initrd macht da wirklich keinen Sinn.

am besten erzeugt man ein root-fs für Debian mit debootstrap

debootstrap <suite> /path/to/rootfs

Zitat

Original von Soulreaver
xnalpf
Das hatte ich mir kurz nach meinem Post selbst zusammengereimt ist ja auch so, sobald das rootfs da ist und ich auf /lib/modules zugreifen kann, kann ich die sachen von da aus laden.....
Weis auch garnet wieso ich auf den blöden gedanken mit der initrd gekommen binn?!?!?

Hätte mir die Frage auch mit einem Folgepost beantwortet, hatte aber nach meinem letzten Post Gestern Computerverbot
Gruß

Ach ja Computerverbot. Ich glaub ich lass mir von meiner Frau heute auch mal wieder Computerverbot erteilen. Das ist fast wie rausgespült werden.

System.map liegt bei mir in /boot Da wo es immer liegt (bei SuSE)

Ich habe bei meiner Konfiguration eine feste IP-Adresse vergeben:

LABEL desktop
KERNEL vmlinuz-2.6.16.9
APPEND root=/dev/nfs nfsroot=192.168.0.1:/nfsroot/01,rsize=8192,wsize=8192,nfsvers=3 ip=192.168.0.4:192.168.0.1:192.168.0.2:255.255.255.0:

.1 ist der nfs / tftp-Server
.4 der Client
.2 der DSL-Router

ip=bootp sollte eigentlich auch funktionieren; Siehe /usr/src/linux/Documentation/nfsroot.txt

Taucht denn im Logfile vom Server irgendwas auf? Ein Versuch, das nfs-Verzeichnis zu mounten?

/boot kann man ja anlegen, um die System.map dort zu lagern. Muss es ja anderweitig nicht nutzen

Das via DHCP übermittelte Verzeichnis ist nur dafür da, über tftp den Kernel (und evtl. initrd) zu laden - mit NFS hat das nichts am Hut.

Ob der Linux NFS-Root-Code diese Option auswertet, wage ich mal zu bezweifeln. Bin zumindest nicht drübergestoßen, als ich mein System aufgesetzt habe.

Die Kernel-Option " [*] Root file system on NFS" ist gesetzt? Ich denke zwar nicht, dass die Debian-Kernelquellen schuld sind, aber der Vanilla-Kernel wäre einen Versuch wert.

Zitat

Original von Soulreaver

Was meinst du damit?

N Witz aus Men in black II

Zitat

Das ist bei Debian auch so, aber beim Netzboot habe ich kein "/boot".....

Verdammt, mein Kernel will via Netzerk das Rootfs einfach net einhängen!
Ich hab den Treiber der Netzwerkkarte, rootfs via NFS und die IP autoconf fest einkompiliert aber er meckert immer "Unable to mount Root fs"....
Ich teste das ganze mit einem testweise installiertem LTSP sobald ich in der dhcpd.conf meinen Kernel gegen den ausm LTSP tausche läuft alles.

Code

label linux
  kernel bzImage
  append rw root=/dev/ram0 nfsroot=192.168.1.1:/opt/ltsp/i386,rw

Das sieht aber schwer nach lilo.conf aus. Da hat das rein gar nix zu suchen. Das muss in die pxelinux.conf! (Wenn du per PXE bootest, was du bestimmt machst)
[edit] Siehe auch hier

Zitat

ich hab auch schon root=/dev/nfs versucht aber damit meldet er "Cannot open root device "nfs" or unknown-block(2,0)"
Macht auch nach meinem Verständniss keinen Sinn.

Ach ja, wenn ich append ganz weglasse (er bekommt ja sein Verzeichniss via DHCP) gehts auch net

Kann mir jemand helfen?

MfG

Alles anzeigen

Also mal Schritt für Schriit:

1. Datei /etc/dchpd.conf hat dies hier:

host tv {
  hardware ethernet 00:02:b3:1c:c0:b1;
  fixed-address 10.5.10.202;
  filename "pxelinux.0";
        }

2. es gibt ein Verzeichnis /tftpboot und darin ein Unterverzeichnis pxelinux.cfg sowie die Datei pxelinux.0 (aus dem pxelinux bootpaket) in dem Unterverzeichnis /tftpboot/pxelinux.conf gibt es passend zur (o.g.) MAC Adresse eine datei namens 01-00-02-b3-1c-c0-b1 und die sieht so aus:

DEFAULT suse.10
IPAPPEND 1
APPEND vga=0x311 nfsroot=10.5.10.129:/BigVol/nfsroot/wohnzimmer noapic noapm 
TIMEOUT 40

3. Der Kernel, welcher in der DEFAULT direktive angegeben ist liegt ebenfalls in /tftpboot

So ists bei mir konfiguriert und funktioniert mit drei clients hervorragend.

Tja, ich hoffe, du kriegst für dieses Problem ne Lösung präsentiert. Das gleiche Problem hatte ich auch schon mal. Das war dann aber schon der dritte NFS-Boot Client und die anderen liefen schon ganz wunderbar. Daher war ich mir ganz sicher, dass es nicht am Server und/oder Kernel bzw NFS-OS liegen kann. Ich hab dann das Board getauscht (nicht die NIC, nur das Board) und plötzlich lief alles. Meldung an der Konsole war zwar, da SuSE 10.0, etwas anders (no more processes in this runlevel system halted) läuft aber aufs gleiche hinaus. Der init-Prozess kann die Konsolen nicht initialisieren. Komisch ist halt, dass es vom Mainboard abhängt was eigentlich nix mit den Konsolen zu tun haben sollte.