ich habe hier ein seltsames Problem mit Fujitsu Lifebooks U 7510
Linbo startet, bekommt aber die start.conf der Gruppe nicht, sondern die Default start.conf.
Die Fehlermeldung: No Operating System configured in start.conf
Wenn ich einen USB-Netzwerk Adapter mit dem Laptop verwende, dann klappt alles. Also wohl ein Problem mit der Netzwerkkarte. Diese wird zwar grundsätzlich erkannt und ich kann mich mit linbo-ssh auf dem Client einloggen. Aber zu dem Zeitpunkt wo Linbo die start.conf kopieren möchte, klappt das nicht.
Netzwerkkabel wurde schon getauscht, Switche resettet. Das Problem gibt es nur mit dieser Hardware.
Hat jemand eine Idee? @thomas Gibt es evtl. einen aktuelleren Kernel für lmn71, den Du einspielen könntest? Oder gibt es eine Kernel Option für diese Netzwerkkarte?
ich kann im nächsten Paket einen aktuelleren 5.10er Kernel mitliefern. Ob das was hilft, weiß ich allerdings nicht. Kernel 5.15 kommt erst in Linbo 4.1.
Ich habe den Laptop dann noch an meine VirtualBox lmn71 Testumgebung angeschlossen(derselbe Installationsstand), dieselbe start.conf verwendet und siehe da, alles funktioniert.
Der einzige Unterschied in der Netzwerkkonfiguration der mir auffällt ist:
Funktioniert:
e1000e 0000:00:1f.6 eth0: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx
Funktioniert nicht:
e1000e 0000:00:1f.6 eth0: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
„Flow Control“ ist da „None“, also deaktiviert.
Vielleicht hast Du, oder jemand noch eine Idee, wie ich das debuggen könnte?
wenn ich zum Test, wenn der Client in Linbo steht, ein 1 GB File vom Client zum Server kopiere, dann steigt der Wert von „RX dropped“ (ifconfig eth0) rasant an. Das passiert auch auf meinem Testsystem und der Grund warum Linbo trotzdem funktioniert und die start.conf dort lädt, hängt wohl noch von anderen Parametern ab.
Das passiert auch mit dem neuen Linbo Kernel 5.10.89. Also denke ich, daß es sich um oben verlinkten Bug handelt.
Wenn ich auf dem Client Clonezilla mit dem Kernel 5.13.0-21 boote und die Datei vom Clonezilla Client zum Server kopiere, so gibt es keine „RX dropped“ Pakete.
@thomas
So würde ich mich gerne darin versuchen ein linuxmuster-linbo7 mit dem aktuellen 5.15er Kernel zu bauen. Ich möchte ja nichts durcheinanderbringen, aber wäre es Dir vielleicht möglich den Kernel auf linbo-build-cache bereitzustellen? Also falls abzusehen ist, daß der 5.15er Kernel mit dem aktuellen Build Environment zu bauen ist. Ansonsten muß ich einfach warten und die Laptops mit USB-Netzwerk klonen und händisch umzubenennen.
hab ich auch schon gemacht.
Ich hab den Namen in der devices.csv immer vor dem booten des nächsten Clients geändert (und import).
So bekamen alle einen eigenen Namen obwohl ich den gleichen USB Dongel verwendet habe.
Natürlich stehen sie alle nochmal in der devices.csv mit ihrer internen MAC.
klasse, vielen Dank für diese Erleichterung mit dem Docker build environment!
Hat bis auf einen kleinen Bug(?) im Dockerfile(Issue ist eröffnet) wunderbar funktioniert.
Leider bringt der 5.15.13er Kernel keine Lösung meines Problems. Die RX dropped Pakete sind nach wie vor da.
Jedenfalls kann ich jetzt einfach bei erscheinen eines neuen Kernels einfach testen.
die Netzwerkkarte ist eingebaut, mit der funktioniert Linbo nicht. Mit der USB-Netzwerkkarte klappt alles.
Aber ein anderes Gerät probieren ist ein guter Tip, danke! Vielleicht ist es ja auch ein Defekt. Sobald die Leihgeräte zurück sind, werd ich das probieren.
Der Unterschied ist im Bindestrich des Hostnames für den WLAN Eintrag des Notebooks. Offenbar wird da von Linbo der Hostname des WLAN Clients vorher gefunden und die Hardwaregruppe „nopxe“ erkannt. Am Linbo Screen des PC wird aber alles richtig angezeigt, also home-pc03, 10.0.13.7 und die richtige MAC.
Könntest Du bitte den Fehler finden und einen Fix bereitstellen? Oder soll ich alle Hostnamen umbenennen? Praktisch ist es schon, die WLAN Geräte einfach mit dem -wlan greppen zu können.
PS: Gibt es mittlerweile eine bessere/andere Möglichkeit die WLAN MAC zusätzlich zu einer LAN MAC eines PCs aufzunehmen, oder ist obige Vorgehensweise nach wie vor richtig?
sieht nach einem Bug aus. Danke fürs Debuggen. Erstellst du bitte noch einen Issue? Sollte dann bald gefixt sein.
Bei Notebooks habe ich nur noch einen Eintrag in devices.csv mit DHCP statt IP, dann funktionieren sie drahtgebunden in allen VLANs. Für WLAN braucht man eigentlich keinen Eintrag, da reicht doch eine IP aus der Range. Wenn Domänenbeitritt und Image im LAN gemacht wurden, funktioniert das dann auch im WLAN.
es tut mir ja schrecklich Leid, aber ich muss da eine Beobachtung von Heute mal berichten.
Ich hab an meiner virtuellen Testumgebung rumgeschraubt: nix schlimmes: nur aktualisieren.
Dabei hab ich auf 4.06 upgedatet. Erstmal alles gut.
Mehrfach gebootet, Image geschrieben, gesynct alles fein.
Dann wollte ich die Umgebung vorbereiten zum Exportieren.
Das mache ich so, dass ich die Festplatte der Clients verwerfe und eine neue zur Verfügung stelle.
Die partitioniere ich imemr mit linbo, bevor ich exportiere.
Das hat nicht geklappt, weil ich, wenn ich mit der leeren Festplatte drin boote, dann kam das von Klaus beschriebene Problem „no Operatingsystem found“ und es war keien start.conf auf dem Client (wohlgemerkt: mit linbo 4.06).
Also hab ich geschaut, ob da was komisch ist: Zugriffsrechte der start.conf.winlin: 644
Name in devices.csv: die Rechner heißen r100pc01 und r100pc02.
Paranoid wie ich bin hab ich eine examplesstart.conf hinkopiert und mehrfach linuxmuster-import-devices gemacht. Auch ein update-linbofs … hat alles nix gebracht.
Dann hab ich die Rechner umbenannt zu r100-pc01 und import gemacht: schwupps ging es wieder.
Frech wie ich bin, hab ich sie gleich zurück benannt: ging immer noch…
Wenn ich das richtig hab, dann holt linbo jetzt die gruppe des Clients aus dem AD und das scheint bei Clients, deren workstations Accouont vor langer Zeit erstellt wurde, schief zu gehen.
Das gemeine: man merkt es erst, wenn man dem Client eine leere Festplatte vor setzt…
Ich habe ältere Versionen der Umgebung, falls da jemand in den AD reinschauen will…
Du könntest es ja ausprobieren, was die neue Abfrage nach der Gruppenzugehörigkeit bei Dir liefert:
r100pc02 ersetzen durch einen Hostnamen, den Du jetzt neu noch nicht umbenannt hattest: