Syslinux 6.04 PXE Lightweight IP HTTP/FTP Support einrichten

Anmerkung:
Dies ist eine weiterführende Anleitung zu meinem Grundgerüst, basierend auf dem nachfolgenden Artikel:

https://www.german-syslinux-blog.de/synology-dsm-6-0-syslinux-6-04-pxetftpdhcp-server-einrichten/

Schritt: HTTP / FTP Downloads in der PXE Umgebung ermöglichen:

Melden Sie sich zuallererst auf Ihrer DS an und navigieren Sie anschließend ins Paketzentrum. Dort angekommen installieren Sie die Web Station, denn diese ist zwingend Voraussetzung für unser Vorhaben. In Firmenumgebungen gibt es eventuell bereits einen Web Server! In meinem Beispiel beziehe ich mich allerdings nur auf die Einrichtung unter Verwendung der DS.

Es gäbe auch die Möglichkeit einen externen Webserver als Downloadquelle zu nutzen. Die Geschwindigkeit wäre allerdings dann durch Ihren Internetanschluss begrenzt. Bei einer 100 Mbit Leitung wären das dann ca. ~12,5 MB/s (Theoretisch). Das wäre also deutlich langsamer als das über einen Internen Web Server abzuwickeln der im eigenen Intranet steht und mit 1Gbit angebunden ist! Und wer hat schon eine 100 Mbit Leitung beim ISP? 🙂

Wenn Sie die Webstation installiert haben stellen Sie diese bitte wie auf den Bildern zu sehen ist ein:

Welche PHP Version sie auswählen ist egal, da wir PHP ja nicht benutzen wollen, sondern lediglich einen Webserver mit Downloadmöglichkeit wollen.

Im Unterpunkt “Virtueller Host” klicken sie auf “Erstellen”.

Wählen Sie dort portbasiert aus und aktivieren sie daneben die HTTP Checkbox. HTTPS Verbindungen unterstützt Syslinux nicht! Diesen brauchen wir nicht. Vergeben Sie nun einen Port für Ihren Web Server. Im Standardfall ist Port 80 immer der normale HTTP Port. In unserem Fall ist es jedoch ratsam einen speziellen Port auszuwählen. Tragen Sie dort einfach 7777 oder einen Port Ihrer Wahl ein. Bedenken Sie dabei, dass sie keine Ports verwenden dürfen, die durch andere Dienste in Ihrer Umgebung bereits genutzt werden. Der Dokument Root sollte der TFTP Root sein. Wie der bei Ihnen lautet müssen Sie selbst wissen.

Ich mache Ihnen trotzdem mal ein Beispiel (So könnten Sie Ihr TFTP Root in der DS genannt haben):

/PXEServer/TFTP/
/TFTPRoot/

In unserer Anleitung zum Einrichten des TFTP&PXE Servers hatten wir eine gewisse Verzeichnisstruktur angelegt. Suchen Sie einfach die Datei “pxelinux.0“. Alle Ordner die sie dafür wechseln mussten sind der Pfad Ihres TFTP Root’s.

Beispiel:

/PXEServer/TFTP/pxelinux.0 => TFTP Root => /PXEServer/TFTP/

Als nächstes wählen Sie noch bei HTTP-Backend “Nginx” aus. Bei “PHP” das Standard Profil.

Somit ist der Webserver auch soweit eingerichtet.

Schritt: pxelinux.cfg/Konfigdateien editieren

Öffnen Sie die Datei: “pxelinux.cfg/default_BIOS” in einem Editor. Ich mache Ihnen ein Beispiel wie sie bereits vorhandene Einträge abändern könnten.

So sieht ein Eintrag bei mir in dieser Datei aus:

 LABEL WinPE50X32ISO
MENU LABEL 1. WinPE 10.0 Build 1709 x32 Bit - MemDisk ISO
MENU INDENT 2
COM32 linux.c32 memdisk
APPEND iso raw
INITRD images/Winpe/WinPE10.0/WinPE_x86.iso
TEXT HELP
Es wird die Windows Vorinstallations Umgebung 10.0 im
32 Bit Modus geladen mit allen Netzwerktreibern.

Die WinPE Versionen sind abwaertskompatibel. Es ist Ihnen moeglich
mit der WinPE 10.0 Version auch aeltere Windows Versionen zu installieren.

Es wird automatisch das Netzwerkshare zu den Windows Images aufgebaut.
ENDTEXT

Sie sehen hier einen Eintrag um die 32 BIT WinPE 10 Version über Memdisk zu laden.Sie müssen nichts anderes machen, als vor dem Pfad der ISO Datei noch ein http://DS_IP_ADRESSE:PORT/ (Beispiel: http://192.168.1.5:7777/ ) davor zu stellen.

Nach dem Bearbeiten sollte der Eintrag so aussehen:

 LABEL WinPE50X32ISO
MENU LABEL 1. WinPE 10.0 Build 1709 x32 Bit - MemDisk ISO
MENU INDENT 2
COM32 linux.c32 memdisk
APPEND iso raw
INITRD http://192.168.1.5:7777/images/Winpe/WinPE10.0/WinPE_x86.iso
TEXT HELP
Es wird die Windows Vorinstallations Umgebung 10.0 im
32 Bit Modus geladen mit allen Netzwerktreibern.

Die WinPE Versionen sind abwaertskompatibel. Es ist Ihnen moeglich
mit der WinPE 10.0 Version auch aeltere Windows Versionen zu installieren.

Es wird automatisch das Netzwerkshare zu den Windows Images aufgebaut.
ENDTEXT

Schritt: Das Booten über lpxelinux.0 einrichten:

Aus unserer vorherigen Anleitung booten wir die pxelinux.0 Datei im Legacy Modus. Da diese Datei den HTTP / FTP Modus nicht unterstützt werden wir noch ein wenig verändern müssen.

Laden Sie sich deswegen nochmal die aktuellste Syslinux Version herunter.

https://www.kernel.org/pub/linux/utils/boot/syslinux/Testing/6.04/syslinux-6.04-pre1.zip

Nach dem Entpacken kopieren Sie die Datei Syslinux 6.04\bios\core\lpxelinux.0 in das TFTP Root Verzeichnis Ihrer DS. Die Datei muss im selben Ordner liegen wie die Datei “pxelinux.0“!

Schritt: DHCP via SSH editieren

Melden Sie sich mit Putty über SSH auf Ihrer Synology an. Der Benutzername ist admin und nicht root liebe Leute 😉 Ich wollte es nur gesagt haben. Wenn Ihr eingeloggt seid, dann tippt folgendes ein:

cd /etc/dhcpd/
sudo vi dhcpd-pxe.conf

Sie werden nun erneut nach dem Passwort gefragt! Nach dem eingeben erscheint der Inhalt der Datei!

Die Datei kann verschieden aussehen, je nachdem welche Anleitungen Sie bereits durchgegangen sind. In dieser Datei ist immer pxelinux.0 durch lpxelinux.0 zu ersetzen! Insgesamt kommt pxelinux.0 zweimal in der ganzen Datei vor!

Kopieren Sie bitte nicht mein Beispiel, sondern ändern die das bitte von Hand!

dhcp-boot=tag:pxe,pxelinux.0
dhcp-vendorclass=set:pxe,PXEClient

#Beispiel Eintrag und Erklärung
#Tag vergeben, DHCP-Option 60, Suche String (Match)
#dhcp-match=set:bios,60,PXEClient:Arch:00000
#Boot-Tag, Boot-Dateiname, Server Name (DNS), Server IP Addresse
#dhcp-boot=tag:bios,pxelinux.0,192.168.1.5,192.168.1.5
#Boot-Tag, DHCP-Option 209, Pfad zur Syslinux-Konfigurationsdatei
#dhcp-option-force=tag:bios,209,pxelinux.cfg/default_BIOS

dhcp-match=set:bios,60,PXEClient:Arch:00000
dhcp-boot=tag:bios,pxelinux.0,192.168.1.5,192.168.1.5
dhcp-option-force=tag:bios,209,pxelinux.cfg/default_BIOS

dhcp-match=set:efi32-1,60,PXEClient:Arch:00002
dhcp-boot=tag:efi32-1,pxelinuxEFI32.efi,192.168.1.5,192.168.1.5
dhcp-option-force=tag:efi32-1,209,pxelinux.cfg/default_EFI32

dhcp-match=set:efi32-2,60,PXEClient:Arch:00006
dhcp-boot=tag:efi32-2,pxelinuxEFI32.efi,192.168.1.5,192.168.1.5
dhcp-option-force=tag:efi32-2,209,pxelinux.cfg/default_EFI32

#Standard für UEFI Rechner
#Die meisten UEFI Rechner benutzen diesen Eintrag. Je nach Hersteller kann es 
#jedoch sein, das statt 00007 mal 00009 verwendet wird. 
dhcp-match=set:efi64-1,60,PXEClient:Arch:00007
dhcp-boot=tag:efi64-1,pxelinuxEFI64.efi,192.168.1.5,192.168.1.5
dhcp-option-force=tag:efi64-1,209,pxelinux.cfg/default_EFI64

dhcp-match=set:efi64-2,60,PXEClient:Arch:00008
dhcp-boot=tag:efi64-2,pxelinuxEFI64.efi,192.168.1.5,192.168.1.5
dhcp-option-force=tag:efi64-2,209,pxelinux.cfg/default_EFI64

dhcp-match=set:efi64-3,60,PXEClient:Arch:00009
dhcp-boot=tag:efi64-3,pxelinuxEFI64.efi,192.168.1.5,192.168.1.5
dhcp-option-force=tag:efi64-3,209,pxelinux.cfg/default_EFI64

Wenn Sie die EINFÜGEN Taste einmal drücken können Sie die Einträge verändern. Wenn Sie damit fertig sind drücken Sie einmal die ESC Taste.

Danach schreiben Sie folgendes:

:w und mit ENTER bestätigen. Die Meldung erscheint, das der Inhalt gespeichert wurde!
:q und mit ENTER bestätigen. Sie verlassen den Editor!

Der letzte Schritt: DHCP Server neu starten:

Damit unsere Änderungen auch angenommen werden, muss der DHCP Server einmal neu gestartet werden. Gehen Sie dafür im DSM auf Systemsteuerung und dann DHCP-Server und klicken dort einmal auf DHCP deaktivieren und im Anschluss nochmals auf aktivieren.

Schritt: Der Test:

Starten Sie den Rechner über PXE im Legacy Modus und überprüfen Sie, ob der Eintrag ordnungsgemäß funktioniert! Die Geschwindigkeit sollte deutlich besser sein, als TFTP Transfers. Ich habe selber mal geprüft wie viel schneller das nun vonstatten geht und in meinem Fall ist es der Faktor X4-X15. Im TFTP Protokoll werden die Daten mit ca. ~5 MB/s übertragen ohne TFTPBlockSize Angaben! Mit optimierten Werten komme ich auf ca. 25-30MB/s. Das sind ganz ordentliche Werte, aber trotzdem noch kein Vergleich zu den HTTP Downloads.

Über HTTP mit ca. ~20-100MB/s im eigenen Intranet (Natürlich ist das abhängig von der aktuellen Netzwerklast/Auslastung der Synology). Ich habe hier privat überall 1Gbit verlegt. Theoretisch wären 125MB/s möglich. Real ca 115MB/s.

Testen Sie es einfach selbst wie schnell es nun geht. Es ist jedenfalls eine deutlich spürbare Verbesserung.

Zum Anfang!

17 Antworten auf „Syslinux 6.04 PXE Lightweight IP HTTP/FTP Support einrichten“

  1. Hallo Stefan,
    in der default_BIOS werden ja nur die Pfade der iso-Dateien der MemDisk-Einträge mit “http://192.168.1.5:7777/” editiert….

    Wie verhält es sich mit den mit den Bootmanager-Einträgen (wim-Dateien)….müssen hier keine Pfade für den schneller HTTP-Modus angepasst werden? kann/soll man auch die default_EFI32 und default_EFI64 anpassen…hier gibt es ja nur Bootmanager-Einträge….

    1. Ich kenne mich leider selbst nicht so gut mit der BCD Struktur aus. Ich hatte da zwar auch mal versucht einfach eine HTTP Adresse zu benutzen, aber das schlug fehl. Auch meine Suchbemühungen im Internet fanden nichts.

      Ich habe aber noch eine Idee.

      Kannst du mal bitte im UEFI Modus immer das WinPE x64 Image laden und die Zeit stoppen bis der Ladebalken verschwunden ist?

      Eventuell kann man die Zeit ein wenig tunen. Ich habe das gerade selber bei mir ausprobiert. Bitte folgendes der CreateCustomBCD_WinPE_BIOS_AND_UEFI_X86_X64.cmd nach der Zeile:

      bcdedit -store C:\BCD -set {ramdiskoptions} ramdisksdipath \Boot\boot.sdi

      hinzufügen:

      bcdedit -store C:\BCD -set {ramdiskoptions} ramdisktftpblocksize 4096
      bcdedit -store C:\BCD -set {ramdiskoptions} ramdisktftpwindowsize 16
      bcdedit -store C:\BCD -set {ramdiskoptions} ramdisktftpvarwindow Yes 

      Dann lässt du die BCD-Datei erstellen, überschreibst die Alte im Boot\ Verzeichnis auf dem TFTP Server und nimmst erneut die Zeit. Dann änderst du beim zweiten Durchlauf die 4096 in 8192, speichern, BCD-Datei erstellen lassen, wieder überschreiben und erneut die Zeit messen.

      Beim letzten Durchlauf den Wert auf 16384 setzen und das ganze nochmal.

      Meine Benchmarkergebnisse:

      Datei: WinPE_x64.wim = 296MB

      Standard = 1 Minute 27,41 Sekunden = 3,3MB/s

      Wert 4096 = 32,4 Sekunden = 9,13MB/s
      Wert 8192 = 24,02 Sekunden = 12,32MB/s
      Wert 16384 = 21,05 Sekunden = 14,06MB/s

      Es lohnt sich also dies zu ändern. Probier es aus. Die Werte schwanken zwar prinzipiell ein wenig, aber dennoch sind diese im Schnitt deutlich besser als mit Standardeinstellungen. Das kommt zwar nicht an die Geschwindigkeit des HTTP Servers ran, aber trotzdem ist das zufriedenstellend.

      Das Editieren der default_EFI32 und default_EFI64 Dateien kannst du Dir prinzipiell ab jetzt sparen. Du nutzt ja im UEFI Modus den Windows-Boot-Manager, also werden die gar nicht beachtet. Ich habe zwar noch die Hoffnung, dass in einer neueren Syslinux Version dann auch endlich mal irgendwann der UEFI Boot-Manager startbar ist, aber bis dahin müssen wir das halt solange ignorieren.

      1. Hallo Stefan,
        ich frage deswegen, weil die WIM-Dateien im Bootmanager bei mir extrem langsam laden.

        Habe folgendes Fehlverhalten im BIOS-Legacy Modus:

        Wenn ich in der Backup Section den obersten Acronis True Image Eintrag (memdisk – langsam) auswähle „flutscht“ innerhalb von 5 Sekunden die Oberfläche der Acronis-Rescue-Oberfläche auf den Bildschirm !!! Alles Wunderbar !!!

        Wenn ich die darunterliegenden Einträge (kernel Load – schnell ) auswähle tut sich gar nix –> schwarzer Bildschirm – ganz links oben blinkt der Cursor!

        Wenn ich in der Windows Section die memdisk-Einträge auswähle –> alles bestens Start.cmd öffnet sich nach einigen Sekunden …alles gut !!!

        Wenn ich jedoch den BootMgr auswähle …lädt dieser…wenn ich dann aber eine WIM auswähle (z.B. WinPE win 10 x64 oder Acronis_x86x64) dann dauert es schon mal 1 Minute bis der Fortschrittsbalken der Boot.sdi rüberläuft…..bei dem Fortschrittsbalken der der eigentlich wim.-Datei tut sich erst mal gar nichts ….nach 10 Min sieht man erst den ersten Abschnitt des Fortschriritts ganz links ….dauert also ewig…

        Ich hab jetzt deine Idee vom letzten Post noch nicht ausprobiert…mache ich später noch 🙂

        1. Ja, das weiß ich noch, denn das sagtest du schon einmal.

          Hast du das Problem denn auch, wenn du den PC direkt mit dem NAS verbindest ohne irgendwelche Zwischengeräte wie Switches/Hubs/Router zu verwenden? Ich kenne deine Netzwerkstruktur nicht, aber das wäre das Erste was ich testen würde.

          Da das Problem ja scheinbar alle Clients in deinem Netz haben muss das entweder an dem TFTP Server selbst liegen oder an Bandbreitenbeschränkungen, die beim NAS eingestellt worden sind oder eventuell an einem Gerät in deinem Netzwerk, wo alle dran angeschlossen sind.

          Probiere erst einmal die Anpassung aus, danach sehen wir weiter. 🙂

  2. Es gibt tatsächlich einen zentralen Netzwerk-Switch über welchen unser Netzwerk aufgeteilt wird (da hängen fast alle Geräte dran):

    ABER: Da am gleichen PC der MemDisk Boot innerhalb von wenigen Sekunden flutscht, der Bootmanager-Boot jedoch unendlich langsam abläuft würde ich jetzt mal nicht mehr mein Netzwerk oder irgendwelche Switches verantwortlich machen !!!

    Wenn ich im UEFI Modus das WinPE x64 Image lade ….dann kommt zunächst ein Fortschrittsbalken für die Datei “Boot.sdi”…das dauert ca 1 Min. Danach folgt der leere Fortschrittsbalken für die WinPE x64.wim….der bleibt erst mal ca. gefühlte 10 Minuten leer…dann kommt links das erste weisse Stück….wenn man das hochrechnet, dann dauert es sicher 1,5 Stunden…

    Ich kann das morgen gerne mal testen …. frage mich aber ob das Tuning wirklich der richtige Lösungsansatz ist. Bei dir lädt die WinPE standardmäßig in einer Minute und 27 Sek (mit oder ohne HTTP?)…beim mir 1,5 Stunden…

    1. 1 Minute 27 Sekunden sind die Standardwerte bei mir beim TFTP Transfer OHNE jegliche Änderungen. Mit den Änderungen brauchen ich für 300MB über TFTP 15-20 Sekunden (BIOS oder UEFI ist egal, UEFI scheint aber immer ein bisschen langsamer zu sein). Schwankt immer ein bisschen. Über HTTP geht das deutlich schneller. Da sind es vielleicht 5 Sekunden.

      Ich würde das Switch nicht ausschließen. Bei Managed-Switches kann man einiges einstellen. Traffic priorisieren, Bandbreitenbeschränkungen für einzelne Dienste etc. Eine vorhandene Firewall kann jedenfalls als Grund ausgeschlossen werden, denn dann würdest du gar keine Verbindung hergestellt bekommen.

      Daher schließe einfach einen Rechner direkt an die Kiste an. Du musst ja schon schauen, das du den Fehlerkreis eingrenzen kannst. Wenn du aber nichts änderst, fischst du die ganze Zeit im Trüben. Du kannst ja auch erst wirklich ausschließen, das nichts anderes bei Euch im Netzwerk schuld ist, wenn bei einer Direktverbindung immer noch die Probleme bestehen. Dann weißt du jedenfalls das der Fehler irgendwas mit der Synology zu tun haben muss und kein anderes Gerät im Netz schuld ist über diesen der Netzwerkverkehr geleitet wird.

      Die Aussage das Memdisk ja funktioniert und TFTP ja nicht, hat nicht sonderlich viel zu bedeuten. Du lädst die Dateien ja nicht über TFTP, sondern über den Webserver. Das ist nicht der gleiche Datenverkehr. Das sind zwei völlig unterschiedliche Protokolle. Und wenn da jetzt irgendwie ein Gerät zwischen hängt, das TFTP Datenverkehr drosselt, ja dann hast du dein beschriebenes Problem.

      Bei der Synology könntest du auch selbst mal schauen, ob du irgendwelche Einträge unter Netzwerk => Datenfluss-Steuerung eingetragen hast.

      Ansonsten könnte man noch den Traffic mit Wireshark analysieren. Das ist aber eher etwas für Leute, die Ahnung davon haben. Habt Ihr keinen IT-Systemadmin bei Euch oder machst du das alles selbst? 😀

  3. Ich bin der Systemadmin (also ich mache alles selbst!) 🙂

    Also Memdisk wird über Webserver geladen – und der Bootmanager über TFTP ? Das war ja meine ursprüngliche Frage…ich dachte beides wird über Webserver geladen sobald man HTTP einrichtet.

    Das heißt wenn ich ausschliesslich UEFI-Rechner im Netzwerk hätte dann würde mir das Einrichten von HTTP gar keinen Geschwindigkeitsvorteil bringen !?

    Du meinst also den neuen UEFI-Rechner mit LAN-Kabel direkt an die Diskstation anschliessen ….und dan PXE-Boot versuchen….ist zwar etwas aufwendig….aber vielleicht kann ich dann den Fehler tatsächlich eingrenzen

  4. Zitat
    “Also Memdisk wird über Webserver geladen – und der Bootmanager über TFTP ?”

    Nein, Memdisk und der Bootmgr wird über TFTP geladen. Das siehst du, wenn du dir mal die TFTP-Logs anguckst (/var/log/opentftp.log). Über HTTP wird auch nur geladen, wo du vor dem Pfad die HTTP Adresse schreibst. lpxelinux.0 bringt nur den HTTP Support mit. Das Dateien via HTTP geladen werden sollen musst du aber explizit in den Dateien konfigurieren. Also die HTTP Adresse davor setzen. Andernfalls läuft das über das TFTP-Protokoll.

    Zitat
    “Das heißt wenn ich ausschliesslich UEFI-Rechner im Netzwerk hätte dann würde mir das Einrichten von HTTP gar keinen Geschwindigkeitsvorteil bringen !?”

    ACK. Insofern es keine Möglichkeit in der BCD gibt so etwas anzugeben, nicht. Ich habe jedenfalls nichts dazu gefunden und auch die Microsoft Dokumentationen erwähnen diesbezüglich nichts. Es gibt nur den Support von Multicast-Verteilungen, was aber auch meines Wissens nach auch wieder über TFTP abläuft. Ich will mich hier aber auch nicht zu weit aus dem Fenster lehnen, denn vielleicht ist das doch möglich, nur ich habe es noch nicht entdeckt. Ich bin ja schließlich auch kein BCD-Profi 😀

    Du wirst also das Problem lösen müssen. Ich kenne auch ansonsten nur sehr wenige Möglichkeiten das alles so nachzubauen wie ich mit den Anleitungen bereits getan habe. Entweder man hat sowieso einen Windows Server irgendwo stehen mit der WDS Rolle oder man baut sich das Konstrukt halt selbst.

    Zitat
    “Du meinst also den neuen UEFI-Rechner mit LAN-Kabel direkt an die Diskstation anschliessen ….und dan PXE-Boot versuchen….ist zwar etwas aufwendig….aber vielleicht kann ich dann den Fehler tatsächlich eingrenzen”

    Wie gedenkst du denn sonst das Problem einzugrenzen, wenn nicht so? Du kannst das zwar machen wie du möchtest und du musst es auch nicht machen, wenn du nicht willst, aber irgendwo musst du ja anfangen. 🙂

    1. Problem ist eingegrenzt: Hab die DS direkt mit den PC verbunden….hier funktioniert alles einwandfrei !!! Du hattest somit recht …es muss an dem Lancom Switch liegen, an dem sämtliche Geräte hängen.

      Jetzt werde ich mich wohl mit dem Teil mal beschäftigen müssen (hier gibts zig Einstellungsmöglichkeiten) …denn hier wird wahrscheinlich der Datentransfer langsam ….

      Übrigens kurz eine Anmerkung:

      Du solltest in der Anleitung” Lightweight IP…” ergänzen, dass man auf der DS in der Systemsteuerung unter DHCP-Server den Bootloader auf “lpxelinux.0” umstellen muss. Ist zwar logisch …sollte aber erwähnt werden in der Anleitung.

      Danke für deine Hilfe !!

      1. Zitat
        “Du solltest in der Anleitung” Lightweight IP…” ergänzen, dass man auf der DS in der Systemsteuerung unter DHCP-Server den Bootloader auf “lpxelinux.0” umstellen muss. Ist zwar logisch …sollte aber erwähnt werden in der Anleitung. ”

        Ob du mir jetzt glaubst oder nicht, aber das ist pure Absicht! 😀 Denn, dadurch das wir im Nachhinein eh immer die dhcpd-pxe.conf bearbeiten, wird dem Eintrag keine Bedeutung mehr zugewiesen. Das war bei Dir damals nur notwendig, weil du das eben nicht nach meiner Anleitung eingerichtet hattest, sondern davon abgewichen warst. Da war das in der Tat erforderlich. Jetzt wäre das sowieso nur Makulatur, da der Eintrag schon lange nicht mehr beachtet wird.

        Freut mich, dass du deiner Problemlösung einen Schritt näher gekommen bist. Für mich hört sich das alles so an, als hättest du das System der Firma übernommen, es aber nicht eingerichtet, richtig? Gibt es bei Euch keine Dokumentationen wo alles vermerkt wurde? Sich in einer Firma zurecht zu finden ohne jegliche Informationen zu dem IST-Status zu haben, ist schon hart. Du wirst das schon hinkriegen 🙂

  5. Hallo erstmal
    @Stefan Danke für deine Arbeit.. hat mir ein großes Stück weitergeholfen auf meiner Syno ein Ultimatives BootSystem einzurichten..

    Allerdings hänge ich jetzt bei der HTTP Erweiterung..
    vorweg:
    meinen PC habe ich auf Bios Boot (MBR) eingestellt, wegen Bootmanager im MBR (2 Partitionen mit Win10)

    mein PXE Server funktioniert grundsätzlich.. nur nicht über HTTP

    meine config Zeilen lauten:

    LABEL WinPE50X32ISO
    MENU LABEL 2. WinPE 10.0 Build 1709 x32 Bit – per HTTP
    MENU INDENT 2
    COM32 linux.c32 memdisk
    APPEND iso raw
    INITRD http://192.168.2.20:7777/images/win10_pe/WinPE_10x86.iso
    TEXT HELP
    Es wird die Windows Vorinstallations Umgebung 10.0 im
    32 Bit Modus geladen mit allen Netzwerktreibern.

    Die WinPE Versionen sind abwaertskompatibel. Es ist Ihnen moeglich
    mit der WinPE 10.0 Version auch aeltere Windows Versionen zu installieren.

    Es wird automatisch das Netzwerkshare zu den Windows Images aufgebaut.
    ENDTEXT

    LABEL WinPE50X32ISO
    MENU LABEL 3. WinPE 10.0 Build 1709 x32 Bit – per ISO
    MENU INDENT 2
    COM32 linux.c32 memdisk
    APPEND iso raw
    INITRD images/win10_pe/WinPE_10x86.iso
    TEXT HELP
    Es wird die Windows Vorinstallations Umgebung 10.0 im
    32 Bit Modus geladen mit allen Netzwerktreibern.

    Die WinPE Versionen sind abwaertskompatibel. Es ist Ihnen moeglich
    mit der WinPE 10.0 Version auch aeltere Windows Versionen zu installieren.

    Es wird automatisch das Netzwerkshare zu den Windows Images aufgebaut.
    ENDTEXT

    Der Teil wo ich die ISO einfach nur mit initrd lade, funktionierts
    Im Teil über HTTP funktionierts nicht und erhalte die Fehlermeldung, daß man die ISO nicht finden könne..

    wenn ich die in der config-Zeile angegebene Adresse im Browser eingebe, werde ich gleich gefragt, was ich mit der ISO machen möchte, also downloadbar..

    kann mir jemand helfen, wo ich her den Fehler habe..
    Ich denke irgendwo einen Syntax oder Denkfehler..
    mein HTTP-Root (und TFTP-ROOT) ist auf das Verzeichnis pxe gelegt, wo die pxelinux.0 liegt..
    darunter gibt’s dann das /Images Verzeichnis und darunter dann z.B. das (/Images)/win10_pe Verzeichnis wo das ISO
    drin liegt…

    Danke für eure Hilfe

    1. Das hört sich alles danach an, dass der falsche Bootloader verwendet wird.

      Der pxelinux.0 (Syslinux-Bootloader ohne HTTP-Support) kann keine HTTP Adressen öffnen!
      Der lpxelinux.0 (Syslinux-Bootloader mit HTTP-Support) dagegen schon.

      Es scheint, als hättest du vergessen die dhcpd-pxe.conf zu bearbeiten und das pxelinux.0 durch lpxelinux.0 zu ersetzen.

  6. Ja, Danke für den Hinweis, den hatte ich mir auch schon mal angesehen..
    aber da wird im wesentlichen erklärt, wie man ein PE-Installations Umgebung erstellt.

    Bei mir ists aber so, dass ich eine boot.wim schon habe, die ich gerne aus dem Menü heraus starten würde..

    Menüeintrag sieht so aus
    LABEL boot.wim starten
    MENU LABEL 9. boot.wim starten
    MENU INDENT 2
    com32 linux.c32 wimboot
    INITRD bootmgr,bcd,boot.sdi,http://192.168.2.20:7777/images/Win10PE/boot.wim

    da wird mir aber ein Fehler ausgegeben, dass der die boot.wim nicht finden kann

    1. Ich habe nie mit Wimboot gearbeitet. Ich kann Ihnen da also auch nicht helfen. Funktioniert der Eintrag denn OHNE die HTTP Adresse? Sonst fragen sie mal beim Hersteller von Wimboot nach.

      Zitat
      “Ja, Danke für den Hinweis, den hatte ich mir auch schon mal angesehen..
      aber da wird im wesentlichen erklärt, wie man ein PE-Installations Umgebung erstellt.”

      Das stimmt schon, aber es ist dort ebenso erklärt wie man sich eine eigene BCD-Datei baut, dessen Einträge sie dann immer beliebig erweitern könnten. Dann brauchen sie auch kein Wimboot mehr.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.