openSuse Netboot DHCP Fehler seit OPSI 4.3 stable - August 2024

[GregorEDCE]

Hallo zusammen,

seit dem Update unseres Opsi Servers auf "Release 4.3 stable - August 2024" funktionieren die openSUSE Netboot Produkte nicht mehr. Folgender Fehler tritt bei dem Netboot Produkt "opensusel-15-6" auf.

Vor dem Starten der grafischen Installationsoberflaeche von SUSE erscheint die Meldung:

"Please make sure your installation medium is available".

Nach Auswahl der korrekten URL zum isocontent Ordner erscheint:

"DHCP Configuration failed".

Das identische Paket hat vor dem Update funktioniert. Aeltere openSUSE Pakete zeigen das gleiche Verhalten. Die Windows Netboot Pakete funktionieren einwandfrei.

Die manuelle Installation von SUSE mit einem USB Stick funktioniert auf dem Rechner auch ohne Probleme.

Ich habe vermutet, dass ein Zusammenhang mit dem shimx64 Fehler, welcher in den Release Notes beschrieben wird, besteht. Doch auch bei der Verwendung von opsi-netboot.efi ohne shimx64 erscheint der gleiche Fehler.

https://opsi.org/de/releases/#4.3-20240828051035

Ich freue mich über Hinweise. Vielleicht hat jemand ähnliche Probleme?

Dankeschön

Viele Grüße
Segler

[m.radtke]

Hi

der von dir erwähnte shimx64 Fehler betrifft nur bestimmte Dell Geräte. Da dein Client scheinbar auch bootet, ist er nicht betroffen.

Nun zum Problem:
Wie wird denn das Depot Netzwerkseitig aufgelöst, oder FQDN oder IP Adresse? Falls FQDN, dann stell mal die Depot Adresse in den Depot Einstellungen auf IP Adresse um. Manchmal sind die Treiber die in den Installern verwendet werden sehr speziell und fliegen mit einem Segfault weg wenn eine Namensauflösung pder FQDN gemacht werden muss.

Gruß
Mathias

[GregorEDCE]

HI Mathias,

vielen Dank für deine Antwort und die Klarstellung, dass shimx nicht das Problem ist.

Das Depot (clientconfig.depot.id) wird per FQDN aufgelöst. Ich werde es am Montag mit der IP-Adresse testen.

Eine Info fehlt in meinem Eingangspost:

Wir mussten für unsere opensuse Pakete bisher immer die "opensuse.py" wie folgt anpassen, da auch zuvor DHCP Probleme auftraten.

Code: Alles auswählen

Zeile 218: hardwareAddress = backend.getMacAddress(hostId = clientId)
Zeile 219: execute(f"{which('kexec')} --load {kernel_file}  --append='install=https://{fqdn}:{pckey}@{depotAddress}:4447/depot/{productId}/isocontent/ {append_line} ifcfg={hardwareAddress}=dhcp,rfc2132' --initrd={inird_file}")

Zeile 218 wurde hinzugefügt, um die MAC-Adresse des Clients abzurufen, Zeile 219 nur um den ifcfg-Teil erweitert. Ich kann leider nicht mehr nachvollziehen, welchen genauen Fehler wir damals ohne diese Änderungen bekamen. Seit openSUSE 15.4 hatte es funktioniert.

Ich habe die Installation von openSUSE 15.6 auch ohne diese Änderungen, mit dem originalen OPSI-Paket für opensusel15-6 getestet, ohne Erfolg.

Funktioniert die Änderung im Python Skript durch das OPSI-Update eventuell nicht mehr wie geplant?

Viele Grüße
Gregor

[GregorEDCE]

Hi

der von dir erwähnte shimx64 Fehler betrifft nur bestimmte Dell Geräte. Da dein Client scheinbar auch bootet, ist er nicht betroffen.

Nun zum Problem:
Wie wird denn das Depot Netzwerkseitig aufgelöst, oder FQDN oder IP Adresse? Falls FQDN, dann stell mal die Depot Adresse in den Depot Einstellungen auf IP Adresse um. Manchmal sind die Treiber die in den Installern verwendet werden sehr speziell und fliegen mit einem Segfault weg wenn eine Namensauflösung pder FQDN gemacht werden muss.

Gruß
Mathias

Ich habe in der Depot-Konfiguration bei "depotRemoteURL" und die "depotWebdavURL" den FQDN durch die IP-Adresse des Opsi-Servers ersetzt. Leider hat das nichts an dem DHCP Fehler geändert.

[m.radtke]

Hi

wir testen das Produkt in der Fassung in der wir es verteilen regemläßig und solch einen Fehlverhalten habe ich bisher nicht beobachtet.
Das Update des Servers hat meiner Meinung nach erstmal nichts mit dem Fehlverhalten zu tun, da sehe ich erstmal keinen Zusammenhang, da der Fehler ja im Installer selbst ist und sich erstmal auf die Netzwerkkonfiguration bezieht.

Wenn die Maschine im Fehler ist, wechsel bitte das TTY auf eine die einen Login ermöglicht. Unter /var/log/ gibt es sicherlich ein Yast2 log oder ähnlich, da kann man ansetzen um rauszufinden was genau da schief läuft.

Gruß
Mathias

[GregorEDCE]

Hallo,

wir sind immer noch dabei, das Problem zu lösen. Den aktuellen Stand möchte ich hier gern teilen, falls jemand ähnliche Probleme hat.

@m.radtke Danke für den Hinweis mit den Logs. Während der DHCP-Fehler auftritt kann man eine Shell im linuxrc öffnen. Die Logs zeigen, dass linuxrc keine IP-Adresse vom DHCP bekommt. Die Abfrage bricht mit einem Timeout ab. Auch das manuelle Neustarten des Netzwerkadapters mittels

Code: Alles auswählen

wicked ifup eth0

schlägt nach einem Timeout fehl.

Zieht man allerdings das Netzwerkkabel ab, steckt es wieder an und startet den Adapter dann manuell neu, funktioniert der Abruf der IP-Adresse. Steckt man das Kabel neu an, nachdem das opsi-linux-boot-image fertig durchgelaufen ist und bevor linuxrc versucht, die IP abzurufen, läuft die Installation wie gewünscht durch.

Die zuvor beschriebene Anpassung der opensuse.py ist notwendig, damit die Anfrage beim DHCP durch linuxrc mit der korrekten CLIENT ID (RFC2132) geschieht und kann hier als Problem ausgeschlossen werden. Der Hintergrund ist bei SUSE bekannt und hier dokumentiert:
https://documentation.suse.com/sles/15- ... cp-rfc4361

Warum der IP Abruf erst nach dem neuen Einstecken des Netzwerkkabels funktioniert, ist noch unklar.


VG Gregor

[GregorEDCE]

Hallo,

das Problem besteht leider immer noch. Ich habe in der Zwischenzeit die Installation des identischen und anderen opensuse-Netboot Produkten auf einem Opsi-Server, welcher noch auf der Version 4.2 läuft getestet. Dort funktionierte die Installation problemlos ohne DHCP-Fehler beim booten von linuxrc. Der verwendete DHCP-Server in diesem Netzwerk ist identisch zu unserem.

Ich würde gern testen, ob das opsi-linux-bootimage hier einen Einfluss hat. Leider konnte ich nicht herausfinden, wo ich alte Versionen des opsi-linux-bootimage herunterladen kann.

Ich habe bereits versucht, einfach den /tftpboot/-Ordner des 4.2-Opsi Servers mit unseren zu tauschen. Das funktioniert aber nicht.

Ich würde mich freuen, wenn mir jemand sagen könnte, wie ich ein älteres opsi-linux-bootimage auf unserem aktuellen opsi4.3-Server testen kann.

Vielen Dank

Viele Grüße

[m.radtke]

Hi

du kannst hier (https://download.opensuse.org/repositor ... 4-1.tar.gz) die Datei auspacken und dann miniroot-x64.zstd und vmlinuz-x64.signed nach /tftpboot/opsi/opsi-linux-bootimage miniroot-x64 bzw install-x64 kopieren.

Die 4.3 Dateien am Besten vorher sichern.

Dann hast du das alte Bootimage in Verwendung.

Gruß
Mathias

[GregorEDCE]

Hi Mathias,

vielen Dank für deine Antwort. Mit dem alten Bootimage funktioniert die Installation jetzt wieder. )

Jetzt bleibt die bei mir die Frage, warum das so ist. Das Bootimage aus deinem Link ist von Ende 2023. Der Fehler trat aber erst im September auf. Dort war ja schon einige Zeit das neue Bootimage im Einsatz.

Vg
Gregor

[GregorEDCE]

Hallo,

nachdem die Installation nun mit dem alten opsi-linux-bootimage funktioniert, ist eine neuer Fehler aufgetreten.

Zum einen kann die Installationsquelle im isocontent-Ordner erst nach einiger Wartezeit eingebunden werden. Zuvor wird der Fehler angezeigt: "Cant create Repository".

Den Fehler konnte ich beheben, indem als installpfad, welcher zum isocontent-Ordner zeigte, durch den Pfad zum openSUS online repo ersetzt habe:

"install=https://{fqdn}:{pckey}@{depotAddress}:4447/depot/{productId}/isocontent/"
ersetzt durch
"install=http://download.opensuse.org/distributi ... /repo/oss/"

Ein weiterer Fehler ist, dass die Parameter "language" und "console_keymap" und "timezone" anscheinend nicht mehr gepatched werden, da der openSUSE Installer meckert, dass er "#@language*#" usw. nicht kennt. In der opensuse.py sind die Parameter nicht beim Erstellen der PATCH_IN-Datei enthalten, daher gehe ich davon aus, dass dies innerhalb des bootimages passiert?

Ist das richtig? Kann man dort etwas ändern? Alternativ kann ich die Einträge für beide Parameter bei der Erstellung der PATCH_IN ergänzen.

Dankeschön

Vg Gregor