forum.opsi.org

Hallo zusammen,

wir haben diese Woche Updates in unseren Opsi Server eingespielt. Dabei kam auch das "neue" opsi-linux-bootimage in Version 20250924 mit.
Wir installieren bei uns hauptsächlich Windows, nun wollten wir uns aber auch einmal an die Installation von Linux Mint heranwagen. Auf dem Opsi-Server ist Version 4.3.0.2-3 des mint-22 Netboot-Pakets installiert.
Nun haben wir heute allerdings versucht Linux Mint 22 mit dem dafür vorgefertigten Paket zu installieren.
Das opsi-linux-bootimage startet normal, Client-Daten werden eingegeben, Netboot-Produkt wird ausgewählt - soweit, so gut. Kurz nach dem Start erscheint allerdings folgende Fehlermledung: Folgendes ist noch zu erwähnen: der FQDN des Opsi-Servers löst zu einer Adresse in einem /24-Subnetz auf. Wir haben allerdings noch weitere Netze, aus welchen eine Installation von Betriebssystemen mithilfe des opsi-linux-bootimage funktionieren soll. Der Client mit dem ich initial gestestet habe befindet sich in einem anderen Subnetz als der Opsi-Server, kommuniziert also mit dem Opsi-Server also über ein Gateway.
Allerdings setzt das Argument "-t1" des Ping-Befehls die TTL des Pakets auf 1. Dadruch schlägt der Ping entsprechend fehl; es erscheint die genannte Fehlermeldung.

Anschließend habe ich meinen Testclient in das entsprechende Subnetz geschoben - und siehe da: die Installation läuft ohne Probleme.

Ich weiß nicht, ob das Kommando durch das opsi-linux-bootimage, oder durch das mint-22 Netboot-Paket vorgegeben wird. Außerdem haben wir vor der Verwendung des neuen Netboot-Image noch nicht versucht Linux Mint per Opsi zu installieren. Für mich ist also nicht nachzuvollziehen, ob die Problematik erst seit dem neuen Bootimage besteht. Weiterhin habe ich durch meine bisherige Recherche auch keine Möglichkeit gefunden den Befehl entsprechend selbst anzupassen, etwa über eine Property im Netboot-Produkt oder über ein Kommandozeilenargument für das opsi-linux-bootimage.

In beiden Fällen aber meine Frage: Warum wird die TTL entsprechend niedrig eingestellt? Gibt es hier Prozesse, welchen keinen "Hop" vertragen? Für unser Setup wäre es mit Abstand am einfachsten die TTL etwas hochzusetzen. Ist das möglich? Wenn ja, wie?

Liebe Grüße und Danke für eure Hilfe

Hallo,

das Problem sollte mit der Version 4.3.0.3-4 behoben sein.
https://opsipackages.43.opsi.org/experi ... x/netboot/

Grüße
Jan Schneider

Hallo,

danke für die Antwort - der Fehler taucht nun tatsächlich nicht mehr auf, dafür erhalte ich einen anderen: Anscheinend fehlt nun also der Befehl zum dekomprimieren der initrd?
Der einzige Unterschied ist, dass ich das "neue" Paket zum Testen mit einer anderen Product-ID auf dem Opsi-Server installiert habe. Gibt es da einen Zusammenhang?

Grüße

Hallo,

auch dieses Problem sollte jetzt ab bootimage-Version 20251007 behoben sein.
Die neue Version kann hier heruntergeladen werden:

https://software.opensuse.org//download ... -bootimage

Grüße
Jan Schneider

Hallo,

ich habe das neue Bootimage eingespielt - neue Versionsnummer wird beim Starten auch angezeigt.

Allerdings bekomme ich wieder eine andere Fehlermeldung, diesmal: Danke noch einmal für deine Bemühungen bisher.

Moin,

im setup.py von mint unterscheiden wir Kompressionsmethoden je nach product-id.
lz4 wird nur als fallback verwendet, wenn weder "mint21" noch "mint22" in der product-id vorkommen. (Anscheinend wurde in älteren mint-Versionen mal lz4 als Kompression verwendet). Sowohl mint21, als auch mint22 nutzen zst.

Workaround könnte also sein, das Produkt als "mint22" auf dem Depot zu installieren (oder zumindest als etwas, was "mint22" enthält).
Ich werde den Fallback im Paket anpassen, sodass in Zukunft zstd verwendet wird.

Die Änderung ist in mint*_4.3.0.4-1 soeben nach experimental gegangen.

Hallo,

Das Paket hatte den Namen "mint22-test", anscheinend ist aber dennoch ein Fallback auf lz4 passiert?
Ich habe versucht das neue experimental Paket auch nocheinmal unter dem Namen "mint22-test" zu installieren, selbe Fehlermeldung.
Anschließend habe ich das Paket als "mint22", als dem regulären Namen installiert und siehe da: dekomprimieren des Pakets klappt jetzt.
Nun geht der Installationsprozess weiter, bis zu dem Punkt an dem Busybox gestartet wird. Entsprechenden Screenshot habe ich angehangen, bitte entschuldigt die Zensur, aber ich kaann unter Domain / IP-Konstrukt leider nicht veröffentlichen

Was für mich auf jeden Fall auffällig ist: in der sechten Zeile von unten wird versucht von der x.x.x.1 das Linux Mint Image zu laden. Das ist allerdings nur das Gateway in dem Netz. Der Opsi-Server hat die x.x.x.254, von dieser Adresse gehen auch die DHCP-Offers aus. Eine gültige Lease erhält das System ja auch sowohl im Kernel des bootimages, also auch anschließend in Busybox.
Das unter der Adresse x.x.x.1 nichts gefunden wird, ist also klar. Allerdings endet dann auch die Auflösung des Hostnames in einem Segmentation fault, was ich mir nicht so ganz erklären kann. Wenn man anschließend in der busybox Umgebung versucht den Namen aufzulösen, funktioniert das.
Für mich ist nun nicht ganz verständlich, warum versucht wird das Image von der x.x.x.1 zu laden und warum die Namensauflösung fehlschlägt.

Grüße

Hallo,

ich möchte dem Beitrag hier nur kurz einen "Bump" geben. Können wir noch etwas testen oder korrigieren? Falls ja, bitte bescheid geben.

Vielen Dank.