Kernel 3.2.0-4-amd64

[guenterq]

Hallo und Mahlzeit

wenn man hier im Forum nach dem Stichwort friert such läßt, bekommt man viele Nachrichten zu lesen, in denen es um das einfrieren von Wheezy mit dem Kernel 3.2.0.4 geht.

Mir geht es auch so, zwar weniger häufig, 1-2 mal die Woche, aber es geschieht nun mal. Irgendwo erstaunt mich das, da ich seit 2008 mit Linux-Distries auf meinem Rechner arbeite und ich somit schon eine Reihe von Kernel kommen und gehen gesehen habe. Bei keinem dieser Kernel ist mir aber das System eingefroren.

Nun habe ich zum ersten mal ein Debian auf meinem Rechner, bei dem es sich auch noch um die Stable-Variante handelt, und ausgerechnet hiermit kommt es zu Problemen. Ich suche den Fehler zwar immer noch ausserhalb vom Kernel, meistens sitzt der ja auch vor dem Monitor, aber hier im Forum verdichten sich schon die Hinweise, das der Kernel eine Rolle spielt.

Jetzt zu meiner Frage:
Wenn es wirklich der Kernel ist, bleibt dieser bei Wheezy dennoch bis zur nächsten Stable unverändert? Muss man wirklich auf einen Kernel aus unstable oder experimentel ausweichen?

Schönen Tag noch.....

[catdog2]

Wenn es wirklich der Kernel ist, bleibt dieser bei Wheezy dennoch bis zur nächsten Stable unverändert? Muss man wirklich auf einen Kernel aus unstable oder experimentel ausweichen?

Es wird idr neue kernel in den Backports geben. Solltest du dem Grund für das einfrieren näher kommen könnte auch ein Bugreport helfen.

[TBT]

So was hatte mein Rechner auch, bis ich dem Board mal ein neues Bios spendiert habe

Das Board konnte laut den Notes zum Bios mit dem i7 im Auslieferungszustand nicht
richtig umgehen, was dann mit der nächsten Biosversion behoben wurde.

[guenterq]

So was hatte mein Rechner auch, bis ich dem Board mal ein neues Bios spendiert habe

Ich denke nicht, das es am Bios liegt. Auf dem betroffenen Rechner sind vier OS, davon drei "Linuxe" installiert. Die Linuxe laufen jeweils auf einen 3.2er , 3.5er oder 3.8er Kernel. Das OS mit dem 3.2er Kernel friert mir ein, wenn auch selten. So wie dies auch bei anderen Benutzern der Fall ist.

Welchen Kernel kann man denn über die Backports installieren. Ich wollte mal in den Paketlisten nachsehen, aber hierzu gibt es nur Listen für stable, unstable, testing und experimental.

[rendegast]

Vielleicht helfen auch
amd64-microcode / intel-microcode/iucode-tool
dafür sollte Modul cpuid in der initrd geladen sein, /etc/initramfs-tools/modules.

Kernel 3.9 oder 3.10 sollte wohl bald in den backports sein.

Gegenwärtig lassen sich bei einem 64bit-System die kernel-headers des sid-kernels 3.9 nicht unter wheezy nutzen.
Die kernel-headers 3.10 sind (noch) unvollständig, eventuell aber dann auch nicht verwendbar.

Aus den (vanilla)Sourcen ließen sich per 'make deb-pkg' passende Pakete bauen.

[orcape]

Hi guenterq,

Du hast es zwar nicht geschrieben oder ich habe es überlesen, Du hast aber wohl einen Rechner mit Intel i(x) Prozessor.
Ich hatte vor einem halben Jahr mit einem Intel i7 das gleiche Problem mit dem 3.2.0-4amd64 Kernel unter Testing (Wheezy).
Abhilfe schaffte eine Installation eines 3.7 trunk Kernel aus experimental.
Läuft bis jetzt problemlos, jetzt weiter unter Testing (Jessie).

Gruß orcape

[Cae]

Welchen Kernel kann man denn über die Backports installieren. Ich wollte mal in den Paketlisten nachsehen, aber hierzu gibt es nur Listen für stable, unstable, testing und experimental.

Genau, es gibt noch keinen Kernel in wheezy-backports [1]. Vermutlich wird es die ein paar Wochen, nachdem in Jessie ein neuerer Kernel eingezogen ist, geben, als 3.8er. Wann das der Fall ist, kann ich nicht unbedingt abschaetzen.

Gruss Cae

[1] http://packages.debian.org/search?suite ... nux-image-

[Feuerstein]

@guenterq: "Critical Linux vulnerability imperils users, even after “silent” fix" , dies betrifft deinen Kernel auch.
http://arstechnica.com/security/2013/05 ... ilent-fix/

Abhilfe schafft diese Info:
http://www.debian.org/security/2013/dsa-2669

Also kurzum: Ja ich würde auf alle Fälle den Kernel upgaden.

LG
F.

[smutbert]

Ich habe es ähnlich wie orcape gemacht, nur dass ich bei kernel 3.9-rc8 aus siduction gelandet bin. Das einzige Paket, das außer linux-image noch notwendig ist, ist eine neuere initramfs-tools Version. Beides hat sich ohne das geringste Probleme in das wheezy System eingefügt.

Nur wenn man zusätzliche Kernelmodule benötigt zB proprietäre Grafikkartentreiber oder die Virtualbox Module über dkms, braucht man auch noch die Header und kann sich nicht sicher sein, dass die Version der Module in Wheezy für den neueren Kernel kompiliert werden kann.
Das war für mich kein Nachteil, weil ich 3rd party Module sowieso (bis jetzt erfolgreich) zu vermeiden versuche.

[guenterq]

Herzlichen Dank für die Antworten zu meiner Anfrage.

Ich habe mir aus unstable den 3.9er Kernel installiert und werde das Ganze jetzt mal beobachten und berichten.

Beste Grüße aus dem Dürener Land!!

[Milbret]

Alternativ empfehle ich auch mal selbst Kernel zu kompilieren von kernel.org
Hab hier Wheezy mit einem 3.9.5 am laufen und schon 3.9.6 erstellt sowie auch den Long Termin Kernel 3.4.49

Kann dir die Long Term Kernel auch am meisten empfehlen.
In der Regel laufen die ganz gut.
Vor einigen Monaten hat man dort auch die Update Strategie gewechselt.
So erhalten auch Long Term Kernel neue Funktionen, was auch zukünftig Kernel Probleme mit neuer Hardware zu lösen.

Würde sowas auch mehr empfehlen als einen Kernel aus Experimental oder Unstable.

Martin

[guenterq]

@Milbret

interessante Info. Danke, schaue ich mir an.

bg
Günter

[guenterq]

Code: Alles auswählen

Ich habe mir aus unstable den 3.9er Kernel installiert und werde das Ganze jetzt mal beobachten und berichten.

Leider hat der 3.9er Kernel nichts gebracht. Nach zwei Tagen Betrieb fror mir das System gerade eben aus heiterem Himmel wieder ein. Dieses mal konnte ich noch mit alt+F1 ins Terminal wechseln, mich als root anmelden um den Rechner geordnet herunter und wieder hoch zufahren.

[guenterq]

....was mich zu folgender Frage bringt.

Wenn das System einfriert, ich auf die Systemzeit schaue, kann ich mit dieser Zeit nicht in einer bestimmten Logdatei nach den Ursachen des Freezes nachschauen?

[smutbert]

Natürlich geht das, allerdings steht nicht in allen Logdateien die normale Uhrzeit.

[…]Dieses mal konnte ich noch mit alt+F1 ins Terminal wechseln, mich als root anmelden um den Rechner geordnet herunter und wieder hoch zufahren.

Dann ist das System nicht richtig eingefroren, höchstens X oder auch nur die gnome-shell. Von der Konsole kannst du mit

Code: Alles auswählen

service gdm3 restart

den Login Manager neu starten und dich einfach neu anmelden - ein Neustart ist nicht notwendig.
Einige der interessanteren Logdateien sind

- die Ausgabe von dmesg bzw. /var/log/dmesg(.?)
- /var/log/Xorg.0.log bzw. nach dem nächsten Start von X /var/log/Xorg.0.log.old
- ~/.xsession-errors bzw. nach der nächsten (grafischen) Anmeldung ~/.xsession-errors.old

Wenn du gleich nach dem Einfrieren auf der Konsole nach der Ursache suchst, findest du sie mit etwas Glück in einer der letzten Zeilen in einer der Logdateien.

[debianix]

Hm... aus dem Grund das Gnome häufig abgeschmiert ist (nicht nur unter Debian) habe ich XFCE installiert. Mein Notebook mit Intel i7 läuft seitdem stabil ohne jegliche abstürze etc...

Ach > und die xfce-goodies nicht vergessen

[guenterq]

Gnome3 halte ich aber für den zeitgemäßeren Desktop. Er fühlt sich einfach moderner an, als die Desktops aus dem letzten Jahrzehnt. Und vieles was unter Gnome3 angeblich nicht gehen soll, wie z.B. einen Starter auf dem Desktop anlegen, geht sehr wohl.

Mich stört dieser Bug in Gnome3 nicht mehr, weil ich meinen Rechner nicht mehr komplett runterfahre, sondern nur noch per suspend to disk in den Ruhezustand versetze, wobei dieser Fehler nicht mehr in Erscheinung tritt.

Ich hoffe dennoch, das dieser Fehler in Gnome 3.10 behoben wird.