Openthinclient Boot time issue
Guten Tag in die Runde,
ich habe ein Problem mit unseren Openthinclients, und nachdem ich nun schon einiges ohne Erfolg analysieren konnte, kann mir hier vielleicht jemand helfen.
Kennt das Problem jemand, oder hat jemand gar eine Lösung dafür?
Vielen Dank und viele Grüße
Stefan
ich habe ein Problem mit unseren Openthinclients, und nachdem ich nun schon einiges ohne Erfolg analysieren konnte, kann mir hier vielleicht jemand helfen.
Grundsätzlich fahren die Devices hoch, allerdings dauert dies mehrere Minuten
Nach Einschalten des Bootlogs konnte ich feststellen dass das Problem replizierbar an der gleichen Stelle beim Bootvorgang liegt
"Enter Auth Username: [ 9.881778 Generic FE-GE Realtek PHY r8169-0-100:00:99: attached PHY driver (mii_bus:phy_addr=r8169-0-100:00, irq=MAC)"
Erster Verdacht: OpenVPN, da hier die Einstellung Usereingabe abfragen aktiv ist
Quercheck: OPENVPN herausgenommen: Gleiches Ergebnis
Nach Einschalten des Bootlogs konnte ich feststellen dass das Problem replizierbar an der gleichen Stelle beim Bootvorgang liegt
"Enter Auth Username: [ 9.881778 Generic FE-GE Realtek PHY r8169-0-100:00:99: attached PHY driver (mii_bus:phy_addr=r8169-0-100:00, irq=MAC)"
Erster Verdacht: OpenVPN, da hier die Einstellung Usereingabe abfragen aktiv ist
Quercheck: OPENVPN herausgenommen: Gleiches Ergebnis
Kennt das Problem jemand, oder hat jemand gar eine Lösung dafür?
Vielen Dank und viele Grüße
Stefan
Kommentieren
Teilen
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 673561
Url: https://administrator.de/forum/openthinclient-boot-problem-dauer-673561.html
Ausgedruckt am: 26.06.2025 um 15:06 Uhr
12 Kommentare
Neuester Kommentar
Moin,
wäre vielleicht sinnvoll zu ein paar mehr Details zu nennen, etwa wie deine Thinclients denn den OpenThinClient booten => USB/SSD/Network(PXE) und wie deren OpenThinClient denn initial konfiguriert wurde.
Gruß
wäre vielleicht sinnvoll zu ein paar mehr Details zu nennen, etwa wie deine Thinclients denn den OpenThinClient booten => USB/SSD/Network(PXE) und wie deren OpenThinClient denn initial konfiguriert wurde.
Gruß
1
Hi Biberman,
da hast Du natürlich recht.
Die Geräte booten über PXE.
Es gibt auch die Option eines Localboot. Dann booten die Devices über ein lokales Image. Im lokalen Netzwerk wird das aber übersprungen, wenn PXE eingerichtet ist und funktioniert. (Werde aber mal einen Test machen und die Localboot-Option herausnehmen.)
Viele Grüße
Stefan
da hast Du natürlich recht.
Die Geräte booten über PXE.
Es gibt auch die Option eines Localboot. Dann booten die Devices über ein lokales Image. Im lokalen Netzwerk wird das aber übersprungen, wenn PXE eingerichtet ist und funktioniert. (Werde aber mal einen Test machen und die Localboot-Option herausnehmen.)
Viele Grüße
Stefan
OK.
Wenn das nicht den Erfolg bringt, auch mal den Debug Modus verwenden und den Bootvorgang verfolgen um zu sehen welcher Prozess da abfragt
Wenn das nicht den Erfolg bringt, auch mal den Debug Modus verwenden und den Bootvorgang verfolgen um zu sehen welcher Prozess da abfragt
Startoptionen > Debugmodus für Startvorgang > Debugge init-script (für Experten)
(An den Debug-Breakpoints "exit" eintippen um im Bootvorgang weiter zu machen)1
Localboot kann ich ausschliessen.
Allerdings steht nach dem Eintrag oben im Bootlog:
[***] Job openvpn@openvpn.service/start running (30s / 1min 31s).
Das sieht dann doch eher danach aus, als würde der Dienst openvpn nicht starten können, da ihm keine Zugangsdaten bekannt sind.
Allerdings steht nach dem Eintrag oben im Bootlog:
[***] Job openvpn@openvpn.service/start running (30s / 1min 31s).
Das sieht dann doch eher danach aus, als würde der Dienst openvpn nicht starten können, da ihm keine Zugangsdaten bekannt sind.
Zitat von @SFischer:
Allerdings steht nach dem Eintrag oben im Bootlog:
[***] Job openvpn@openvpn.service/start running (30s / 1min 31s).
Das sieht dann doch eher danach aus, als würde der Dienst openvpn nicht starten können, da ihm keine Zugangsdaten bekannt sind.
Ja, dann liegt es offensichtlich an OpenVPN. Wie und was habt ihr für OpenVPN denn für eine Auth konfiguriert (User:Pass / Zertifikat)?Allerdings steht nach dem Eintrag oben im Bootlog:
[***] Job openvpn@openvpn.service/start running (30s / 1min 31s).
Das sieht dann doch eher danach aus, als würde der Dienst openvpn nicht starten können, da ihm keine Zugangsdaten bekannt sind.
Und gibt es das Problem schon länger oder wurde evt. etwas am OpenVPN Server geändert?
1
OpenVPN gibt es schon länger hier, wir haben bislang IGEL Clients eingesetzt, die sich beim Booten dann mit einem Watchguard-Cluster verbinden. Nach VPN-Aufbau wird dann eine RDP-Session aufgebaut. Das klappt gut, ist aber relativ teuer.
Die Openthinclients sollen das gleiche machen. Ähnlich wie bei den IGEL-Geräten ist Openvpn teil des OS und wird über eine Management GUI mitverwaltet. Ich vermute, dass hier das Problem zu suchen ist. Anscheinend wir der Openvpn-Dienst immer mitgeladen, wenn einmal hinzugefügt, auch wenn man den später wieder aus der Konfig entfernt.
Das Problem gibt es auch in einer ähnlichen Konstellation mit Ubuntu:
https://askubuntu.com/questions/627842/what-does-the-form-field-enter-au ...
Nachdem das ganz dann doch relativ schnell komplex wird, dachte ich, ich frage mal hier nach.
Die Openthinclients sollen das gleiche machen. Ähnlich wie bei den IGEL-Geräten ist Openvpn teil des OS und wird über eine Management GUI mitverwaltet. Ich vermute, dass hier das Problem zu suchen ist. Anscheinend wir der Openvpn-Dienst immer mitgeladen, wenn einmal hinzugefügt, auch wenn man den später wieder aus der Konfig entfernt.
Das Problem gibt es auch in einer ähnlichen Konstellation mit Ubuntu:
https://askubuntu.com/questions/627842/what-does-the-form-field-enter-au ...
Nachdem das ganz dann doch relativ schnell komplex wird, dachte ich, ich frage mal hier nach.
Zitat von @SFischer:
Anscheinend wir der Openvpn-Dienst immer mitgeladen, wenn einmal hinzugefügt, auch wenn man den später wieder aus der Konfig entfernt.
Kann ich hier im Test nicht nachvollziehen, wenn ich den Autostart nachträglich wieder deaktiviere und das Profil aktualisiere, startet der Dienst auch nicht mehr von selbst.Anscheinend wir der Openvpn-Dienst immer mitgeladen, wenn einmal hinzugefügt, auch wenn man den später wieder aus der Konfig entfernt.
https://docs.openthinclient.com/2025/books/openthinclient-management-ser ...
Im Zweifel nimmt man halt den Link für den Start von Hand raus aus dem Image.
Hi BiberMan.
vielen Dank für den Input und die Hilfe.
Der Hinweis mit dem Debuggen war super, das Ergebnis ist aufschlussreich:
Gibt man im Bootscreen bei der auth-Eingabe einfach enter ein, dann erscheint:
Es erscheint damit für mich also so, dass schon beim Booten Credentials abgefragt werden.
vielen Dank für den Input und die Hilfe.
Der Hinweis mit dem Debuggen war super, das Ergebnis ist aufschlussreich:
2025-06-26 15:52:11,963 ERROR 00:e0:c5:1f:12:88 192.168.10.199 user openvpn Failed to run application.
Traceback (most recent call last):
File "/opt/openvpn/tcos/launcher", line 232, in <module>
run_app(app_config)
File "/opt/openvpn/tcos/launcher", line 125, in run_app
if result.get('code') != tcos.dialog.OK:
^^^^^^^^^^
AttributeError: 'NoneType' object has no attribute 'get'
2025-06-26 15:52:11,967 WARN 00:e0:c5:1f:12:88 192.168.10.199 user openvpn Failed to connect to dialog socket: Connection refused
Retrying... (Attempt 1/30)Gibt man im Bootscreen bei der auth-Eingabe einfach enter ein, dann erscheint:
2025-06-26 16:09:58,523 INFO 00:e0:c5:1f:12:88 192.168.10.199 daemon systemd-tty-ask-password-agent Password query on /dev/tty1 finished successfully.
2025-06-26 16:09:58,552 INFO 00:e0:c5:1f:12:88 192.168.10.199 daemon systemd-tty-ask-password-agent Starting password query on /dev/tty1.
2025-06-26 16:09:59,831 INFO 00:e0:c5:1f:12:88 192.168.10.199 daemon systemd-tty-ask-password-agent Password query on /dev/tty1 finished successfully.
2025-06-26 16:09:59,833 ERROR 00:e0:c5:1f:12:88 192.168.10.199 daemon ovpn-openvpn ERROR: Auth username is empty
2025-06-26 16:09:59,833 INFO 00:e0:c5:1f:12:88 192.168.10.199 daemon ovpn-openvpn Exiting due to fatal errorEs erscheint damit für mich also so, dass schon beim Booten Credentials abgefragt werden.
if result.get('code') != tcos.dialog.OK:
^^
AttributeError: 'NoneType' object has no attribute 'get'
Das klingt sehr nach Programmier-Fehler, da hier offensichtlich die Variable "result" nicht auf Inhalt geprüft wird. Ist das Image des ThinClient up to date?^^
AttributeError: 'NoneType' object has no attribute 'get'
Prüfe auch folgendes:
- Wenn du den Dienst nur gestoppt oder deaktiviert und die OpenVPN Config entfernt hast ohne das Profil zu aktualisieren kann das vorkommen das der Dienst weiterhin beim Boot startet und dann natürlich fehl schlägt.
- Auf dem ThinClient-Dateisystem prüfe im launcher script
/opt/openvpn/tcos/launcherob dort OpenVPN fest eingebaut wurde. - Schau in eventuell noch vorhandene *.xml oder *.conf Dateien auf Referenzen zu deiner alten OpenVPN Konfiguration
- Ansonsten erstelle das Boot-Image mit deinem bereinigten Profil neu (regenerate/redeploy).
Erst einmal vielen Dank für Deine Zeit und die Hilfe:
Was ich nun gemacht habe:
Patchlevel geprüft >Ist ok
Localboot Image neu erstellt
Test mit localboot und PXE liefern allerdings immer noch das gleiche Ergebnis.
client
proto tcp
<ca>
BEGIN CERTIFICATE-----
*
END CERTIFICATE-----
</ca>
<cert>
BEGIN CERTIFICATE-----
*
END CERTIFICATE-----
</cert>
<key>
BEGIN PRIVATE KEY-----
***
END PRIVATE KEY-----
</key>
remote-cert-eku "TLS Web Server Authentication"
remote IP.IP.IP.IP 443
persist-key
persist-tun
verb 3
mute 20
keepalive 10 60
data-ciphers AES-256-CBC
auth SHA256
float
reneg-sec 28800
nobind
mute-replay-warnings
auth-user-pass
tls-version-min 1.2
;remember_connection 0
;auto_reconnect 1
Meine nächste Idee wäre das OTC komplett zu resetten und mit einem blanken Gerät zu beginnen, die Konfig Zug um Zug auszurollen...
Was ich nun gemacht habe:
Patchlevel geprüft >Ist ok
Localboot Image neu erstellt
Test mit localboot und PXE liefern allerdings immer noch das gleiche Ergebnis.
Im /opt/openvpn/tcos/launcher ist openvpn fester Bestandteil
openvpv.conf ist sauber, da ist wenig drin:
dev tunopenvpv.conf ist sauber, da ist wenig drin:
client
proto tcp
<ca>
BEGIN CERTIFICATE-----
*
END CERTIFICATE-----
</ca>
<cert>
BEGIN CERTIFICATE-----
*
END CERTIFICATE-----
</cert>
<key>
BEGIN PRIVATE KEY-----
***
END PRIVATE KEY-----
</key>
remote-cert-eku "TLS Web Server Authentication"
remote IP.IP.IP.IP 443
persist-key
persist-tun
verb 3
mute 20
keepalive 10 60
data-ciphers AES-256-CBC
auth SHA256
float
reneg-sec 28800
nobind
mute-replay-warnings
auth-user-pass
tls-version-min 1.2
;remember_connection 0
;auto_reconnect 1
Meine nächste Idee wäre das OTC komplett zu resetten und mit einem blanken Gerät zu beginnen, die Konfig Zug um Zug auszurollen...
auth-user-pass
Das würde ne Eingabe für Username und Password triggern, oder liegt da nen Plaintext file mit den Creds rum.Meine nächste Idee wäre das OTC komplett zu resetten und mit einem blanken Gerät zu beginnen, die Konfig Zug um Zug auszurollen...
Clean ist immer gut. 
.
