[solved] Surface go 2 Bootimage slow

[ithebk]

[SOLVED]
Das Problem war doch ein ganz anderes. Es lag an einem zweiten Lan Interface bzw. das der Opsi Server über zwei Interface erreichbar war. Er wurde mit unterschiedlichen IP Adresse angesprochen. Ka warum er die zwischendurch wechselt für die Anfragen aber er hat es gemacht. Anscheinend verwenden die unterschiedlichen Boot Dienste (Linux-bootimage -> copy pe) unterschiedliche Methoden die IP Adresse zu bestimmen.

------

Hallo zusammen,

ich versuche gerade ein Surface Go 2 mittels Opsi (PXE Boot, USB Ethernet Adapter) aufzusetzen. Der Kopiervorgang des Winpe Images ist so langsam, dass er abbricht. Vor ein paar Monaten hat es noch einwandfrei funktioniert und an allen anderen Computern funktioniert es auch weiterhin fehlerfrei. Ich vermute deshalb ein Problem mit dem Bootimage und habe auch schon ein neueres installiert. Leider hat das keine Besserung gebracht.

Ich hoffe ihr habt noch eine Idee für uns..

dpkg -l | grep opsi

Code: Alles auswählen

opsi-linux-bootimage                                20220124-2  
opsi-linux-support                                  4.2.0.0-1        
opsi-server-full                                    4.2.0.57-1                                  
opsi-tftpd-hpa                                      5.2.8-76                            
opsi-utils                                          4.2.0.145-1                    
opsi-windows-support                                4.2.0.0-1                      
opsi4ucs                                            4.1.1.10-1                        
opsi4ucsappcenter                                   4.2.1.0-1                    
opsiconfd                                           4.2.0.225-1                 
opsipxeconfd                                        4.2.0.22-1                 
python-opsi                                         4.1.1.79-2

[ithebk]

Ich habe mir mal die syslogs auf dem bootimage angeschaut. Dort taucht folgende Zeile auf (name.domain ersetzt):

Code: Alles auswählen

CIFS: VFS:\\ name.domain.de has not responded in 180 seconds

Andere Rechner (kein UEFI, kein surface go mit usb Adapter, gleicher Opsi Server) haben bei uns mit gleichen Firewall Regeln kein Problem sich damit zu verbinden.

Ich bin mir nicht sicher was den Fehler verursacht.. Der Name wird aurfgelöst und mit einem ping erreiche ich ihn auch.

Code: Alles auswählen

clientconfig.depot.id= name.domain.de
clientconfig.configserver.url = https://name.domain.de:4447/rpc
dlientconfig.depot.protocol = cifs
dlientconfig.depot.protocol.netboot = cifs

Wie schon geschrieben: Mit anderen Rechner und dem gleichen Windows netboot Produkt habe ich den Fehler nicht. Mir würden schon Ideen helfen woran es liegen könnte.


Edited:
in /var/log/opsi/opsiconfd/IP.log taucht folgendes auf:

Code: Alles auswählen

(jsonrpc.py:345)
Traceback (most recent call last):
  File "opsiconfd/application/jsonrpc.py", line 200, in process_jsonrpc
  File "starlette/requests.py", line 219, in body
  File "starlette/requests.py", line 213, in stream
starlette.requests.ClientDisconnect

[ThomasT]

Ich tippe jetzt mal hier drauf: viewtopic.php?p=55144#p55144

Aber das Surface Go 2 hatte ich noch nicht in der Hand und kenne mich damit auch nicht aus.

[ithebk]

Die Einstellungen bringen leider keine Veränderung.

Gibt es noch eine andere Idee? Können wir uns mit so einem Problem auch an den Support wenden ohne support Subscription? Wir würden dann natürlich dafür auch zahlen.

[m.radtke]

Hi

ohne Supportvertrag gibt es nur den Weg über den Einführungssupport

Was ihr probieren könnt sind die Bootimage.append Parameter apci=off und/oder noapic

Ansonsten könnt ihr mal im dmesg des Client nachsehen ob dort etwas auffälliges geloggt wird, TX/RX Errors oder ähnliches.
Es könnte aber auch an Netzwerkkomponenten bei euch liegen.

Gruß
Mathias

[ithebk]

Die Bottimage.append Parameter habe ich schon ausprobiert. Das hat nichts gebracht.

Gibt es irgendwo ein archiv der verschiedenen bootimages? Das stable bootimage funktioniert gar nicht mit den surface go 2 und das experimental hat den beschriebenen Fehler.

Im September hatte ich ein experimental bootimage mit dem es funktioniert hat, aber durch die Updates haben wir halt irgendwann ein neueres bekommen. Ich würde dann einfach mal unterschiedliche Versionen ausprobieren.

dmesg werde ich mir morgen mal anschauen.

Danke schonmal

[m.radtke]

Hi

ein Archiv gibt es nicht.

Wenn du ein debianartiges System hast kannst du unter

Code: Alles auswählen

/var/cache/apt

schauen ob dort noch Pakete liegen.

[ithebk]

So wir haben noch einiges ausprobiert und mehr herausgefunden aber es noch nicht gelöst.

Erstmal scheint das Problem doch in die Richtung dieses Threads viewtopic.php?p=55144#p55144 zu gehen.

Es gibt eine Verbindung und das Laufwerk ist auch gemoutet jedoch so langsam, dass er in ein Timeout läuft. Auch ein einfaches 'ls' funktioniert noch sehr schleppend.

Die genannten Vorschläge haben uns aber nicht weitergeholfen. Wir haben nun auf webdav gewechselt. Dort beginnt er auch das winpe Image zu kopieren (auch relativ flott) aber bei der install.esd (4GB) bricht er jedesmal bei +- 18% ab (steht lange und dann ein timeout).

Dazu haben wir bis jetzt aber keine Fehler in den logs gefunden was das verursachen können. Das Problem tritt nur bei den surface go 2 (ethernet usb adapter) auf. Alle anderen Rechner laufen bei uns einwandfrei.

Wir vermuten deshalb, dass da ein Bug in den bootimages ist. Leider haben auch alle bootimages von uns in /apt/cache das Problem nicht behoben.

Über weitere Hilfe und Hinweise würden wir uns sehr freuen.


Edited:
Gibt es im Opsi Webdav Netboot Produkt (win10-x64) irgendwelche festen Timeout settings seitens Opsi? Wir vermuten, dass in der Netboot PXE Installation irgendein Timeout greift.

[ithebk]

Das Problem ist evtl. doch was anderes und es liegt an den nvme Platten bzw. den Treibern dafür oder was ds bootimage damit mach? Kann das sein?

Wenn ich in per cif installiere und dann mich mittels root ins bootimage anmelde -> dann warte bis er stehen bleibt -> cd /mnt/ -> ls

Der ls Befehel dauert ewig aber nachdem er durch ist kopiert er wieder kurz Dateien. Dann wieder ein ls (ca. 5 Minuten warten bis er durch ist) und er kopiert wieder ein paar Daten...

So habe ich die pxe Installation fast durchbekommen am Ende ist sie trotzdem abgebrochen.

Es sind aber nur Vermutungen ich habe keine Ahnung warum ein einfaches ls in /mnt/ in dazu bringt wieder Dateien zu kopieren und weiterzumachen.