PXE Boot startet bei ActionRequest „setup“ nicht automatisch Netboot (opsi 4.3)

[basdi]

Hallo zusammen,

ich stoße bei opsi 4.3 auf ein Verhalten, das ich aus 4.1/4.2 so nicht kenne und wollte fragen, ob das so gewollt ist oder ob ich etwas übersehe.

Situation:
- Client ist korrekt angelegt
- Netboot-Produkt (Windows 11) ist sauber gebaut und funktioniert
- Client steht auf ActionRequest = setup
- PXE Boot ist im BIOS/UEFI aktiv

Ablauf beim Booten:
1. Client startet per PXE
2. opsi PXE/GRUB Menü erscheint
3. Nach Timeout bootet der Client von der lokalen Festplatte
4. Nur wenn ich im Menü manuell „Netboot“ auswähle, startet die Windows-Installation unattended wie erwartet


Erwartetes Verhalten (wie in 4.1/4.2):
Wenn ein Client auf setup steht, sollte er beim PXE-Boot automatisch in das Netboot-Produkt springen, ohne dass man im Menü etwas auswählen muss.

Ist das in 4.3 nicht mehr vorgesehen?
Oder gibt es eine Einstellung (opsipxeconfd / GRUB / Host-Parameter), mit der man das alte Verhalten wiederherstellen kann, sodass:

Code: Alles auswählen

PXE → direkt Netboot, wenn setup gesetzt ist

Aktuell scheint das Menü immer Vorrang zu haben und der Default-Eintrag ist „localboot“.

Hat jemand das gleiche Verhalten beobachtet und eine Lösung dafür?

Danke euch!

[j.schneider]

Hallo,

nein, das ist so nicht beabsichtigt.
Gibt es vielleicht Fehlermeldungen in der opsipxeconfd.log?

Grüße
Jan Schneider

[JakobCGN]

WICHTIG: Alle Angaben ohne Gewähr. Übernehme keine Haftung! Testen mit Vorsicht und nur im Testsystem.

als wir damals auf 4.3 umgestiegen sind, mussten wir unseren externen DHCP Server anpassen:
aktuelle config: https://docs.opsi.org/opsi-docs-de/4.3/ ... hcp-server
Info: https://docs.opsi.org/opsi-docs-de/4.3/ ... hcp_server

wenn du einen Client auf setup setzt (z.B. das netboot Paket hwinvent): wird bei dir auf dem depot eine client-spezifische GRUB-Konfigurationsdatei (alias "PXE Startdatei") angelegt?

Bei uns werden sie im Pfad

Code: Alles auswählen

/tftpboot/opsi/cfg/

durch das setup setzen im configed erstellt:

PXE_Startdatei.png (32.7 KiB) 794 mal betrachtet

Wenn sich eines unserer Systeme mal aufhängt, schadet es nicht, komplett alle drei opsi Dienste bei uns neu zu starten (auch auf dem configserver), ABER bzgl. configserver Neustarts im Produktivsystem aufpassen - besser nur zu Wartungszeiten:

Code: Alles auswählen

sudo systemctl restart opsiconfd.service opsi-tftpd-hpa.service opsipxeconfd.service

den opsipxeconfd loglevel /etc/opsi/opsipxeconfd.conf während der Tests auf z.B. 6 zu erhöhen, kann auch helfen. Danach muss noch opsipxeconfd.service neu gestartet werden.

Die opsi Windows (hwinvent, win11-x64, ...) und opsi Linux Pakete (opsi-linux-bootimage, opsipxeconfd, ....) sollten aktuell sein - ggfls. vorher prüfen:
https://opsipackages.43.opsi.org/stable/windows/
https://download.opensuse.org/repositor ... 3:/stable/

Veraltete DHCP Rule(s), opsi Linux/Windows Pakete und Problem im System mit der Erstellung der PXE Startdateien sind bei uns die ersten Punkte auf der Checkliste. Anbei noch ein Link (auch für erfahrene opsi Admins als Nachschlagewerk bestimmt ganz gut):

Ablauf der netboot Installation: https://docs.opsi.org/opsi-docs-de/4.3/ ... ed-netboot
Repo prüfen (andere Pfade 4.2 vs 4.3): https://docs.opsi.org/opsi-docs-de/4.3/ ... _eintragen
Pakete aktualisieren: https://docs.opsi.org/opsi-docs-de/4.3/ ... ualisieren

[basdi]

Hallo zusammen,
zuerst mal danke für die Rückmeldungen!

@j.schneider
Ich habe das Netboot-Paket win11 auf setup gesetzt und parallel die Log-Datei opsipxeconfd.log mit tail ausgelesen.

Code: Alles auswählen

[5] [2026-02-04 10:34:05.798] [               ] PXE boot configuration for host 'opsi-pve.schule.local' is now set at /tftpboot/opsi/cfg/db-d6-15-b2-24-11.cfg   (opsipxeconfd.py:459)

Leider ist der Client opsi-pve nach dem Neustart - wie zuvor – nach dem Timeout im PXE-Boot-Menü
(Continue, Netboot, UEFI Settings) wieder in das bereits manuell per Netboot installierte Windows gestartet.

---

@JakobCGN
Ich habe zuvor überwiegend mit opsi 4.2 gearbeitet, weshalb ich bei einigen Änderungen in opsi 4.3 etwas ins Stolpern gerate.
Bei meiner neuen Tätigkeit wollte ich die bisherige Client-Management-Lösung durch opsi 4.3 ersetzen, musste jedoch feststellen, dass man trotz der ausführlichen Dokumentation an manchen Stellen unfreiwillig hängen bleibt.

Die Startoptionen auf meinem DHCP-Server (OPNsense) habe ich bereits gesetzt. Das opsi-PXE-Bootmenü wird auch korrekt geladen.
Unter dem Pfad

Code: Alles auswählen

/tftpboot/opsi/cfg/

wird zudem die entsprechende .cfg-Datei angelegt, sobald das Paket auf setup gesetzt wird.

Wie bereits beschrieben, kann ich die Netboot-Pakete manuell über das PXE-Bootmenü installieren. Wenn ich den Client jedoch normal starten lasse, beginnt die Netboot-Installation nicht automatisch.

Die <MAC>.cfg verbleibt entsprechend im Verzeichnis und wird erst gelöscht, wenn ich den setup-Status des Pakets wieder entferne.


---
Hier noch der ganze Log von opsipxeconfd:

Code: Alles auswählen

[5] [2026-02-04 09:40:30.260] [opsipxeconfd start] Running opsipxeconfd setup   (setup.py:89)
[5] [2026-02-04 09:40:30.260] [opsipxeconfd start] Setting up limits   (setup.py:50)
[5] [2026-02-04 09:40:30.267] [opsipxeconfd start] Setting up GRUB configuration   (setup.py:73)
[5] [2026-02-04 09:40:31.202] [opsipxeconfd start] Connecting to OPSI Service at 'https://localhost:4447' (attempt 1)   (service.py:151)
[5] [2026-02-04 09:40:32.255] [opsipxeconfd start] Connecting to OPSI messagebus   (opsiservice.py:2170)
[5] [2026-02-04 09:40:32.266] [opsipxeconfd start] Connected to OPSI messagebus (id='130708757053520')   (opsiservice.py:1940)
[5] [2026-02-04 09:40:32.352] [opsipxeconfd start] Setup finished   (setup.py:97)
[1] [2026-02-04 09:40:32.352] [opsipxeconfd start] OPSI PXE Configuration Service version 4.3.15.2 starting   (opsipxeconfd.py:52)
[5] [2026-02-04 09:40:32.352] [opsipxeconfd   ] Starting opsipxeconfd main thread   (opsipxeconfd.py:228)
[5] [2026-02-04 09:40:32.353] [               ] Start setting initial boot configurations   (util.py:129)
[5] [2026-02-04 09:40:32.353] [opsipxeconfd   ] Creating unix socket /var/run/opsipxeconfd/opsipxeconfd.socket   (opsipxeconfd.py:148)
[5] [2026-02-04 09:40:32.369] [               ] Finished setting initial boot configurations   (util.py:161)
[5] [2026-02-04 09:40:55.679] [               ] PXE boot configuration for host 'opsi-pve.schule.local' is now set at /tftpboot/opsi/cfg/db-d6-15-b2-24-11.cfg   (opsipxeconfd.py:459)

[ewimar]

Hallo!

@basdi: Triviale Frage: Passt die MAC im opsi-configed auch zur MAC des Clients?

Dazu befragt man am besten den Client selbst:
Boote den Rechner per PXE und warte auf das GRUB-Menü.
Drücke 'C' für die Kommandozeile.
Gib den Befehl "pager=1" ein. (Tipp: "=" ist die Taste "´" rechts neben "ß")

Code: Alles auswählen

pager=1

Gib den Befehl "set" ein.

Code: Alles auswählen

set

Dir werden nun alle Variablen angezeigt.
Mit Eingabetaste geht es zeilenweise weiter, mit Leertaste eine Seite weiter.

Prüfe, ob die Variablen net_default_mac bzw. net_pxe_mac tatsächlich mit der MAC im opsi-configed übereinstimmen.

Code: Alles auswählen

net_default_mac='db:d6:15:b2:24:11'
...
net_pxe_mac='db:d6:15:b2:24:11'

Die Erfahrung zeigt, dass Dockingstation oder USB-Netzwerkadapter manchmal Probleme bereiten.

Grüße
Martin

[basdi]

@ewimar

Danke, jetzt funktioniert das automatische Betanken endlich
Am Ende lag es gar nicht an der MAC‑Adresse, sondern am falsch eingestellten TFTP‑Server.

Ohne deinen Hinweis auf den Befehl wäre ich da allerdings nie drauf gekommen.
In der OPNsense standen zwei Einträge... einer davon zeigte auf die falsche IP‑Adresse .