pxe boot endet in busybox

berni51

berni51

Open-Net-FreeBSD user
Hi,
ich möchte ein paar ältere NUCs und Brixs diskless laufen lassen und via pxeboot starten. Dazu hab ich einen Pi4 (8GB) mit einem Devuan als dnsmasq-Server eingerichtet. Darauf befinden sich mehrere Linux Bootimages (devuan & Refracta).
NUC und brix finden auch den Bootserver und rufen brav das von mir erstellte Auswahlmenü auf. Es enthält die Aufrufe
  • Devuan minimal-live
  • Devuan desktop-live
  • Refracte-nox
  • memtest

Leider führt nur der Aufruf von memtest zu einem korrekten Ergebnis. Bei den drei Linuxen startet zunächst normal der Linux-Bootvorgang, um dann aber jedesmal in der busybox von initram zu enden. Die enthält zwar reichlich Kommandos, aber das ist natürlich kein vernünftiges System.
Verlasse ich mit "exit" die busybox, gibt es die Meldung:
Code: 
mounting of /ROOT failed.
Klar, das kann natürlich nix werden - nur warum?

Code: 
Dec 12 23:10:45 dnsmasq[1674]: gestartet, Version 2.85, DNS abgeschaltet
Dec 12 23:10:45 dnsmasq[1674]: Optionen bei Übersetzung: IPv6 GNU-getopt DBus no-UBus i18n IDN2 DHCP DHCPv6 no-Lua TFTP conntrack ipset auth cryptohash DNSSEC loop-detect inotify dumpfile
Dec 12 23:10:45 dnsmasq-dhcp[1674]: DHCP, Proxy im Subnetz 192.168.0.0
Dec 12 23:10:45 dnsmasq-tftp[1674]: TFTP Wurzel ist /home/data/netboot 
Dec 12 23:11:53 dnsmasq-dhcp[1674]: PXE(eth0) 94:c6:91:11:06:22 proxy
Dec 12 23:11:57 dnsmasq-dhcp[1674]: PXE(eth0) 192.168.0.71 94:c6:91:11:06:22 bios/pxelinux.0
Dec 12 23:11:58 dnsmasq-tftp[1674]: Fehler 0 TFTP Aborted von 192.168.0.71 empfangen
Dec 12 23:11:58 dnsmasq-tftp[1674]: /home/data/netboot/bios/pxelinux.0 an 192.168.0.71 verschickt
Dec 12 23:11:58 dnsmasq-tftp[1674]: /home/data/netboot/bios/pxelinux.0 an 192.168.0.71 verschickt
Dec 12 23:11:58 dnsmasq-tftp[1674]: /home/data/netboot/bios/ldlinux.c32 an 192.168.0.71 verschickt
Dec 12 23:11:58 dnsmasq-tftp[1674]: Datei /home/data/netboot/bios/pxelinux.cfg/7ea11317-78b9-28a5-9593-94c691110622 nicht gefunden
Dec 12 23:11:58 dnsmasq-tftp[1674]: Datei /home/data/netboot/bios/pxelinux.cfg/01-94-c6-91-11-06-22 nicht gefunden
Dec 12 23:11:58 dnsmasq-tftp[1674]: Datei /home/data/netboot/bios/pxelinux.cfg/C0A80047 nicht gefunden
Dec 12 23:11:58 dnsmasq-tftp[1674]: Datei /home/data/netboot/bios/pxelinux.cfg/C0A8004 nicht gefunden
Dec 12 23:11:58 dnsmasq-tftp[1674]: Datei /home/data/netboot/bios/pxelinux.cfg/C0A800 nicht gefunden
Dec 12 23:11:58 dnsmasq-tftp[1674]: Datei /home/data/netboot/bios/pxelinux.cfg/C0A80 nicht gefunden
Dec 12 23:11:58 dnsmasq-tftp[1674]: Datei /home/data/netboot/bios/pxelinux.cfg/C0A8 nicht gefunden
Dec 12 23:11:58 dnsmasq-tftp[1674]: Datei /home/data/netboot/bios/pxelinux.cfg/C0A nicht gefunden
Dec 12 23:11:58 dnsmasq-tftp[1674]: Datei /home/data/netboot/bios/pxelinux.cfg/C0 nicht gefunden
Dec 12 23:11:58 dnsmasq-tftp[1674]: Datei /home/data/netboot/bios/pxelinux.cfg/C nicht gefunden
Dec 12 23:11:58 dnsmasq-tftp[1674]: /home/data/netboot/bios/pxelinux.cfg/default an 192.168.0.71 verschickt
Dec 12 23:11:58 dnsmasq-tftp[1674]: /home/data/netboot/bios/vesamenu.c32 an 192.168.0.71 verschickt
Dec 12 23:11:59 dnsmasq-tftp[1674]: /home/data/netboot/bios/libcom32.c32 an 192.168.0.71 verschickt
Dec 12 23:11:59 dnsmasq-tftp[1674]: /home/data/netboot/bios/libutil.c32 an 192.168.0.71 verschickt
Dec 12 23:11:59 dnsmasq-tftp[1674]: /home/data/netboot/bios/pxelinux.cfg/default an 192.168.0.71 verschickt
Dec 12 23:12:17 dnsmasq-tftp[1674]: /home/data/netboot/boot/amd64/devuan/minimal-live/live/vmlinuz an 192.168.0.71 verschickt
Dec 12 23:12:21 dnsmasq-tftp[1674]: /home/data/netboot/boot/amd64/devuan/minimal-live/live/initrd.img an 192.168.0.71 verschickt

Das Logfile bringt mich auch nicht recht weiter! Die nicht gefundenen Dateien existieren in der Tat nicht, im Verzeichnis pxelinux.cfg befindet sich ldiglich die Datei "default", die das Menüsystem für pxeboot enthält.
Brauch ich möglicherweise spezielle pxeboot-Images?

Berni
 
berni51 schrieb:
Darauf befinden sich mehrere Linux Bootimages (devuan & Refracta).
Zum Vergrößern anklicken....

Hi,

meinst du hier mit "Linux Bootimages" die images die du zb auf nen Stick oder ne CD-Brennen würdest?

Wenn ja wird das nicht funktionieren, für solche images braucht man soweit ich weiß einen chain-loader in verbindung mit PXE, ich hatte mir das vor Jahren mal angeschaut aber ob der unverhoften komplexität nicht weiter verfolgt.

Früher (tm) war wohl der gängige weg das root auf NFS zu haben, ich glaube das ging auch mit OpenBSD, ich weiß aber nicht wie aktuell das noch ist.
 
@CommanderZed : Hatte tatsächlich geglaubt, das würde mit "normalen" Boot-Images funktionieren. Der Kenel wird ja auch prima gebootet, aber beim initramfs hörts auf.
Also brauche ich wohl richtige netimages. :confused:
 
berni51 schrieb:
Also brauche ich wohl richtige netimages. :confused:
Zum Vergrößern anklicken....
Ich hatte das früher (tm) mal mittels tftp am laufen, da brauchte man ein paar Dateien (pxelinux.0, vesamenu.c32, menu.c32, memdisk, mboot.c32, chain.c32) aus dem "syslinux" Paket im Verzeichnis vom tftp Server (/var/lib/tftpboot), die Datei pxelinux.0 musste man im dhcp Server als Boot-Image mit angeben:

/etc/dhcp/dhcpd.conf
Code: 
        allow booting;
        allow bootp;
        next-server <IP of TFTP Server>;
        filename "pxelinux.0";

Im PXE Bootmenu Config File musste man dann noch den Pfad zum jeweiligen Kernelfile (meist das mit Namen vmlinuz) und der dazugehörigen initrd.img mitsamt der Transfermethode (z.B http) angeben.

EDIT: hab grad gesehen, das war aus dem Menu zum Installieren von ner Distri - du brauchst ja ne bootbare fertige Installation?

hier noch der Menu-Eintrag von damals, /var/lib/tftpboot/pxelinux.cfg/default, vielleicht hilfts doch noch was:

Code: 
default menu.c32
prompt 0
timeout 300

menu title *** PXE Boot Menu ***
label 1
 menu label ^1) Boot from local ^HD (default)
 localboot 0

label 2
 menu label ^2) Install CentOS 6.7 i386 (32 bit)
 kernel centos67_i386/images/pxeboot/vmlinuz
 append initrd=centos67_i386/images/pxeboot/initrd.img \ 
 method=http://<TFTP IP>/centos67_i386 devfs=nomount
 
Ich hab das mit dnsmasq aufgesetzt. Das enthält ja tftp gleich mit. Die Syntax der dnsmasq.conf sieht beinahe genauso aus wie die von @turrican. Auch die benötigten Dateien sind die gleichen wie oben beschrieben.
Aber die Sache funktioniert trotzdem nicht - noch nicht. Vielleicht liegt das Problem ja DHCP Server. Das macht hier ja eine Fritzbox und der dnsmasq soll nur als Proxy laufen. Wenn der Client keine IP erhält, klappts ja wohl auch mit dem Mounten von /root nicht.
Oder such ich in der völlig falschen Richtung?

Berni
 
Wenn der Client keine IP erhält - dann kann er eigentlich gar nichts machen; der initiale Transfer der Datei pxelinux.0 folgt erst danach.

Wie gibst du dem dhcp an der FB die pxelinux.0 mit? Kann das da mit angegeben werden
 
Er muss ja eine IP sowie die config erhalten, sonst würde er garnicht erst den Linux-Kernel laden?

Er bootet ja den kernel und die initrd.img soweit ich das sehe, bekommt aber kein rootfs, kein /

Ich denke das ist genau das was meine recherchen damals ergeben haben, er bootet den kernel, weiß aber dann nicht wie er das rootfs des images gemountet bekommt, denn das liegt ja nicht für in einen für ihn mountbaren punkt. Achtung: Mega gefährliches Halbwissen

Weder kann der kernel Dateisysteme per http noch per tftp mounten, oder sich ein image herunterladen und dann in den RAM entpacken und dort als ramdisk mounten. Soweit ich weiß kann der Kernel in diesem moment nur nfs

Es gibt aber möglichkeiten, das ist dann entweder ein an sich modifiziertes linux vmlinuz oder diese chainload geschichte, die soweit ich das verstanden habe so tut als wäre es eine festplatte für das zu bootende system (Frag mich nicht nach den details)
Dadurch kann man dann auch zb eine Windows-ISO booten sollte man sowas brauchen.
 
@turrican:
Die Fritzbox kann leider mit pxeboot gar nichts anfangen, das soll ja dnsmasq übernehmen. Die Konfigurationsdatei dafür sieht so aus:
Code: 
port=0
interface=eth0
dhcp-range=192.168.0.0,proxy
enable-tftp
tftp-root=/home/data/netboot
pxe-service=x86PC,"PXELINUX (BIOS)",bios/pxelinux
pxe-service=x86-64_EFI,"PXELINUX (EFI)",efi64/syslinux.efi
log-queries
log-facility=/var/log/dnsmasq.log

@CommanderZed :
Schätze, das ist genau der Punkt. Ich beschäftige mit jetzt mal mit ipxe, bin aber noch in der Experimentierphase. Und ich bin auf der Suche nach einem lupenreinen Netbootimage.
 
Wenn du was hinbekommst und zb einfach ne iso zum booten kriegst wie da teilw. beschrieben würde ich mich wahnsinnig über eine kurzanleitung freuen :)
 
Wie gesagt, wenn dein Client schon keine IP vom DHCP bekommt, dann wird alles andere eh erstmal hinfällig.
Ich denke, dass es besser wäre wenn der dnsmasq das alles komplett handelt, also ab Ausgabe der IP an den Client.

Du könntest dazu als Test mal diese IP an der Fritzbox vom DHCP ausnehmen und dem dnsmasq die Kontrolle darüber geben - bzw einen Teil der IP-Range vom dnsmasq für diese Zwecke handhaben lassen, und den Bereich auf der FB entsprechend einschränken.

Die sog. "netimages" welche im Netz verfügbar sind für ein Linux-OS - das waren meiner Erfahrung nach immer Images zur Installation einer Distribution, aber keine installierten Versionen;
Du könntest zum Test eine Version mittels chroot in ein /home/data/netboot/<Distri> Verzeichnis installieren und von da aus den kernel und initrd per pxe zu starten versuchen.
 
turrican schrieb:
Die sog. "netimages" welche im Netz verfügbar sind für ein Linux-OS - das waren meiner Erfahrung nach immer Images zur Installation einer Distribution, aber keine installierten Versionen
Zum Vergrößern anklicken....
So kenne ich das auch, net bedeutet hier, dass das Installationsimage auf eine Netzanbindung angewiesen ist, da es sich die zu installierenden Pakete aus dem Netz ziehen muss. Im Gegensatz zur DVD (hier liegen die Pakete auf dem Installationsmedium) ist dadurch das Image als solches kleiner.

Rob
 
turrican schrieb:
Wie gesagt, wenn dein Client schon keine IP vom DHCP bekommt, dann wird alles andere eh erstmal hinfällig.
Ich denke, dass es besser wäre wenn der dnsmasq das alles komplett handelt, also ab Ausgabe der IP an den Client.
Zum Vergrößern anklicken....

Wie kommst du dadrauf das der Client keine IP bekommt?
Wie soll er ohne IP sich nen Kernel per TFTPgezogen haben? Und im Kernel-Log steht doch eine drinn.

turrican schrieb:
Du könntest dazu als Test mal diese IP an der Fritzbox vom DHCP ausnehmen und dem dnsmasq die Kontrolle darüber geben - bzw einen Teil der IP-Range vom dnsmasq für diese Zwecke handhaben lassen, und den Bereich auf der FB entsprechend einschränken.
Zum Vergrößern anklicken....
Unfug, er müsste die Mac aus der FritzBox rausnehmen, würde aber auch nichts bringen da der DHCP vom client genommen wird der als schnellstes reagiert. Offensichtlich aber unnötig da er ja per PXE bootet, das würde er nicht machen wenn er nur die dhcp infos der FB bekommen würde.

turrican schrieb:
Die sog. "netimages" welche im Netz verfügbar sind für ein Linux-OS - das waren meiner Erfahrung nach immer Images zur Installation einer Distribution, aber keine installierten Versionen;
Zum Vergrößern anklicken....
ja

turrican schrieb:
Du könntest zum Test eine Version mittels chroot in ein /home/data/netboot/<Distri> Verzeichnis installieren und von da aus den kernel und initrd per pxe zu starten versuchen.
Zum Vergrößern anklicken....
Das funktioniert afaik mit vanilla pxe und linux nur wenn er das per nfs exportiert und auch mountet, da man per tftp zb kein fs mounten kann
 
Sehr gute Hinweise, das werd ich heut abend mal umsetzen.
Tatsächlich scheinen nahezu alle Images reine Installationsimages zu sein, obwohl in einer Abhandlung auf der Debian-Seite auf die Unterschiede hingewiesen wird.
Wie Du das mit der chroot-Installation meinst, ist mir nicht ganz klar. Die bisherigen 4 Installationen (hab noch Knoppix dazu genommen) hab ich mittels Mounten der Isos und anschliessendem rsync auf das Verzeichnis vom tftpboot gemacht. Ist das nicht das, was Du meinst?
 
berni51 schrieb:
Wie Du das mit der chroot-Installation meinst, ist mir nicht ganz klar. Die bisherigen 4 Installationen (hab noch Knoppix dazu genommen) hab ich mittels Mounten der Isos und anschliessendem rsync auf das Verzeichnis vom tftpboot gemacht. Ist das nicht das, was Du meinst?
Zum Vergrößern anklicken....

Ich glaube was er vorschlägt ist anstelle die so zu entpacken eine Betriebsysteminstallation dort durchzuführen

Das führt aber zu dem exakt gleichen Problem: Der Linux-Kernel kann kein / (root) per tftp mounten. Damit nach dem Kernel der Boot aber weitergehen kann braucht das Linux ein funktionsfähiges, für ihn als Dateisystem (!!!) mountbares / verzeichniss - bei einer normal gebooteten CD oder USB-Stick wird einfach das genommen da das ein format ist das der Kernel kennt und lokalmounten kann.

TFTP ist aber kein "Format" das der Kernel in irgend einer weise beim boot als Dateisstem mounten kann.
 
CommanderZed schrieb:
Wie kommst du dadrauf das der Client keine IP bekommt?
Zum Vergrößern anklicken....
Commander, das schrieb berni weiter oben selber, schau mal nach.

CommanderZed schrieb:
Unfug, er müsste die Mac aus der FritzBox rausnehmen, würde aber auch nichts bringen da der DHCP vom client genommen wird der als schnellstes reagiert.
Zum Vergrößern anklicken....
was is da genau Unfug?
In der FB kann man "schnell mal" die dhcp-Range "von-bis" ändern, ohne groß sonst was zu ändern, um schnell mal was auszuprobieren.
Das ist doch ein gangbarer Weg - hab ja nicht behauptet, dass es der einzige ist - vielleicht hast du auch nen besseren.
 
AH ja, zur IP: Die wird ja tatsächlich erstmal vergeben (192.168.0.71), dann werden kernel und initram geladen. Letzteres scheitert aber, und wenn das System dann in der Busybox endet, hat die Schnittstelle keine IP mehr. Kann ich ja mit dem busybox-ifconfig abfragen.
Lass ich dann mit dem busybox-udhcpc eine IP abholen, bekommt eth0 auch eine IP - aber nur eine IPv6. Merkwürdig!

Eine Betriebssystem-Installation kann ich wohl auf dem raspi nicht durchführen. Ich will ja keine arm64 Clients booten, sondern X86er.
 
turrican schrieb:
was is da genau Unfug?
In der FB kann man "schnell mal" die dhcp-Range "von-bis" ändern, ohne groß sonst was zu ändern, um schnell mal was auszuprobieren.
Das ist doch ein gangbarer Weg - hab ja nicht behauptet, dass es der einzige ist - vielleicht hast du auch nen besseren.
Zum Vergrößern anklicken....

Wenn du den rausnimmst macht er aber trotzdem noch den DHCP-Server, unabhängig von der "Range" - der client schickt ne DHCP anfrage per Broadcast raus, der Server der zuerst antwortet "gewinnt" - das ist ganz unabhängig von der Range.

Möchte man sicher gehen das ein bestimmter DHCP Server im Netz verwendet wird muss man idr. sicher stellen das kein anderer mehr aktiv ist, also komplett abschalten.

(Einzige einschränkung hier: Man kann auf layer2 da mit manchen Managed Switchen was alterntives bauen)

turrican schrieb:
Commander, das schrieb berni weiter oben selber, schau mal nach.
Zum Vergrößern anklicken....

Naja, wenn der Kernel nach dem Boot über nen fehlendes / meckern kann, wurde halt gebootet ... da er nur booten kann wenn er ne IP bekommen hat weil man ohne halt nichts per TFTP bekommt ...
 
Daaaaaaaaaaaas kann sehr sehr gut sein :)
:) :)

Übel wirds tatsächlich erst wenn zwei die gleiche Range haben und die gleiche Addresse an zwei Clients verteilt wird die dann einen IP-Addresskonflikt haben
 
CommanderZed schrieb:
Übel wirds tatsächlich erst wenn zwei die gleiche Range haben und die gleiche Addresse an zwei Clients verteilt wird die dann einen IP-Addresskonflikt haben
Zum Vergrößern anklicken....
Das fällt unter Umständen auch lange nicht auf...

Den dhcp gleich auf dem dnsmasq anstatt der FB zu haben wäre halt eleganter, da man da u.a. in den Logs besser sehen kann was genau passiert;
Interessant wäre, wie der Ablauf bei berni51 ausschaut, auf nem "normalen" Server (nicht-FB) kriegt man schön den kompletten Ablauf im Log (wenn nicht, is eh was komplett im argen), vom DHCPDISCOVER, über -OFFER, REQ, ACK zum PXE, file, sent usw...
Bei der FB sieht man da so gut wie gar nichts im Logfile.
 
Hab mal den dnsmasq den DHCP-Job machen lassen. Tatsächlich war er schneller als Fritz und hat brav eine IP vergeben:
Code: 
Dec 14 18:05:41 dnsmasq-dhcp[1616]: 3724631105 verfügbarer DHCP-Bereich: 192.168.0.230 - 192.168.0.235
Dec 14 18:05:44 dnsmasq-dhcp[1616]: 3724631105 DHCPDISCOVER(eth0) f0:de:f1:07:fb:46
Dec 14 18:05:44 dnsmasq-dhcp[1616]: 3724631105 Marken: eth0
Dec 14 18:05:44 dnsmasq-dhcp[1616]: 3724631105 DHCPOFFER(eth0) 192.168.0.233 f0:de:f1:07:fb:46
Dec 14 18:05:44 dnsmasq-dhcp[1616]: 3724631105 angeforderte Optionen: 1:netmask, 28:broadcast, 2:time-offset, 3:router,
Dec 14 18:05:44 dnsmasq-dhcp[1616]: 3724631105 angeforderte Optionen: 15:domain-name, 6:dns-server, 12:hostname
Dec 14 18:05:44 dnsmasq-dhcp[1616]: 3724631105 nächster Server: 192.168.0.77
Dec 14 18:05:44 dnsmasq-dhcp[1616]: 3724631105 sent size:  1 option: 53 message-type  2
Dec 14 18:05:44 dnsmasq-dhcp[1616]: 3724631105 sent size:  4 option: 54 server-identifier  192.168.0.77
Dec 14 18:05:44 dnsmasq-dhcp[1616]: 3724631105 sent size:  4 option: 51 lease-time  1h
Dec 14 18:05:44 dnsmasq-dhcp[1616]: 3724631105 sent size:  4 option: 58 T1  30m
Dec 14 18:05:44 dnsmasq-dhcp[1616]: 3724631105 sent size:  4 option: 59 T2  52m30s
Dec 14 18:05:44 dnsmasq-dhcp[1616]: 3724631105 sent size:  4 option:  1 netmask  255.255.255.0
Dec 14 18:05:44 dnsmasq-dhcp[1616]: 3724631105 sent size:  4 option: 28 broadcast  192.168.0.255
Dec 14 18:05:44 dnsmasq-dhcp[1616]: 3724631105 sent size:  4 option:  3 router  192.168.0.77
Dec 14 18:05:44 dnsmasq-dhcp[1616]: 3724631105 verfügbarer DHCP-Bereich: 192.168.0.230 - 192.168.0.235

Ansonsten hat sich aber nix verändert, das heisst, der Bootvorgang endet in der Busybox. Wie der Commander schon sagte, klappt das Mounten des /root nicht.
Als nächstes werd ich mich mit ipxe befassen. Ich berichte weiter.

Berni
 
berni51 schrieb:
Hab mal den dnsmasq den DHCP-Job machen lassen. Tatsächlich war er schneller als Fritz und hat brav eine IP vergeben:
Zum Vergrößern anklicken....
Also doch: FB, Herausforderung Nummer 1...

berni51 schrieb:
Code: 
Dec 14 18:05:41 dnsmasq-dhcp[1616]: 3724631105 verfügbarer DHCP-Bereich: 192.168.0.230 - 192.168.0.235
Dec 14 18:05:44 dnsmasq-dhcp[1616]: 3724631105 DHCPDISCOVER(eth0) f0:de:f1:07:fb:46
Dec 14 18:05:44 dnsmasq-dhcp[1616]: 3724631105 Marken: eth0
Dec 14 18:05:44 dnsmasq-dhcp[1616]: 3724631105 DHCPOFFER(eth0) 192.168.0.233 f0:de:f1:07:fb:46
...
Zum Vergrößern anklicken....
Nach dem OFFER müsste ein REQUEST vom Client und ein ACKNOWLEDGE vom Server kommen, ansonsten hatte der Server dem Client die IP nicht korrekt gegeben (bzw dieser diese schon nicht requested). Danach sollte eine PXE Meldung kommen, und es sollten die File-Transfer-Versuche im Log auftauchen, so wie im Beispiel sichtbar (aus [1]):

Code: 
Nov 5 23:48:15 node1 dnsmasq-dhcp[7036]: DHCPDISCOVER(eth0) 08:00:27:88:0b:f3
Nov 5 23:48:15 node1 dnsmasq-dhcp[7036]: DHCPOFFER(eth0) 10.0.2.217 08:00:27:88:0b:f3
Nov 5 23:48:15 node1 dnsmasq-dhcp[7036]: DHCPREQUEST(eth0) 10.0.2.217 08:00:27:88:0b:f3
Nov 5 23:48:15 node1 dnsmasq-dhcp[7036]: DHCPACK(eth0) 10.0.2.217 08:00:27:88:0b:f3
Nov 5 23:48:21 node1 dnsmasq-dhcp[7036]: PXE(eth0) 10.0.2.217 08:00:27:88:0b:f3 pxelinux.0
Nov 5 23:48:21 node1 dnsmasq-tftp[7036]: sent /var/lib/tftpboot/pxelinux.0 to 10.0.2.217
Nov 5 23:48:21 node1 dnsmasq-tftp[7036]: file /var/lib/tftpboot/pxelinux.cfg/01-08-00-27-88-0b-f3 not found
Nov 5 23:48:21 node1 dnsmasq-tftp[7036]: file /var/lib/tftpboot/pxelinux.cfg/0A0002D9 not found
Nov 5 23:48:21 node1 dnsmasq-tftp[7036]: file /var/lib/tftpboot/pxelinux.cfg/0A0002D not found
Nov 5 23:48:21 node1 dnsmasq-tftp[7036]: file /var/lib/tftpboot/pxelinux.cfg/0A0002 not found
Nov 5 23:48:21 node1 dnsmasq-tftp[7036]: file /var/lib/tftpboot/pxelinux.cfg/0A000 not found
Nov 5 23:48:21 node1 dnsmasq-tftp[7036]: file /var/lib/tftpboot/pxelinux.cfg/0A00 not found
Nov 5 23:48:21 node1 dnsmasq-tftp[7036]: file /var/lib/tftpboot/pxelinux.cfg/0A0 not found
Nov 5 23:48:21 node1 dnsmasq-tftp[7036]: file /var/lib/tftpboot/pxelinux.cfg/0A not found
Nov 5 23:48:21 node1 dnsmasq-tftp[7036]: file /var/lib/tftpboot/pxelinux.cfg/0 not found
Nov 5 23:48:21 node1 dnsmasq-tftp[7036]: sent /var/lib/tftpboot/pxelinux.cfg/default to 10.0.2.217
Nov 5 23:48:22 node1 dnsmasq-tftp[7036]: sent /var/lib/tftpboot/menu.c32 to 10.0.2.217
Nov 5 23:48:22 node1 dnsmasq-tftp[7036]: sent /var/lib/tftpboot/pxelinux.cfg/default to 10.0.2.217

Das ist aber trotzdem noch alles aus dem Bereich "wir booten eine Linux-Distri zur Installation" - d.h die Baustelle wird vermutlich nach dem hier noch nicht zu Ende sein, denn du wolltest ja ein lauffähiges Linux welches dem Client rübergeschoben wird und dann ohne lokale Disk läuft.
Sowas war mal bei einem früheren AG von mir angedacht, für Cluster-Betrieb, wurde dann aber nie umgesetzt - stattdessen bekamen die einzelnen Nodes doch wieder lokale Disks (vorrangig wg. lokaler temporärer "scratch" Dateien während ne Calculation läuft, das wäre übers Netz auf nen Filer zu lahm gewesen), booteten zur initialen Install jedoch über PXE und installierten sich per Skript quasi erstmalig nach Lieferung (bzw nach nem Festplattentausch im Fehlerfall) automatisch und waren ab da dann bereit für Cluster-Betrieb, deswegen ist das für mich mit nem lauffähigen Linux übers Netz dann jetzt auch #Neuland :D ... bzw wüsste ich jetzt ausm Stegreif auch nicht, wie mans mit nem BSD machen würde.


[1] How to configure PXE boot server in Linux // when using DNSMASQ
 
Wo liegt denn DER große Unterschied, ein Installationsscript aufzurufen zum Aufruf einer Shell? Gestern hab ich einmal mal anstelle von initram einfach bash aufgerufen, und damit bekomme ich immerhin eine arbeitsfähige Shell. Nicht viel, aber ein kleiner Fortschritt.
Mehr und mehr glaube ich aber, dass ich ohne ein NFS die Sache nicht hinbekomme. Oder vielleicht doch mit ipxe, das hab ich ja auch noch in der Pipeline.
 
Klar, so ein Skript für ne Installation wird ja auch in ner Shell ausgeführt - zu dem Zeitpunkt reichts aber, wenn nur ne rudimentäre Umgebung für diese Shell da ist; das ist ja genau was die ganzen netimages sind: ne rudimentäre Umgebung, gerade ausreichend, um die Installation durchzukriegen;

Deine angedachte Installation bräuchte ja anstatt so ner minimalumgebung ein bootfähiges "fertig installiertes" Image von irgendwoher, welches per PXE bootet und die installierte Variante des OS komplett in den Speicher nachlädt (gehe ich richtig davon aus, dass du lokal keine Platte bzw keine Installation liegen haben möchtest) - wie das auch immer nachgeladen wird, ob per nfs oder iscsi usw.

Wenn man das weiter denkt, dann hängt da noch mehr dran: wenn du mehrere (verschiedene?) Maschinen mit so einem Image bedienen möchtest, dann müsste das auch bei jedem Boot einer solchen Maschine automatisch "individualisiert" werden, d.h. gewisse Dateien in /etc können nicht einfach stur nachgeladen werden, sondern müssten auf die jeweilige Maschine angepasst werden - z.B. hostname und alles was mit network/ifconfig zusammenhängt usw.

EDIT: Von Ubuntu z.B. gabs mal das DisklessUbuntuHowTo - schon etwas älter, aber ggf kannst dir da noch weitere Anregungen rausziehen?
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben