Der iMac 27" von Mitte 2011 steht seit Jahren herum. Apple hat ihn längst abgeschrieben, macOS bekommt er keins mehr. Also: Linux Mint drauf. Was folgte, war eine Woche Fehlersuche mit mehreren falschen Fährten, einem Hardware-Defekt-Verdacht, der sich in Luft auflöste, und einer Ursache, auf die niemand kommt.
Die Ausgangslage
iMac12,2, Intel Core i7-2600, dazu zwei GPUs: die integrierte Intel HD 3000 und eine AMD Radeon HD 6970M. Wichtig für alles Weitere, und eine Eigenheit dieser Baureihe: Apple hat das interne Panel nur an die Radeon verdrahtet. Die Intel-GPU treibt den eingebauten Bildschirm nicht an. Wer die Radeon abschaltet, sitzt vor einem dunklen Gerät.
Der Live-USB-Stick bootete nur im Kompatibilitätsmodus, also mit
nomodeset. Die Installation lief durch — und danach: schwarzer Bildschirm.
Ein klassisches Henne-Ei-Problem. Ohne Treiber kein Bild, mit Treiber kein
Bild.
Erste Runde: überhaupt wieder ins System
Das installierte Mint tauchte im Bootpicker gar nicht erst auf. Der Weg
zurück führte über den Live-Stick und chroot:
sudo mount /dev/sda2 /mnt # Mint-Root (ext4)
sudo mount /dev/sda1 /mnt/boot/efi # EFI-Partition (vfat)
sudo mount --bind /dev /mnt/dev
sudo mount --bind /dev/pts /mnt/dev/pts
sudo mount --bind /proc /mnt/proc
sudo mount --bind /sys /mnt/sys
sudo mount --bind /run /mnt/run
sudo chroot /mnt
Die Bind-Mounts sind nicht optional. Ohne /run und /sys kann grub-probe
den Pfad vom Dateisystem zum Blockgerät nicht auflösen und update-grub
bricht ab. Drin dann:
update-grub
grub-install /dev/sda
Danach bootete der Rechner. Mit nomodeset, also im
EFI-Framebuffer-Notbetrieb, ohne Grafikbeschleunigung. Und mit auffälligen
vertikalen blauen Streifen über dem ganzen Bild.
Die Streifen: eine Woche auf der falschen Fährte
Die Streifen waren von der ersten Sekunde an da, schon im Boot-Splash. Meine
Arbeitshypothese: ein Stride-Fehler im efifb. Die Apple-Firmware meldet
eine Zeilenbreite, die nicht zur Panel-Geometrie passt, jede Scanline
verrutscht um denselben Betrag, fertig sind die Bänder. Ein bekannter
Mac-Bug, plausibel, und im nomodeset-Modus kein Widerspruch.
Diese Hypothese war falsch. Dazu am Ende mehr.
Zweite Runde: warum lädt radeon nicht?
inxi -Gxx zeigte das Elend deutlich:
Device-2: AMD Blackcomb [Radeon HD 6970M/6990M] driver: N/A
Display: driver: X: loaded: modesetting unloaded: fbdev,radeon,vesa
API: OpenGL renderer: llvmpipe (LLVM 20.1.2 256 bits)
llvmpipe heißt: Software-Rendering auf der CPU. Die Radeon lag komplett
brach. Der Grund ist strukturell — der radeon-Treiber braucht
Kernel-Mode-Setting, und nomodeset schaltet genau das ab. Beide Symptome,
Streifen und fehlende Beschleunigung, hatten dieselbe Wurzel.
Also nomodeset weg. Ergebnis: schwarzer Bildschirm. Und kein SSH, der
Rechner tauchte nicht mal im Router auf.
Damit stand der Verdacht im Raum, den man bei diesem Modell fürchtet: Die 6970M in den 2011er-iMacs gehört zu einer Baureihe mit einem berüchtigten AMD-GPU-Defekt. Reihenweise Ausfälle. Die Karte läuft im dummen Framebuffer, aber sobald ein echter Treiber sie arbeiten lässt, stirbt sie.
Die Sackgassen
Der Reihe nach ausgeschlossen:
Firmware fehlt? Nein. BARTS_mc/me/pfp/smc und BTC_rlc lagen alle in
/lib/firmware/radeon/.
radeon geblacklistet? Nein. Der Treffer in /etc/modprobe.d/ war
blacklist radeonfb — der uralte Framebuffer-Treiber, auf jedem Ubuntu
standardmäßig geblockt, völlig harmlos. Nicht zu verwechseln mit dem
radeon-KMS-Treiber.
Hardware-Defekt? Die Logs sagten nein. Beim schwarzen Boot lief das
Journal ruhig weiter — EXT4-fs re-mounted r/w, lp: driver loaded. Ein
harter GPU-Lockup hätte das System eingefroren, das Log wäre mittendrin
abgebrochen. Der Boot lief einfach durch. Nur eben ohne Bild.
amdgpu? Und hier wurde es interessant:
amdgpu 0000:01:00.0: probe with driver amdgpu failed with error -22
amdgpu versuchte, die Karte zu übernehmen, und scheiterte mit EINVAL.
Die 6970M ist TeraScale 2 / Northern Islands — eine Generation, die amdgpu
schlicht nicht unterstützt. Der zuständige Treiber ist und bleibt radeon.
Trotzdem war amdgpu geladen (Refcount 0, an nichts gebunden), und radeon
war es nicht.
nomodeset, das dreimal zurückkam
Der eigentliche Zeitfresser war ein Detail, das drei Mal in verschiedenen
Verkleidungen auftrat: Was in /etc/default/grub steht, ist nicht, womit
der Kernel bootet.
cat /proc/cmdline # die Wahrheit
sudo grep 'vmlinuz' /boot/grub/grub.cfg # was GRUB tatsächlich liest
grep CMDLINE /etc/default/grub # nur die Vorlage
Erste Runde: Die Datei war sauber, radeon.dpm=0 stand drin. Die
grub.cfg hatte aber noch nomodeset — weil nach dem Editieren nie ein
update-grub lief. Zweite Runde: dasselbe Spiel nach einem
update-initramfs, das im Hintergrund eine Neugenerierung getriggert hatte.
Wer bei GRUB debuggt, sollte sich angewöhnen, ausschließlich /proc/cmdline
zu glauben. Alles andere ist Absichtserklärung.
Nebenbei: Ein editierbares GRUB-Menü gab es auf diesem Mac nicht. Weder
Shift noch Esc beim Start brachten eines hervor — die Tastatur ist zu
diesem Zeitpunkt schlicht noch nicht aktiv. Das heißt: keine Testläufe pro
Boot, jede Änderung muss über die Datei und update-grub laufen. Und es
macht SSH zur Pflicht, bevor man riskant neu startet.
Die Lösung
Zwei Schritte, und beide sind nötig. Der erste steht in einigen Foren, der zweite nirgends:
1. amdgpu blockieren. Er kann die Karte nicht ansteuern, belegt aber den Probe-Versuch:
echo "blacklist amdgpu" | sudo tee /etc/modprobe.d/blacklist-amdgpu.conf
2. radeon explizit in die initramfs aufnehmen. Ohne diesen Schritt lädt
radeon unter Kernel 6.17 nicht — obwohl das Modul vorhanden ist, die
Firmware daliegt und nichts es blacklistet:
echo radeon | sudo tee -a /etc/initramfs-tools/modules
sudo update-initramfs -u
Gegenprüfen, bevor man rebootet:
lsinitramfs /boot/initrd.img-$(uname -r) | grep -E 'radeon|amdgpu'
Erwartet: radeon.ko.zst und blacklist-amdgpu.conf tauchen auf, amdgpu.ko
nicht. Und /etc/default/grub ohne nomodeset, gefolgt von update-grub
und einer Kontrolle der grub.cfg.
Nach dem Neustart:
$ lsmod | grep radeon
radeon 2179072 15
$ ls /sys/class/backlight/
radeon_bl0
$ cat /sys/class/drm/card0-eDP-1/status
connected
eDP-1 ist das interne Panel, vom echten Treiber erkannt. radeon_bl0 ist
die Hintergrundbeleuchtung. Die Helligkeitstasten funktionieren. Volle
Beschleunigung statt llvmpipe.
radeon.dpm=0 — der Vorsichtsparameter gegen das Power-Management, den ich
lange mitschleppte — stellte sich als überflüssig heraus. Er hat nie etwas
repariert, weil nie etwas kaputt war. Er lief nur zufällig parallel mit.
Und die Streifen?
Das ist die Pointe.
Sie hatten mit Grafiktreibern nichts zu tun. Ich habe irgendwann einen Trackball gegen eine Maus getauscht — und die Streifen waren weg.
Das Trackball-Kabel hat elektromagnetisch in die interne LVDS-Verbindung zwischen Grafikkarte und Panel eingestreut. Im nackten Framebuffer-Modus, ohne die saubere Signalregenerierung eines echten Treibers, schlug das als periodisches Muster durch. Im engen Metallgehäuse eines iMac liegen die rückseitigen USB-Ports und die Panel-Anbindung konstruktiv dicht beieinander.
Softwareseitig war nie etwas kaputt. Kein dmesg der Welt hätte das je
gezeigt. Die halbe Diagnose lief vor einer verfälschten Kulisse.
Was ich mitnehme
Glaube nur /proc/cmdline. Konfigurationsdateien sind Absichten,
Kommandozeilen sind Tatsachen.
Ein Log, das ruhig weiterläuft, ist kein Absturz. Der Unterschied zwischen „Treiber lädt und stirbt" und „Treiber lädt nie" entscheidet über Hardware-Defekt oder Konfigurationsfehler. Er steht in den letzten dreißig Zeilen.
Richte SSH ein, bevor du am Grafiktreiber schraubst. Ein schwarzes Panel sperrt dich sonst aus, besonders ohne GRUB-Menü.
Nicht jedes Symptom ist Software. Wenn alle Logs schweigen, obwohl etwas sichtbar kaputt ist, lohnt der Blick auf das, was am Rechner hängt.
Der iMac läuft jetzt. 2560×1440, beschleunigt, mit regelbarer Helligkeit. Eine Karte, die anfangs als Todeskandidatin galt, ist kerngesund.
Mit KI-Unterstützung erstellt.