Es ist ein wunderschöner Morgen, der frisch gebrühte Kaffee dampft aus meiner schwarzen Tasse, die Sonne scheint, die Vögel zwitschern und ich vergnüge mich mit dem Anblick des brandneuen Gnome-3-Desktops von Debian. Das Glück könnte nicht schöner sein und schon beginne ich mit dem wiederkehrenden Ritual eines Systemupdates.
aptitude update
aptitude safe-upgrade
Keine berauschenden Neuheiten dieses mal, aber es kann auch nicht immer der 08. November sein. Doch was ist das? Zwei libwebkitgtk-Pakete wollen sich nicht per safe-upgrade installieren lassen. Unerschrocken versuche ich es mit einem full-upgrade. Schon erwarte ich, dass irgendein Paket endgültig deinstalliert werden muss, um das Update zu ermöglichen, doch nein, Apt signalisiert nur die zusätzliche Neuinstallation der zwei Pakete. Dann beginnt der Spaß.
Dpkg meldet mir gleich zwei gzip-Lesefehler und aptitude verabschiedet sich danach mit einem "segmentation fault (core dumped)"-Fehler. Die ZSH-Shell macht es kurz und drückt mit einem Emoticon meine momentane Stimmung aus. 🙁
Weitere Versuche die Pakete zu installieren schlagen fehl. Geistesgegenwärtig mache ich noch einen Screenshot für den späteren Debian-Fehlerbericht. Hier wurde ja offensichtlich gemurkst!
Ich versuche Iceweasel zu starten um nach dem Fehler zu recherchieren. Bestimmt gab es noch andere, die das gleiche Schicksal teilten.
Iceweasel startet nicht mehr.
Ich öffne die Gnome-Shell um eine andere Anwendung zu starten. Gnome-Shell stürzt ab. Wieder mit diesem unglücklichen Emote, dass die Gedanken des Gegenüber nicht besser ausdrücken könnte. 🙁 Fortschritt ist wunderbar.
Ich schaue in den Terminal und probiere es mit dmesg.
aptitude[3080]: segfault at 1dcbe0 ip 0828a86e sp bfc33df0 error 4 in aptitude-curses[8048000+3a3000] [ 527.464217] aptitude[3235]: segfault at 77b3255b ip 0828a88a sp bfd5a920 error 4 in aptitude-curses[8048000+3a3000] [ 549.243137] gnome-shell[3243]: segfault at b46c0120 ip b5e948ff sp a7c738b0 error 7 in libglib-2.0.so.0.2800.8[b5e33000+f0000] [ 551.414108] [drm] nouveau 0000:02:00.0: Unexpected pageflip in channel 4. [ 551.431058] [drm] nouveau 0000:02:00.0: PGRAPH - DATA_ERROR INVALID_BITFIELD [ 551.431063] [drm] nouveau 0000:02:00.0: PGRAPH - DATA_ERROR [ 551.431067] [drm] nouveau 0000:02:00.0: PGRAPH - ch 4 (0x0001c70000) subc 5 class 0x8297 mthd 0x1454 data 0x02050185 [ 551.432188] [drm] nouveau 0000:02:00.0: Unexpected pageflip in channel 4.
Mir schwant nichts Gutes und ich beschließe einen Neustart zu machen. Da ich über ein Multiboot-System verfüge, kann ich meine dunklen Vorahnungen sofort überprüfen.
Ich boote in mein leichtgewichtiges Debian-Sid-Spielesystem, doch der Rechner hängt sich nach dem Login direkt auf. Bei Ubuntu, meinem dritten System, ereilt mich das gleiche Schicksal. Womit ich einen neuen Vorteil für ein Multiboot-System gefunden habe. Es kann wunderbar als Indikator für Hardwareprobleme dienen.
An dieser Stelle bin ich mir schon ziemlich sicher, dass es ins Geld gehen könnte. Ich zögere nicht und greife mir die nächst erreichbare Grml Linuxdistribution und starte aus dem Bootmenü der CD das Programm Memtest86. Memtest gehört zu der Sorte von Programmen, von denen man hofft, dass man sie nie benutzen muss, die aber, wenn es darauf ankommt, extrem hilfreich sind.
Ich lasse das Programm 20 Minuten ohne Fehlermeldungen laufen als plötzlich die Anzeige von blau auf rot springt und sich die Fehler beginnen zu summieren. 10000, 20000, 100000....Ich denke, ich bin fündig geworden. Die Warnmeldungen begannen erst in einem Speichersegment > 2GB, weshalb ich die Hoffnung habe, dass der Defekt nur auf einen meiner 2GB RAM Riegel beschränkt ist.
Ich öffne das Gehäuse, stelle fest, dass jetzt genau der richtige Moment für eine Reinigungsaktion ist *hust*, entferne Staub und einen der RAM-Riegel (50/50 Chance), verschraube wieder alles, boote erneut mit der Grml-CD und lasse Memtest86 laufen. Ich scheine das richtige Bauteil erwischt zu haben. Zumindest werden mir nun nur noch 12 Fehler angezeigt. Das ist zwar nicht toll, aber immerhin besser als 100000.
Die Moral von der Geschichte
Genauso wie bei Festplattenproblemen ist nicht immer die Software Ursache allen Übels. In den meisten Fällen warnt Linux durch scheinbar beängstigende Fehler bei einem Hardwaredefekt. Ich habe mal wieder gelernt, dass in PCs von der Stange oft Komponenten verbaut sind, die nicht nur günstig, sondern auch billig sein können. Mit Sicherheit achte ich in Zukunft wieder mehr auf Qualität oder zumindest suche ich mir nur noch Hersteller, die auf ihren RAM eine Garantie von 10 Jahren geben, ein Zeitfenster, was gut zu der anderen Hardware des Haushalts passt. Um schnell herauszufinden, welche Art von Speicher überhaupt im eigenen Rechner verbaut worden ist, eignet sich besonders das Standardwerkzeug dmidecode. Mit dem Befehl dmidecode -t memory lässt sich hier genaueres erfahren.
Ansonsten scheint alles heil geblieben zu sein. Der Core Duo hat jetzt nur noch 2 GB RAM, aber da ich selten an die 1GB-Speichergrenze stoße, spielt es kaum eine Rolle, ob 3 GB frei sind oder nur 1 GB. 😛
Sowas ähnliches hatte ich vor kurzem auch. Der PC meiner Mutter bootete nicht mehr und da sie noch Windows drauf hatte und auch das nicht mehr startete, lag der Verdacht eines Hardewaredefekts nahe. Ich hab allerdings mit einer Live CD versucht zu booten (misslang also schonmal nicht die Festplatte). Das nächste war der Arbeitsspeicher und da fand auch ich den Übeltäter. Naja selbst wenn sie alles gleichzeitig startet, was sie so benutzt waren es nicht mehr als 600 MB Auslastung, also reicht der Rest von 1GB völlig.
Nur mal so als Hinweis:
Bei einem Debian Testing sollte man immer ein aptitude full-upgrade oder apt-get dist-upgrade durchführen.
Sonst wird es unweigerlich irgendwann zu Abhängigkeitsproblemen kommen, da es bei Testing nun mal ständig Änderungen gibt und es wenig sinnvoll ist, diese zu blockieren.
Ein aptitude safe-upgrade bzw. apt-get upgrade ist nur bei stable sinnvoll.
Das Thema scheint dein Steckenpferd zu sein. 🙂 Wie ich bei deinem letzten Kommentar zu aptitude geschrieben habe, bin ich aber anderer Meinung. Insbesondere stimmt es nicht, dass safe-upgrade nur für stable sinnvoll sein soll.
Wie aus der man Seite zu aptitude hervorgeht, ist safe-upgrade zuerst einmal nur der konservativere Weg bei Debian ein Upgrade zu machen. Safe-upgrade ist deshalb safe also sicher, weil es nicht automatisch Pakete deinstalliert, es sei denn sie sind unbenutzt. Wenn wie bei Debian Testing geschehen das Eclipse SDK entfernt wird, hat man mit safe-upgrade noch die Möglichkeit auf das Entfernen zu reagieren, indem Pakete z.B. auf Halt gesetzt werden können.
Ist man sich über die Konsequenzen im Klaren, wird man danach ein full-upgrade machen. Es ist z.B. auch möglich ein full-upgrade nur auf einzelne Pakete anzuwenden. Apt ist hier ziemlich flexibel.
In der Regel hast du natürlich Recht, dass ein full-upgrade zwangsläufig bei Testing und Sid angewendet werden muss. Jeder der diese beiden Versionen benutzt, sollte auch ein gewisses Maß an Erfahrung mit Debian haben. Ich denke nur, dass es für Neueinsteiger in Testing und Sid fatal sein kann, wenn sie lesen, man müsse immer ein full-upgrade machen, ansonsten ginge das System kaputt.
Der richtige Weg ist:
aptitude update
aptitude safe-upgrade
Nachdenken
aptitude full-upgrade
Cheers