(Solved) - Opsi-image-prepare bricht mit Python Errors ab

[psycho.unibas]

Hallo Community,

ich setze mich gerade mit dem Thema Opsi-LocalBoot auseinander und scheitere leider schon bei der Vorbereitung mittels opsi-image-prepare.
Wenn ich die Partitionierung starte sieht auch erstmal alles gut.
Aber sobald das Opsi Linux Bootimage anfängt zu starten, wird die DHCP-Adresse nicht automatisch erkannt und ich muss die Informationen manuell eintragen.
Frage 1: Sollte das nicht automatisch erkannt werden?
Und Problem 2 ist, dass wenn ich die Daten manuell eingetragen habe und die Installation starte, bekomme ich komische python Errors angezeigt und die Installation bzw. die Partitionierung bricht ab.

Leider finde ich die Fehlermeldungen auch nicht in meinem Boot-Image Log, Client Log oder so.

Hatte jemand schonmal das Problem und hat eine Idee?

Danke vorab.

Grüsse,
Alex

[m.radtke]

Hallo Alex

zu 1:
das opsi-linux-bootimage bekommt viele Informationen über den Netboot. Sollten diese nicht verfügbar sein weil das bootimage zB über das Grub Menü gestartet wurde oder von USB-Stick bzw. CD/ISO dann versucht es die Informationen aus den DHCP Infos zu ziehen.

Sind diese nicht vorhanden, dann muss man sie leider eintippen. INteressant zu wissen wäre, welche Information genau fehlt und du eintippen musst.

Zu 2:
Hier braucht es eine genauere Angabe zum Problem bzw den Fehlern. Ein Bild könnte da sicherlich helfen.
Ich selbst habe gestern eine VM mit opsi-local-image-prepare ausgeführt. Das hat wie gewohnt geklappt.

Welchen Serverstand von opsi setzt ihr ein?

Code: Alles auswählen

dpkg -l | grep opsi
bzw
rpm -qa | grep opsi

Gruß
Mathias

[psycho.unibas]

Hallo Mathias,

Ich kann leider keine Screenshots hochladen, da wohl das Kontingent aufgebraucht ist...

zu 1:
Ich boote das Image über Network-Boot indem ich das Image auf Setup in der Admin-Konsole setze.
Es fehlt die IP Adresse, das Gateway und der DNS-Server.


zu 2:
Bsp. Fehlermeldungen:
File "requests/apapters.py" line 406 in send
File "urllib3/connectionpool.py" line 845 in urlopen
File "urllib3/util/retry.py" line 515, in Increment

Es sieht so aus, als ob er den Opsi Server nicht erreichen würde.
Verstehe aber nicht ganz wieso, weil der Initiale Boot funktioniert ja.

[Nachtrag zur Version]
ii opsi-linux-bootimage 20240110-1 all opsi bootimage for netboot tasks.
ii opsi-linux-support 4.2.0.0-1 all Configure system to be able to deploy Linux with opsi.
rc opsi-server 4.2.0.72-1 all opsi server
ii opsi-server-full 4.3.2.2-1 all opsi server
ii opsi-tftpd-hpa 5.2.8-80 amd64 HPA's tftp server
ii opsi-utils 4.3.4.4-1 amd64 Utilities for working with opsi
ii opsi-webgui 4.3.30-1 all opsi webgui
ii opsi-windows-support 4.2.0.3-1 all Install utilities useful for deploying Windows with opsi.
ii opsiconfd 4.3.16.3-1 amd64 opsi configuration service
ii opsipxeconfd 4.3.3.4-1 amd64 opsi pxe configuration service


Grüsse,
Alex

[m.radtke]

Hi Alex

um was für ein Gerät handelt es sich dabei?
Wechsel mal die Konsole (Strg-Alt-F4), logge dich ein (root:linux123) und gebe den Befehl

Code: Alles auswählen

ip a s

ein
Da solltest du sehen welche Netzwerkkarten verfügbar sind.

Vermutlich ist es ein Treiberproblem mit der Netzwerkkarte.

Gruß
Mathias

[psycho.unibas]

Es handelt sich um ein Lenovo Thinkpad X1 Carbon.
Das Notebook ist mittels USB-C an eine Docking-Station angeschlossen, da man heutzutage ja keine Netzwerk-Ports mehr verbaut

Das ist der Output von dem Befehl ip a s

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
2: enp0s31f6: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
link/ether f8:75:a4:b3:10:70 brd ff:ff:ff:ff:ff:ff
inet 131.152.156.28/24 brd 131.152.156.255 scope global enp0s31f6
valid_lft forever preferred_lft forever
15: enx0050b6916991: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 00:50:b6:91:69:91 brd ff:ff:ff:ff:ff:ff

Der State ist down, aber keine Ahnung wieso, weil wenn ich in das PXE boote, ist alles in Ordnung. Und ein normales OS-Deployment funktioniert auch einwandfrei.

Gruss
Alex

[m.radtke]

Hey Alex,

welche der Macadressen hast du im opsi-configed für den Client hinterlegt?

Schau bitte auch nach den Mac Passthrough Einstellungen im UEFI.

Gruß
Mathias

[psycho.unibas]

Hallo Mathias,

als MAC-Adresse steht die MAC der Docking-Station im OPSI.
MAC Passthrough ist bei den Geräten deaktiviert, da Sie sonst keine IP bekommen würden.
IPs werden bei uns anhand der MAC vergeben und da stehen immer nur die Docking-Stations drinne. Sprich ein Client kann nur eine IP bekommen, wenn er an einer entsprechenden Docking-Station hängt.

Grüsse,
Alex

[m.radtke]

Hi Alex

Log dich nochmals ins Bootimage ein und gebe folgenden Befehl ein

Code: Alles auswählen

dhclient enx0050b6916991

Und schau dann bitte noch nach ob nun eine IP auf der Netzwerkkarte von der Docking Station vorhanden ist.

Gruß
Mathias

[psycho.unibas]

Hallo Mathias,

also ich habe letzte Woche nochmal ein paar tests gemacht und gemerkt, dass wenn ich einen USB-Netzwerkadapter anschliesse, welcher keine eigene MAC-Adresse mitbringt, funktioniert das Deployment.
Sprich, es muss irgendwie mit der Docking-Station / MAC / IP Vergabe zusammenhängen.
Ich versuche dem ganzen die nächsten Tage nochmal weiter auf die schliche zu kommen.

Grüsse,
Alex

[m.radtke]

Hi Alex

du kannst, falls du ein bootimage.og von dem Client hast, gerne das Log auf pastebin klatschen und den Link posten.
Schaue es mir dann gerne an.

Das Log kannst du per SSH, oder klassisch per USB Stick vom Client holen wenn es nicht am opsi-Server ist.
Login ist root:linux123
Das Log liegt unter /tmp/log

Gruß
Mathias