Hallo,
habe auf 2.3.40 aktualisiert und keine Probleme mit unterschiedlicher Hardware (Hersteller und Alter). In der start.conf steht kein ‘nomodeset’. Allerdings ist mein Ubuntuclient schon längere Zeit ohne Aktualisierungen, weil ich epoptes gerne noch bis zum 18.04-Client verwenden möchte. Es soll da ja mal nach einem Update des Clients Probleme gegeben haben.
Viele Grüße
Wilfried
Hallo,
Nein, das habe ich nicht gemacht. Ich hatte nicht das Gefühl dass es ein
Grafikkartenproblem war, sondern die Rechner hingen immer beim
Initialisieren der Netzwerkkarte (zumindest blieben die Bootmeldungen an
dieser Stelle stehen…)
Ich bin leider kein Experte, um erklären/erforschen zu können woran das
lag. Bin nur froh dass es wieder läuft…
… insgesammt ist das ein großer Mist: nun macht linbo schon seit 2.3
einen zwangsreboot, damit jedes Betriebsystem einen „frisch gebooteten“
Rechner bekommt, wo linbo noch nichts initialisiert hat, und dann kommt
jetzt bei noch neueren kernels dazu, dass ältere Kernel trotzdem nicht
richtig initialisieren… so ein Mist.
LG
Holger
Hallo,
ja, auch mich erinnert das an die “guten alten” kexec() - Zeiten…Offenbar bleiben “Initialisierungsrückstände” von linbo in diversen flash-Speichern auf dem mainboard zurück (???) - vielleicht findet Thomas einen softwareseitigen “cold reset” dafür - oder müssen wir grub dafür verantwortlich machen ?
Gruß,
Christoph
Hallo Holger,
so hatte ich das auch verstanden, aber irgendwie scheint linbo ja doch die Finger im Spiel zu haben. Wie sonst wäre es zu erklären, dass (ohne eine Änderung am client-Image) das Image nach Linbo-update auf 2.3.40 nicht mehr bootet, und nach Linbo-downgrade auf 2.3.38 sofort wieder anstandslos?
Ich verstehe das nicht, jedenfalls ist es unschön.
LG Alex
Hallo Wilfried,
falls du das Problem mit den verschwundenen Start-Stop-Links nach einem Kernelupgrade meinst: Das kann man vermeiden:
Viele Grüße
Andreas
Welchen Kernel hast du denn jetzt im Ubuntu-Image? 4.4.x oder 4.15.x?
Andreas
Hallo Andreas,
danke für den Hinweis.
Sehe ich das richtig, dass ich unter /etc/init.d zwei Skripte (epoptes und epoptes-client) mit gleichem Inhalt anlege? Inhaltlich muss nichts angepasst werden?
Viele Grüße
Wilfried
Hallo Wilfried,
das siehst du richtig. Du kannst noch die Zeile
Provides: epoptesfür das epoptes-client-Skript anpassen, ansonsten sind keine Änderungen notwendig. Die Skripte sollen ja nur dafür sorgen, dass die Links aus den Verzeichnissen /etc/rc?.d nicht ins Leere zeigen und dann beim Upgrade gelöscht werden.
Viele Grüße
Andreas
Hallo Andreas,
weder noch. Ich bin noch auf Ubuntu 14.04, das läuft jetzt mit 3.13.0-164
LG Alex
Moin!
Ich fass mal zusammen, was man aus meiner Sicht auf dem Xenial-Client tun kann, damit das mit linuxmuster-linbo 2.3.39 klappt:
# apt install r8168-dkms
VG, Thomas
Danke für die Hinweise, Thomas.
Ich finde, dass so lange Ubuntu 16.04 der aktuell unterstütze Default-Cloop ist, sollte dieser Cloop auch ohne zusätzliche Anpassungen am Kernel oder backports zusammen mit Linbo laufen. Gibt es in Linbo die Möglichkeit verschiedene Kernel zu starten? Evtl. sogar konfigurierbar? Ansonsten kann ich das Problem zw. “möglichst viel aktuelle Hardware unterstützen” und “sollte auch mit älteren Kerneln eines Image laufen” verstehen.
vG Stephan
Hallo Stephan,
Man könnte ja auch mal den Client aktualisieren und in ein neues Cloop packen. Die Entwicklung geht halt weiter. Auch ohne Linbo muss ich an Ubuntu-Rechnern manchmal spezielle Kerneloptionen verwenden, damit sie funktionieren.
Wäre sicher möglich. Müsste halt mal jemand implementieren. Die passende Version der e2fsprogs müsste man dann auch jeweils dazu packen.
VG, Thomas
Ich muss das noch einmal rauskramen, denn es ist doch kein Erfolg!
Was ich jetzt schildere kann ich mir überhaupt nicht erklären: Ich dachte ja durch ein neues Image hätte die Sache sich erledigt, leider hat sich ein einziger Client hartnäckig gesträubt (ich verwende nur baugleiche Maschinen!):
Beim Booten meldet er:
Bei der Überprüfung von / wurden schwere Fehler festgestellt
Der Bootvorgang kann dann mit „i“ fortgesetzt werden, der Client startet dann. Ich habe jetzt alles mögliche versucht:
Mein Fazit: Es muss am Linbo liegen! Ich bin mit meinem Latein echt am Ende.
LG Alex (der jetzt erst mal bei 2.3.38-0 bleiben muss)
Hallo Alex,
hast Du schon mal den Netzwerkanschluss getauscht? Solche Fehler sind häufig Fehler die durch defekte Switch-Ports, Steckverbindungen oder Leitungen hervorgerufen werden.
Gruß
Alois
Hallo Alex,
Was ich jetzt schildere kann ich mir überhaupt nicht erklären: Ich
dachte ja durch ein neues Image hätte die Sache sich erledigt, leider
hat sich ein einziger Client hartnäckig gesträubt (ich verwende nur
baugleiche Maschinen!):
wenn nur einer rumzickt, dann liegt es wohl eher nicht an linbo.
Selten hab ich schon von solchen Fällen gehört.
Meist hat es gereicht den Client von USB Stick zu booten und alle
Partitionen zu löschen.
Einmal war eine neue Charge von Rechnern betroffen: da zeigte sich, dass
ein Fehler in der Firmware der SSDs vorhanden war: ein update der
Firmware und alles flutschte wieder.
Es kann aber auch sien, dass bei dem einen Rechner im BIOS eine
Einstellung anders ist.
LG
Holger
Habe ich getauscht gehabt: Kein Erfolg.
LG Alex
Hatte ich auch schon gemacht, ging nicht!
Beachte Punkt 4: Ich habe einen komplett neuen Rechner auch nicht zum Laufen bekommen! Der Rechner um den es geht hat bis zum Upgrade auf 2.3.40 ja klaglos funktioniert! Danach hatte er den Dateisystemfehler. Nach Downgrade auf 2.3.38 ist der Dateisystemfehler weg!
LG Alex
Nur zur Klärung:
Dass es einen „metadata_csum“ Fehler bei Linux-clients (z.B: ubuntu 16.04) mit "normal"alter e2fsck-Software gibt, wurde zwar herausgefunden, aber das hat nicht zwangsläufig damit zu tun, dass Alex seinen Rechner nicht zum Laufen bekommt, evtl. ist da auch ein anderer DAteisystemfehler drin.
Grund, warum ich das sagen will: den metadata_csum Fehler hat man schon bei < linbo 2.3.38, dort (und bei mir auch bei linbo > 2.3.38) habe ich keine Probleme mit dem start.
Also Vorsicht!. Nicht jeder muss sein e2fsck upgraden.
VG, Tobias
Leider nützt das auf meinen HP-Laptops beides nichts. r8168-dkms war bereits installiert, aber möglicherweise passt die installierte Version (8.041.00) nicht zum neuen Kernel (4.15).
Andreas
Für den Kernel 4.15 hat jetzt folgendes das LAN auf unseren HP-Laptops mit Xenial wieder zurückgebracht:
apt purge r8168-dkms
wget http://de.archive.ubuntu.com/ubuntu/pool/universe/r/r8168/r8168-dkms_8.046.00-1_all.deb
dpkg -i r8168-dkms_8.046.00-1_all.debAndreas