ubuntuusers.de

Janna schrieb:

• Wie verhindere ich, dass 6.8.0-138 durch ein Update aus dem System geschmissen wird?

Vorläufig die Kernelpakete für 6.8.0-138 auf hold setzen, und den Kernelpaketen für 6.8.0-139 für Apt-Pinning in der entsprechenden Datei für das Repository im Verzeichnis:

/etc/apt/preferences.d/

... eine negative Pin-Priority setzen. Beispielsweise -10.

Im Wiki:

• apt/apt-Kommandos (Abschnitt „apt-mark“)

• Apt-Pinning

Aber nicht vergessen das auch schnellstmöglich wieder rückgängig zu machen! Es gibt ja nicht ohne Grund eine Nachfolgeversion von Kernel Version 6.8.0-138. Gewöhnlich geht es da um Sicherheitslücken die geschlossen werden, wenn es eine neuere Ubuntu Kernel Version im alten Release gibt. So bald also eine frische Version angeboten wird, darauf aufspringen.

trollsportverein schrieb:

Es gibt ja nicht ohne Grund eine Nachfolgeversion von Kernel Version 6.8.0-138

...und für 6.8.0-139: 6.8.0-146 (2026-09-07), proposed. Da braucht Canonical immer derart lange, um zu "testen" und aus proposed 'rauszuhieven, trotzdem gibt es immer wieder gravierende Fehler.

Nachfolger für 6.8 ff. auch, nur daß 7.0 upstream schon verdammt lange EoS und 7.2 aktuell ist.

trollsportverein schrieb:

Aber nicht vergessen das auch schnellstmöglich wieder rückgängig zu machen! Es gibt ja nicht ohne Grund eine Nachfolgeversion von Kernel Version 6.8.0-138.

Genau deswegen macht man den Quatsch nicht erst. Sondern testet zu allererst einen aktuelleren Kernel. HWE oder Liquorix wurden hier nicht umsonst angesprochen.

schwarzheit schrieb:

Genau deswegen macht man den Quatsch nicht erst. Sondern testet zu allererst einen aktuelleren Kernel.

ACK, aber sowas von!

Ausserdem ist das UEFI nicht aktuell.

Und noch ein Ansatz - mit memtest den RAM checken.

schwarzheit schrieb:

HWE oder Liquorix wurden hier nicht umsonst angesprochen.

Ich ziehe es vor, den mit der Distribution ausgelieferten Kernel zu nehmen, da diese Kombination am besten getestet sein sollte. Das System muss nicht das alleraktuellste sein, sondern es muss funktionieren. Genau das ging zwar in diesem Falle daneben, aber die genannten Kernel sind genauso wenig gegen solche Fehler gefeit.

schwarzheit schrieb:

Ausserdem ist das UEFI nicht aktuell.

Und noch ein Ansatz - mit memtest den RAM checken.

Was soll das bringen? Die Ursache des Problems ist doch gefunden.

Janna schrieb:

Ich ziehe es vor, den mit der Distribution ausgelieferten Kernel zu nehmen, da diese Kombination am besten getestet sein sollte.

Blödsinn. Ausserdem wäre bei einer Neuinstallation der HWE Kernel installiert worden. Weswegen ich den vorschlug.

Das System muss nicht das alleraktuellste sein, sondern es muss funktionieren.

Und es sollte sicher sein. Was ein veraltetes System nicht ist.

Genau das ging zwar in diesem Falle daneben, aber die genannten Kernel sind genauso wenig gegen solche Fehler gefeit.

Also geht man im Kernel vorwärts aber nicht rückwärts!

Was soll das bringen? Die Ursache des Problems ist doch gefunden.

Siehe oben. Sicherheit und Ausschluss möglicher Hardwareprobs.

Und wenn du der Meinung bist das das Problem identifiziert ist warum hast du den Thread dann nicht als gelöst gekennzeichnet?

Janna schrieb:

Ich ziehe es vor, den mit der Distribution ausgelieferten Kernel zu nehmen, da diese Kombination am besten getestet sein sollte.

Du liest ohne Zeifel hier nie mit, zumindest beim Thema Kernel. Canonical hat seit etlichen Jahren am laufenden Band gravierende Probleme mit ihren Kerneln, weil sie offensichtlich keine QA haben.

Nachtrag:

Die aktualisierte Version 6.8.0-142 löst das Problem nicht. Der Rechner friert weiterhin beim Aufwachen ein.

Damit bleibt es bis auf Weiteres bei Version 6.8.0-138.

Janna, meinst du nicht, dass es Gründe gibt, weshalb Kernel mehr oder weniger regelmäßig durch neuere Versionen ersetzt werden? Wenn du diese selbst nicht erkennen kannst, dann gib in die Suchmaschine deiner Wahl doch mal "Risiken veralteter Linux-Kernelversionen" ein. Finden solltest du dann u.a. das hier.

Daher solltest du evtl. doch mal dem HWE-Kernel eine Chance geben, wenn du schon nicht den Liquorix testen willst.

Aber letztlich ist es ja dein System, dass da womöglich bald gekapert werden wird 😎

NurNochDebianUser schrieb:

... dass da womöglich bald gekapert werden wird 😎

Oder bereits ist. 😉

Macht euch darüber keine Sorgen. Der Rechner ist nicht von außen erreichbar, das ist kein Firmenserver, sondern das ist mein privater Arbeitsplatzrechner in einem sicheren Netzwerk. Solange der Router keine üble Sicherheitslücke hat, der (aktuell gehaltene) Browser nicht von Webseiten kompromittiert werden kann und ich nicht selbst bösartige Software installiere, kann nichts passieren - und im letzten Fall, Installation bösartiger Software, kann ein aktueller Kernel auch nichts mehr retten.

Janna, ist dir klar, das alles durch den Kernel geht? Beispiel an einer alten Kernel-Sicherheitslücke:

• Linux-Rechner übers Internet abschießen ← Link zum Archiv

Würde ich, aus welchen Gründen auch immer, an einer alten Kernelversion festhalten müssen, dann wäre das für mich nur ein temporärer Behelf, der so schnell wie möglich durch eine bessere Lösung ersetzt werden muss. Also einen aktuellen Kernel, so weit das auf dem jeweiligen Release möglich ist. Und da gibt es ja viel Auswahl auf Kubuntu mit Fertigpaketen: Liquorix, XanMod, oder die Mainline Kernel, das sind alles Ausweichmöglichkeiten, wenn der normale Ubuntu Kernel dem Admin nicht gut genug sein mag.

Mal ganz abgesehen davon, dass das aktuelle Kubuntu Release Resolute Raccoon ist, und in rund zweieinhalb Wochen dann Stonking Stingray.

Stonking Stingray wird noch bis mindestens Mitte Januar warten müssen. So eine Updatekatastrophe wie beim Wechsel von 22.04 auf 24.04 kann ich mir während des laufenden Projektes nicht leisten. Vielleicht schafft es Canonical bis dann, den Fehler auch in einem 24er Kernel zu beheben.

Noch ein Nachtrag:

Mit 6.8.0-146 ist der Fehler behoben. Kubuntu wacht wieder auf.

Allerdings gibt es mit der Version einen Hänger (ca. 10s) während des Hochfahrens. Das muss ich noch beobachten, aber das ist ohnehin ein anderes Thema.