Hallo zusammen, ich habe gerade versucht unser v7.0 System auf 7.1 upzugraden.
Es hat im Prinzip geklappt bis auf ein Paket.
Fehl:11 http://pkg.netzint.de bionic InRelease
Verbindung mit pkg.netzint.de:80 konnte nicht aufgebaut werden (185.50.121.245), Zeitüberschreitung aufgetreten
Paketlisten werden gelesen... Fertig
W: Fehlschlag beim Holen von http://pkg.netzint.de/dists/bionic/InRelease Verbindung mit pkg.netzint.de:80 konnte nicht aufgebaut werden (185.50.121.245), Zeitüberschreitung aufgetreten
Nun kann ich nicht mehr auf das WebUI zugreifen und die Clients zeigen keine Images mehr an
Konkret können offenbar die folgenden beiden Datein nicht installiert werden:
Hallo Maurice,
ja, das System läuft seit 2020. Also ist die netzint-Paketquelle nicht mehr existent?
Ich werde sie morgen mal auskommentieren und eine neuen Versuch starten.
Danke erst einmal für den Tipp!
Viele Grüße
Ralf
Ich habe jetzt die veralteten Paketquellen gelöscht. Das System hat weiter konfiguriert und Linbo auf den Clients funktioniert wieder.
Das WebUI wird nun auch wieder angezeigt. Ein Login scheitert jedoch.
Es wird lediglich das sich drehende Vorhängeschloss und die Meldung „Warten auf Server“ angezeigt.
Wenn ich die Seite refreshe wird folgendes angezeigt:
Diese Seite funktioniert nicht
server hat keine Daten gesendet.
ERR_EMPTY_RESPONSE
Update: Das neue Linbo startet leider nur auf 5 von 17 Systemen
Die Systeme, auf denen es funktioniert, habe eigentlich nichts gemeinsam, was sie von den anderen unterscheiden würde. Es sind alle 17 Geräte im gleichen Subnetz, am gleichen Server.
Warum starten dann nur 5 Rechner das neue Linbo???
Was mir gerade noch aufgefallen ist… Die 5 Systeme, die funktionieren, haben eine „start.conf_PCXX“ in /srv/linbo/tmp erzeugt. Dort stehen die 5 Rechner, die das neue Linbo anzeigen, mit Hostname im Dateinamen drin…
Vielleicht hilft die Info einem Kundigen. Ich bin hier echt in Not. Zwei Drittel des Computerraums sind lahmgelegt
Hallo Ralf,
das sieht für mich irgendwie so aus, als würde bei den anderen der PXE-Boot auf den Clients nicht richtig anlaufen. Bist Du sicher, dass die alle via PXE booten und dass bei allen eine gültige IP-Adresse ankommt? Was ist, wenn Du nur einen der Clients startest?
Viele Grüße,
Michael
Wenn ich nur einen Rechner starte ändert sich nichts. Die 5 PCs mit neuem Linbo starten das neue, der Rest nur das alte Linbo.
Alle Rechner sind als PXE boot konfiguriert. Das PXE-Bios bekommt auch eine IP… siehe Foto:
Hallo. Das neue Bild ist aufschlussreicher, denn da steht’s ja:
„Client IP: Offline“
Das ist das Problem!
Der Client bekommt zwar ganz am Anfang eine IP per PXE aber danach (wenn der LINBO-Kernel nochmal eine IP per DHCP vergeben soll), bekommt der Client keine IP mehr. Das kann damit zusasmmenhängen, dass der Client nicht lange genug wartet (DHCPretry in der start.conf höher drehen) oder aber, dass die Netzwerkkarte nicht richtig erkannt wird und kein passender Treiber für das Gerät geladen werden kann.
Hast Du beides bereits ausgeschlossen?
Das der Treiber für die Netzwerkkarte nicht erkannt werden kann, kann ich wohl ausschließen. Ich habe hier im PC-Raum nur zwei Hardware-Plattformen (Terra-PCs und HP-Prodesk). Die sind von der Hardware jeweils identisch. Unter den 5 funktionierenden Systemen sind beide Gerätetypen vertreten…
Jede Hardwareklasse hat natürlich eine eigene start.conf…
UPDATE: habe den Eintrag für dhcpretry gefunden. Der steht auf 20. Ich teste jetzt mal 40…
KernelOptions = quiet splash dhcpretry=10
versuchen – den Wert kann man auch noch nach unten justieren, wenn auch weniger reicht.
Aber 10 Sekunden ist schon mal ein guter Anfang.
Das Update kam erst nach meiner Antwort … 40 ist schon ordentlich. Wenn es so lange dauert, bis der DHCP-Server eine Antwort geliefert hat, sind vermutlich noch andere Effekte (wie z.B. schlechte Netzwerkkabel) mit am Werk. Das Problem wurde hier auch schon öfter diskutiert.
Ich habe jetzt mal bis 50 getestet. Wenn das Sekunden sein sollen, dann hat der Eintrag keine Auswirkung. Der Client wartet keine 50s, das sind ca. 5s…
Verändere ich vielleicht eine falsche start.conf? Ich habe die Datei genommen auf die der Symlink mit der IP zeigt, die das BIOS zuvor erhält. Konkret ist das hier die Datei:
Ein Hardwareproblem fände ich schon sehr unwahrscheinlich. Es hat ja nun knapp 4 Jahre super funktioniert. Das Problem wurde ja erst durch das gestrige Update von 7.0 auf 7.1 ausgelöst…
Hmm – vielleicht hilft es ja, wenn Du einen der hängenden Clients mit
der Konsole unter die Lupe nimmst. Also im alten LINBO auf Imaging → Terminal.
Da kannst Du vielleicht mit dmesg oder auch lspci sehen, was mit der Hardware los ist?
Muss in 5 Minuten weg … daher war das vermtlich vorerst die letzte Antwort.
Dann schonmal danke für deine Hilfe.
Leider sind die hängenden Linbos nicht bedienbar. Weder die Maus, noch die Tastatur funktioniert an diesen Rechner
Hallo Ralf,
hast du schon mal versucht, das neue Linbo aus der Schulkonsole herunterzuladen und z.B. über einen USB-Stick zu booten oder beim Start die Bootoption „Netzwerk-Boot“ dezidiert auszuwählen?
Viele Grüße
Jürgen
Hallo Jürgen,
bei der Installation der 7.0 vor knapp 4 Jahren haben alle Clients anstandlos über PXE Linbo gestartet. Da brauchte ich keinen USB-Stick. Das werde ich aber am Montag auf jeden Fall noch ausprobieren.
Den „Netzwerk-Boot“ dediziert auszuwählen habe ich bereits gemacht. Es ändert jedoch nichts. Es wird hartnäckig das alte Linbo „OFFLINE“ gestartet…
Wenn ich mich recht erinnere, muss man nach der Änderung der start.conf bzw. nach Änderung der LINBO-Gruppen per Schulkonsole müssen die Geräte neu importieren.
Wahrscheinlich hast Du daran gedacht, aber nur zur Sicherheit.
[root@server:/srv/linbo]$ ls -la |grep iso
-rw-rw-rw- 1 root root 443547648 Jan 24 14:44 linbo.iso
Da liegt die ISO-Datei … in der Schulkonsole habe ich (hier v7.2) auch mal danach gesucht … aber da finde ich den Download-Button nicht.
Aber das ist auf jeden Fall eine gute Idee: Wenn PXE nicht will, einfach einen ersten Bootvorgang per USB-Stick erzwingen … ich meine, dass wir den Fall hier schon so ähnlich hatten, dass der nächste Boot-Vorgang dann geklappt hat und das alte LINBO überschrieben hatte … weiß es aber nicht mehr ganz genau.
