Vor einer Woche habe ich hier beschrieben,
wie ein iMac von 2011 nach einigem Ringen mit dem radeon-Treiber, einer
amdgpu-Blacklist und einem denkwürdigen USB-Kabel wieder sauber unter Linux
Mint lief. Voller Beschleunigung, mit regelbarer Helligkeit. Ein gutes Ende.
Diese Geschichte hat kein gutes Ende. Sie hat ein funktionierendes Ende — was nicht dasselbe ist.
Der Abend, an dem es kippte
Ich habe einen Film geschaut. Vollbild. Irgendwann, nach einiger Zeit, wurde der Bildschirm schwarz, und der Rechner nahm keine Eingabe mehr an. Kein Mauszeiger, keine Tastatur, nichts. Hart ausschalten war die einzige Option.
Beim nächsten Start blieb er hängen. Schwarzer Schirm, keine Eingabe, kein SSH. Der iMac war weg.
Der Verdacht, der sich nicht bestätigte
Die naheliegende erste Vermutung: ein Energiespar- oder Screensaver-Vorgang, der das Panel abschaltet und beim Aufwecken nicht sauber zurückkommt.
Also die übliche Rettung: Live-Stick, chroot, ins System. Und dann die
Ausschlussarbeit.
Dateisystem? fsck -f lief sauber durch. Kein einziger Fehler. Das harte
Ausschalten hatte nichts beschädigt.
Power-Management? Ich hatte radeon.dpm=0 in der Vorwoche entfernt, weil
es überflüssig schien. Zeitlicher Zusammenhang mit dem Ausfall — verdächtig.
Also zurückgesetzt. Kontrolle in der grub.cfg: sauber drin, korrekt
gebootet. Ergebnis: keine Änderung. Der Boot hängte weiter. Das
Power-Management war es nicht.
Ein hängender GPU-Zustand? Der Klassiker bei alten Karten: warmer Reboot räumt einen verkorksten GPU-Zustand nicht auf, ein echter Kaltstart schon. Nur: Der Rechner war zu diesem Zeitpunkt bereits 24 Stunden stromlos gewesen, Kabel gezogen. Jede Restspannung längst abgeflossen. Auch das fiel weg.
Die eine gute Beobachtung
Das persistente Journal half diesmal nicht. Der Freeze-Boot brach im Log mitten im normalen Betrieb ab — die letzte Stunde Film war nie auf die Platte geschrieben, der Schreib-Cache beim harten Ausschalten verloren. Der kritische Moment: nicht dokumentiert.
Was wirklich weiterhalf, war eine Beobachtung mit bloßem Auge. Beim Booten laufen erst „große Zeilen" durch — der frühe Textmodus-Framebuffer. Sobald der echte Grafiktreiber das Modesetting übernimmt, schaltet die Auflösung auf nativ, und die Schrift wird kleiner. Diesen Übergang kannte ich vom normalen Betrieb.
Jetzt kamen die kleinen Zeilen nicht mehr. Der Rechner lief hörbar weiter, aber genau am Modeset-Übergang starb die Anzeige.
Damit war der Ort des Problems klar: radeon lädt, übernimmt, und im Moment
des Modesets auf das interne Panel wird es schwarz. Nicht das Dateisystem,
nicht das Power-Management, kein früher Firmware-Hang. Der radeon-Modeset.
Zurück ins System — über einen Kompromiss
Mit nomodeset bootete der iMac wieder sauber durch. Der Preis: radeon
lädt dann gar nicht, also keine Beschleunigung — und keine Helligkeitsregelung,
weil das radeon_bl0-Backlight-Interface ohne den Treiber nicht existiert. Das ist nicht schön. Vor dem 27-Zoll-Bildschirm mit 100% Helligkeit muss man gut Sonnenschutz auftragen. Während man auf den oberen Lüftungsschlitzen seinen Glühwein warm halten kann.
Immerhin: ein nutzbares System, und der Beweis, dass die Installation als
solche völlig intakt ist. Nur der Grafiktreiber-Übergang klemmte.
Der Versuch, radeon im laufenden nomodeset-System von Hand zu laden, um
den Fehler live zu sehen, lief ins Leere:
modprobe: ERROR: could not insert 'radeon': Invalid argument
radeon verlangt KMS und verweigert das Laden, solange nomodeset aktiv ist.
Der eigentliche Fehler ließ sich so nicht einfangen.
Und dann ging es einfach wieder
Diesmal richtig vorbereitet: SSH aktiviert und von einem zweiten Rechner aus getestet, dass die Verbindung wirklich steht — nicht nur „enabled", sondern live eingeloggt. Ein schwarzes Panel sollte mich nicht wieder aussperren.
Dann nomodeset raus, radeon.dpm=0 rein, update-grub, Reboot.
Der iMac fuhr hoch. Bild da. Helligkeit regelbar. radeon geladen.
Alles wieder normal.
Und genau das ist der Punkt, an dem diese Geschichte unbefriedigend wird:
Ich weiß nicht, warum. Ich habe nichts gezielt repariert. Dieselbe Karte,
derselbe Treiber, dieselbe Konfiguration, die vorher schwarz blieb, lief
plötzlich wieder. Zwischen „hängt reproduzierbar" und „läuft" lag kein
erkennbarer Hebel — nur die x-te Wiederholung aus update-grub, initramfs neu
bauen, aus- und einschalten.
Was ich nicht behaupten werde
Ich könnte jetzt eine plausibel klingende Erklärung konstruieren. Ein transienter GPU-Zustand, den die wiederholten Boots doch irgendwann gelöst haben. Eine Nebenwirkung der mehrfach neu generierten initramfs. Irgendein Zustand in der Firmware.
Aber ehrlich ist: Ich kann den Mechanismus nicht benennen. Der 24-Stunden- Kaltstart spricht gegen die transiente Erklärung. Der fehlende Log-Eintrag lässt den Freeze-Moment im Dunkeln. Was den Modeset zum Kippen brachte und was ihn wieder heilte — beides bleibt offen.
Ein reparierter Rechner ohne verstandene Ursache ist kein gelöstes Problem. Es ist ein vertagtes.
Was bleibt
SSH ist jetzt dauerhaft an. Das ist die eigentliche Lehre. Beim ersten Mal hat mich ein schwarzes Panel ausgesperrt, weil dieser Mac kein editierbares GRUB-Menü zeigt und die Rettung nur über den Live-Stick lief. Mit permanentem SSH-Zugang von einem zweiten Rechner ist der nächste Ausfall halb so wild.
Der wahrscheinlichste Auslöser ist entschärft. Falls es doch das Bildschirm-Blanking beim Film war, habe ich ihm die Grundlage entzogen: Bildschirmschoner auf „Nie", und in der Energieverwaltung das automatische Ausschalten des Bildschirms ebenfalls auf „Nie". Keine echte Reparatur — ich weiß ja nicht sicher, ob das die Ursache war — sondern eine Hilfslösung, die den verdächtigsten Übergang gar nicht erst provoziert. Für einen Rechner, an dem man Filme schaut, ohnehin sinnvoll.
Und beim nächsten Mal wird mitgeschnitten. Wenn es wieder passiert — und ich rechne damit, dass es das könnte — dann sofort per SSH rein und das Log live mitlesen:
ssh benutzer@<imac-ip>
journalctl -k -f
Das -f lässt das Kernel-Log mitlaufen. Friert der Rechner ein, stehen die
letzten Zeilen vor dem Absturz auf dem Schirm des anderen Rechners — genau
das, was im persistenten Journal bisher immer fehlte. Dazu vorher ein Video
im Vollbild, um den Verdacht zu reproduzieren: War es die GPU-Last, war es ein
Modeset beim Fullscreen-Wechsel, oder ein Einmal-Ereignis?
Bis dahin läuft der iMac. Mit Bild, mit Beschleunigung, mit Helligkeit. Und mit einem offenen Fragezeichen, das ich mir für den nächsten schwarzen Bildschirm aufhebe.
Manchmal ist die ehrlichste Zwischenbilanz: Es funktioniert wieder, und ich weiß nicht genau, warum. Wer bei alter Hardware bastelt, kennt diesen Zustand. Man nimmt das funktionierende System — und bleibt misstrauisch.