wir haben derzeit ein Problem mit unseren LinuxClients (linuxMint22.04). Der PXE-Boot funktioniert, auch in LINBO haben die Clients die korrekte IP Adresse. Sogar wenn man sie vom Stick mit einem anderen OS booten holen sie sich ihre IP. Aber sobald sie ihr reguläres OS vom Image starten sollen → Fehlanzeige, der Server empfängt die Requests und sendet offers, aber die scheinen nie anzukommen wenn das OS gestartet ist.
Zusätzlich verwirrend…es betrifft nur einen Rechnertypen. Die TestVMs auf den Servern und Rechner anderen Typs machen keine Probleme mit dem gleichen Image.
Eben dieses Image hat auch auf den Rechnern, die jetzt nicht mehr wollen, letzte Woche noch keine Probleme bereitet. Ich habe auch selten erlebt, das ein Image über Nacht irgendwie „schlecht“ wird.
Es gibt keine logische Erklärung warum der DHCP-Client bei gestartetem Linux auf den betroffenen Rechnen auf einmal in Timeouts rennt, in Linbo aber keine Probleme macht.
DHCP-snooping und ARP-Protect sind abgeschaltet → sonst würde der PXE nicht funktionieren, in Linbo würde man keine IP bekommen und man würde auch sonst keine IP per DHCP bekommen. Andere Clients beziehen ganz normal ihre IP der DHCP aus dem Pool.
Irgendwer eine Idee dazu?
ich denke, du solltest einen anderen Netzwerkkartentreiber auf dem Client installieren.
Bekomm mal heraus, welche verbaut ist mit
lspci
und schau dann nach, ob es da Probleme mit dem von dir verwendeten Kernel gibt.
Wahrscheinlich reicht es auch, wenn du einfach einen (wahrscheinlich RealTek) treiber blacklistest oder einfach einen neueren Kernel installierst.
Ab und zu (hab ich nur bei RealTek bisher erlebt) nimmt der kernel einen falschen Treiber, der dann nicht richtig funktioniert.
Danke für deine schnelle Antwort. Ich hatte das Problem überhaupt noch nie, dass von heute auf morgen ein Image nicht mehr funktioniert, welches seit 8 Monaten problemlos lief. Als wäre das Haltbarkeitsdatum abgelaufen. Anscheinend ist das Problem erst aufgetreten, nach wir am Freitag die Updates für Linbo eingespielt hatten. Allerdings bringt auch das Zurückspielen auf ein älteres Backup keine besseren Ergebnisse.
Ich hab mal ein paar Screenshots zur gestrigen Fehleranalyse hinzugefügt.
Was wir noch nicht getestet haben. Server auf den Stand vor Freitag aus dem Backup starten und dann die Clients nochmal über Linbo booten lassen. Evtl. gibts ja doch einen (für mich unersichtlichen/unlogischen) Zusammenhang mit den Updates.
Das Kernelmodul igb war bislang eigentlich immer problemlos und wie gesagt, am Image selbst wurde nichts verändert.
wofür ist den der Kernelparameter
biosdevname=0 ?
Lass ihn mal weg (danach import machen und dran denken, dass die /srv/linbo/boot/grub/GRUPPE.cfg neu geschrieben werden muss).
das soll bewirken, dass die Netzwerkkarten weiterhin eth0, eth1 usw. heißen und nicht ens190 oder ähnlich. Den Parameter hab ich bereits deaktiviert, und die entsprechenden Schritte ausgeführt aber erfolglos.Das hatte ich auch schon in Verdacht.
wir haben den Server per Backup auf den Stand am Donnerstag vor dem Update zurückgespielt und jetzt treten die Probleme nicht mehr auf. Scheint doch durch das linbo-update was verbogen zu haben.
Auf die Gefahr hin das das nichts damit zu tun hat:
In diesem Beitrag vor vielen Jahren ging es um den FQDN und dan fehlerhafter Netzwerkinitialisierung in Linbo: FQDN als hostname in der DNS Auflösung? - #11 von foer?
fi
----- if [ -n „$LINBOSERVER“ ]; then
+++ if [ -n „$SERVERID“ ]; then
# add fqdn to environment
echo „export FQDN='“${HOSTNAME}.${DOMAIN}„'“ >> /.env
export FQDN=„${HOSTNAME}.${DOMAIN}“
Ich habe da bislang absolut keinen Zusammenhang erkennen können. Aber es scheint irgendwie einen zu geben. Bei der betroffenen Rechneranzahl 400+ wars erstmal wichtig, wieder Funktionalität herzustellen als jetzt noch tiefer in die Fehleranalyse zu gehen. Das mach ich dann irgendwann mal, wenn kein Unterricht mehr ist. Absolut rätselhaft, wieso das nur bei einem Rechnertyp aufgetreten ist. Unglücklicherweise waren das quasi alle Rechner der Schule. Abgesehen von einer Handvoll Rechner anderen Typs und der virtuellen Test-Maschinen hats die Schule komplett lahm gelegt.
Da es keinen offenkundigen Zusammenhang gibt (warum sollte nach einem linbo-update auf dem Server der Client nach Start des OS keine IP mehr vom DHCP bekommen?), suchst du natürlich erstmal woanders.
Das einzig Vorstellbare wäre, dass sich die Clients nach dem linbo-update irgendeine Config-Datei per Postsync geholt haben, die sie vorher aus Gründen xy nicht erhalten haben, welche dann die Probleme ausgelöst hat.
Da fällt mir ein wesentlicher Unterschied ein: Alle betroffenen Rechner haben eine zusätzliche Netzwerkkarte verbaut. Die Rechner, die funktionierten, haben die zusätzliche Karte nicht. Evtl. spielt das irgendwie eine Rolle.
Tach,
bei uns spacken bei Linbo 4.2.14-0 auch ganz neue Lenovodesktops rum, auf dem Musterrechner des Lieferanten laeuft es einwandfrei, auf den nachfolgenden, die eine neuere CPU haben, geht nichts. Linbo bootet, der folgende Betriebssystemstart crasht, keine Grafik, allerdings sieht man im Syslog vom Server noch dhcp-discovers vom Client und offers vom Server, aber kein request.
Koennte auch was damit zu tun haben, logisch finde ich es aber nicht.
Aber es scheint irgendwie einen zu geben. Bei der betroffenen Rechneranzahl 400+ wars erstmal wichtig, wieder Funktionalität herzustellen als jetzt noch tiefer in die Fehleranalyse zu gehen. Das mach ich dann irgendwann mal, wenn kein Unterricht mehr ist. Absolut rätselhaft, wieso das nur bei einem Rechnertyp aufgetreten ist. Unglücklicherweise waren das quasi alle Rechner der Schule. Abgesehen von einer Handvoll Rechner anderen Typs und der virtuellen Test-Maschinen hats die Schule komplett lahm gelegt.