wir haben unseren Eltern angeboten, private digitale Endgeräte zu „linboisieren“ und sammeln daher gerade massenweise Erfahrungen mit unterschiedlichen Boot-Konfigurationen, Bios-Einstellungen, etc. Erst einmal genial: unsere Images (Win10+Ubuntu+Prüfung) samt Linbo laufen auf bisher 95% der Geräte - von kleineren Treiber-Problemen unter Windows abgesehen. Und die vorher skeptischen Eltern sind nach anfänglicher Skepsis begeistert von dem, was sie da geliefert bekommen (da kann ein gebrauchtes X1 Yoga dann plötzlich tatsächlich in Sachen Coolness mit einem Ipad mithalten!).
Ein Problem, dass wir bisher nur umständlich bis gar nicht in den Griff bekommen, sind USB2LAN-Adapter auf Geräten, die keinen eigenen LAN-Anschluss mehr besitzen.
Hier beobachte ich ein seltsames Verhalten, vor allem bei „schnelleren“ Geräten: Ubuntu zeigt an, dass es eine Netzwerkverbindung versucht - und bricht dann ab (lädt nichts vom Server und es kommt der Bildschirm 1) Neustart 2) Herunterfahren.
Zunächst habe ich dhcpretry versucht zu erhöhen - das hat aber an dieser Stelle anscheinend keine Auswirkungen. Mir scheint es, als warte Linbo nicht lang genug, bis der Netzwerkadapter initialisiert ist ODER er spricht den Adapter irgendwie falsch an.
Interessanterweise gelingt nämlich oft folgendes: ich packe einfach 2 USB2LAN-Adpater in USB-Ports (einen mit, den anderen ohne Kabel). Er erkennt den ersten als eth0 - hier schlägt die Initialisierung erneut fehl. Dann versucht sich Linbo am zweiten, benennt diesen um (nicht mehr eth1, sondern enx…) und lädt darüber die Dateien vom Server.
Hat jemand eine Idee, wo man noch dran drehen könnte? Oder gibt es hier Stellschrauben in Linbo, die man verändern könnte? Denn im Grunde scheint es ja zu gehen.
hatte ich oben schon erwähnt - mit verschiedenen Werten (auch 20) probiert, das hat an dieser Stelle keine Auswirkungen.
Ich denke, die Adapter werden nicht korrekt initialisiert bzw. Linbo wartet nicht lang genug oder spricht sie anders an, als es helfen würde. Linbo versucht es ja mit eth0/eth1/… und bricht dann sofort ab.
Im Debug-Modus ist der Adapter aber nach einigen Sekunden Pause über enx… (ich glaube, das sind die udev-Namen) erreichbar. Und dann tut alles, wie es soll.
Irgendwo in init.sh (ich denke in der Funktion „network()“ kommt Linbo im Falle dieser Adapter durcheinander. Und da es immer weniger Geräte mit echter LAN-Buchse gibt, ist das ja evtl. vermehrt relevant.
dhcpretry greift erst nach der Problem verursachenden Initialisierung …
Wir haben ein vergleichbares Problem, wo der PXE-Boot an ganz neuen DELL OptiPlex 7000 Mini Tower mit Intel CPUs der 12.Generation „vereinzelt“ nicht funktioniert. Bei etwa 3-5% der PCs funktioniert hier der PXE Boot nicht, bisher haben wir weder durch „Überkreuz-Tausch“, noch durch BIOS Einstellungen eine konkrete Ursache / Lösung finden können …
dhcpretry greift erst nach der Problem verursachenden Initialisierung …
Wir haben ein vergleichbares Problem, wo der PXE-Boot an ganz neuen DELL
OptiPlex 7000 Mini Tower mit Intel CPUs der 12.Generation „vereinzelt“
nicht funktioniert. Bei etwa 3-5% der PCs funktioniert hier der PXE Boot
nicht, bisher haben wir weder durch „Überkreuz-Tausch“, noch durch BIOS
Einstellungen eine konkrete Ursache / Lösung finden können …
das Problem ist ja an sich gar nicht der Netzwerkname - Linbo kann ja mit anderen Netzwerknamen umgehen.
Das Timing ist aber unter bestimmten Bedingungen so, dass es schief geht.
@gpeter hast Du den Workaround auf einem der betroffenen Rechner mal ausprobiert?
Hier ging es damals nicht weiter - aus meinen Erfahrungen aber mal eine Idee:
es gibt offenbar Kombinationen - gerade bei USB2LAN-Adaptern, bei denen der USB-Adapter erst mit etwas Verzögerung ansprechbar ist. Linbo ist dann Offline, weil es nur eth0 abfragt.
Das löse ich derzeit dadurch, dass ich vom Stick boote, in den Linbo-DEBUG-Modus wechsele und init.sh ein zweites Mal ausführe. Dann findet Linbo den Stick (offenbar braucht der ein wenig, um im System bekannt zu sein), bekommt die IP und alles weitere funktioniert.
Wäre es nicht möglich, neben dhcpretry einen Paramter netwait (o.ä.) einzuführen, der einfach eine Pause vor der Schleife über die Netzwerkgeräte (im aktuellen Linbo7 vor Zeile 394) einlegt? Könnte ja standardmäßig 0 sein (also so etwas wie: [ -z "$netwait" ] && netwait=0 und ein anschließendes sleep $netwait).
Mir scheint es kein schlechter Ankerpunkt, um bestimmte Timingprobleme beim Booten abzufangen, deren Netzwerkstack so seine Zeit benötigt. Und USB2LAN-Adapter werden in Zukunft wohl eher die Regel, als die Ausnahme.