Ubuntu-Firmwareupdate mit Black Screen auf AMD Radeon RX 6800

Ubuntu-Firmwareupdate mit Black Screen auf AMD Radeon RX 6800: Bildschirm schwarz, Daten aber vermutlich unversehrt

Seit dem 11. August 2026 verteilt Ubuntu das Paket linux-firmware 20240318.git3b128b60-0ubuntu2.29 über noble-updates. Auf Rechnern mit AMD-Grafikkarten der Navi-21-Klasse – Radeon RX 6800, RX 6800 XT, RX 6900 XT und RX 6950 XT – führt dieses Ubuntu-Firmwareupdate zu Black Screens, halbseitig schwarzen Bildern und grünen Streifen. Ein Verlust von Benutzerdateien ist bislang nicht dokumentiert. Der Zugriff über die grafische Oberfläche fällt aber aus.

Genau darin liegt das eigentliche Risiko: Wer den schwarzen Bildschirm für einen Festplattendefekt hält und „zur Sicherheit“ neu installiert, formatiert oder Partitionen neu anlegt, überschreibt seine Daten selbst – bei einem Fehler, der die Daten überhaupt nicht angerührt hat.

Was genau ist passiert?

Am 12. August 2026 wurde im Ubuntu-Bugtracker Launchpad der Fehlerbericht Bug 2163303 eröffnet. Der Erstbericht beschreibt ein Upgrade von linux-firmware-Version 0ubuntu2.27 auf 0ubuntu2.29 um 23:44 Uhr – und unmittelbar danach die defekte Bildausgabe. Der automatische Launchpad-Janitor stufte den Bericht kurz darauf hoch:

„Status changed to 'Confirmed' because the bug affects multiple users.“
Launchpad Janitor, Bug 2163303 im Ubuntu-Tracker

Beim Abruf am 15. August 2026 zeigte Launchpad 28 betroffene Personen sowie sechs als Duplikat zugeordnete Fehlerberichte. Der Bug trägt das Tag regression-update und ist einem Canonical-Mitarbeiter zugewiesen.

Die technische Ursache: eine veraltete DMUB-Firmwaredatei

Beim Start lädt der Grafiktreiber AMDGPU sogenannte Firmware-Blobs – kleine Programmpakete, die direkt auf der Grafikkarte laufen. Für Navi 21 ist dabei die Datei sienna_cichlid_dmcub.bin.zst zuständig, die den Display-Microcontroller (DMUB, der Mikrocontroller für die Bildausgabe) versorgt.

Im Bugverlauf wird dokumentiert: In den Versionen .26 und .27 war diese Datei ein Symlink – also ein Verweis – auf beige_goby_dmcub.bin.zst mit der Microcode-Version 0x02020020. In Version .29 liegt dort stattdessen eine eigenständige Datei mit der veralteten Version 0x01000000. In den Systemprotokollen Betroffener finden sich entsprechend Meldungen wie „Wait for DMUB auto-load failed: 3“ und „DMUB hardware initialized: version=0x01000000“.

Ein Nutzerbeitrag im Launchpad-Bug bringt es auf den Punkt:

„Due to removed symlink in 0ubuntu2.29, DMUB is stale 1.0.0 and breaks display output on Navi 21.“
Sebastian, technischer Beitrag zu Bug 2163303

Bemerkenswert: Der offizielle linux-firmware-Upstream hatte exakt diese Änderung bereits am 3. September 2024 mit dem Commit 96af55bd zurückgenommen – Titel: „amdgpu: Revert sienna cichlid dmcub firmware update“. Die Begründung des Commit-Autors Mario Limonciello:

„changed ucode version from 0x2020020 to 0x1000000 and has caused regressions for users with a crash on boot. Revert this binary to previous version.“
Upstream-Commit 96af55bd

Wer und welche Geräte sind betroffen?

• Betriebssysteme: Ubuntu 24.04 LTS (dokumentiert bis 24.04.4) und Linux Mint 22.3, das auf der Ubuntu-24.04-Basis aufsetzt.
• Problempaket: linux-firmware 20240318.git3b128b60-0ubuntu2.29 (seit 13. Juli 2026 in noble-proposed, seit 11. August 2026 in noble-updates).
• Grafikkarten: AMD Navi 21 / sienna_cichlid – Radeon RX 6800, Radeon RX 6800 XT, Radeon RX 6900 XT, Radeon RX 6950 XT.
• Kernel: Der Fehler wurde unter anderem mit 6.8.0-137-generic, 6.14 und 7.0.0-28-generic reproduziert – er hängt also nicht an einer einzelnen Kernelversion.

Diese Symptome berichten Betroffene

• Eine exakt halbseitige vertikale Bildkorruption oder eine komplett schwarze rechte bzw. linke Bildschirmhälfte ab der grafischen Anmeldung – der Mauszeiger kann dabei weiterhin korrekt sichtbar sein.
• Grüne oder farbige vertikale Streifen und Artefakte, die sich nach einem Neustart verändern können.
• Flackern und anschließend ein vollständiger Black Screen beim Booten oder direkt nach der Anmeldung.
• Bei Mehrmonitor-Betrieb bleiben einzelne Bildschirme schwarz.
• Im Recovery-Modus oder mit dem Startparameter nomodeset ist die Darstellung teils korrekt.
• Kurios, aber dokumentiert: In einem Bericht war ein per Software erzeugtes Bildschirmfoto völlig unauffällig, obwohl der physische Monitor das Fehlerbild zeigte.

So prüfen Sie, ob Sie vom Ubuntu-Firmwareupdate mit Black Screen betroffen sind

Die folgenden Schritte sind rein prüfend und verändern nichts an Ihren Daten:

1. Nicht neu installieren, nicht formatieren. Halten Sie zuerst fest, ob das Problem unmittelbar nach einem Update bzw. Neustart am oder nach dem 11. August 2026 auftrat.
2. Grafikkarte identifizieren: Ist eine Radeon RX 6800, RX 6800 XT, RX 6900 XT oder RX 6950 XT verbaut? Ein Blick in Kaufunterlagen oder auf die Karte selbst genügt – das Gehäuse muss dafür nicht geöffnet werden, wenn die Rechnung vorliegt.
3. Symptommuster abgleichen: halbseitig schwarz, vertikal verfälscht, grüne Streifen, Flackern, kompletter Black Screen oder ausbleibende grafische Anmeldung.
4. Paketversion nur lesend prüfen: Wenn ein Textzugang über Recovery-Modus oder eine Textkonsole möglich ist, listet der von Canonical dokumentierte Befehl dpkg -l linux-firmware die installierte Version auf. Relevant ist exakt 20240318.git3b128b60-0ubuntu2.29. Dieser Befehl liest nur aus, er ändert nichts.
5. Zugangsweg testen: Erscheint die Anzeige im Recovery-Modus oder mit nomodeset korrekt, ist das ein Hinweis auf den beschriebenen Anzeigefehler – aber kein Beweis und keine Reparatur.

Trifft alles zusammen – Navi-21-Grafikkarte, Paketversion .29, passendes Fehlerbild –, ist das ein starkes Indiz. Ausschließen lassen sich andere Ursachen wie ein defektes Monitorkabel, ein Monitorschaden oder ein tatsächlicher Hardwaredefekt nur durch eine echte Prüfung des Geräts.

Das sollten Sie jetzt tun

1. Ruhe bewahren. In den geprüften Quellen ist kein Verlust von Benutzerdateien berichtet. Ein schwarzer Bildschirm beweist weder Datenverlust noch einen Defekt von SSD, Festplatte oder Grafikkarte.
2. Keine weiteren Updates anstoßen und automatische Update-Versuche vorerst unterbrechen, damit sich der Systemzustand nicht weiter verändert.
3. Nichts Neues installieren – weder Treiber noch „Reparaturtools“ aus dem Netz.
4. Wichtige Daten sichern, sobald ein sicherer Lesezugriff besteht – ausschließlich auf einen separaten externen Datenträger, niemals zurück auf das Quelllaufwerk. Wer seine Sicherungsstrategie ohnehin ordnen will, findet im Backup-Assistenten eine strukturierte Hilfe.
5. Recovery-Modus oder nomodeset nur als vorübergehenden Zugangsweg nutzen, nicht als Lösung.
6. Eine Rückstufung des Firmwarepakets nur mit ausreichender Linux-Erfahrung oder fachlicher Begleitung durchführen lassen. In mehreren Berichten stellte die Installation von linux-firmware 20240318.git3b128b60-0ubuntu2.26 (oder .27) samt Neubau des initramfs die Bildausgabe wieder her. Das ist ein in Nutzerberichten belegter Workaround – keine offiziell veröffentlichte Canonical-Reparaturanweisung.
7. Zusätzliche Warnzeichen ernst nehmen: Treten I/O-Fehler, nicht lesbare Dateien, ungewöhnliche Laufwerksgeräusche oder ein nicht mehr erkannter Datenträger auf, ist das ein eigenständiger Verdacht auf einen Speicherdefekt – dann sofort stoppen und prüfen lassen.

Das dürfen Sie auf keinen Fall tun

Dieser Abschnitt ist der wichtigste. Der Anzeigefehler selbst zerstört keine Daten – die typischen Rettungsversuche dagegen sehr wohl.

• Keine Neuinstallation von Ubuntu oder Linux Mint als „Schnelllösung“. Eine Neuinstallation überschreibt Partitionen und Dateien. Für die Behebung dieses Firmwarefehlers ist sie in keiner Quelle belegt oder erforderlich.
• Nicht formatieren, keine Partitionen neu anlegen oder verändern. Genau das macht aus einem harmlosen Bildschirmproblem einen echten Datenverlust.
• Keine Wiederherstellungssoftware auf dasselbe Laufwerk schreiben lassen. Das GNU-ddrescue-Handbuch warnt ausdrücklich, dass beim Wählen eines Geräts oder einer Partition als Ziel die dort vorhandenen Daten überschrieben werden. Ein Rettungs-Image gehört immer auf ein anderes Medium.
• Bei echten I/O-Fehlern niemals ein Dateisystem auf dem Originalmedium „reparieren“. Das GNU-ddrescue-Handbuch formuliert es unmissverständlich: „Never try to repair a file system on a drive with I/O errors; you will probably lose even more data.“ Diese Warnung gilt für einen zusätzlichen Datenträgerfehler – beim reinen Anzeigebug ist ein solcher nicht nachgewiesen.
• Keine eigenmächtigen Eingriffe an DMUB-Dateien, Symlinks oder dpkg-diverts, wenn Sie deren Folgen nicht sicher beurteilen können. Solche Workarounds stehen zwar im Bugverlauf, sind aber nichts für Betroffene ohne fachliche Begleitung.
• Ein Paket-Hold ersetzt keine Datensicherung – und kann spätere Sicherheits- und Fehlerkorrekturupdates dauerhaft blockieren, wenn er vergessen wird.

In unserer Praxis ist es fast immer dasselbe Muster: Nicht der ursprüngliche Fehler kostet die Daten, sondern der gut gemeinte Versuch, ihn selbst zu beheben. Der schwarze Bildschirm wirkt wie ein Totalschaden, also wird das System „frisch aufgesetzt“ – und in diesem Moment sind Fotos, Projekte und Buchhaltung tatsächlich weg. Wer nichts überschreibt, behält alle Optionen.

Warum dieser Fall in Profihände gehört – und wie RESQ konkret hilft

Auf den ersten Blick ist ein Black Screen nach einem Ubuntu-Firmwareupdate ein reines Software-Thema. In der Praxis ist die Lage für Betroffene aber unübersichtlich: Sie sehen nur, dass der Rechner nicht mehr startet. Ob dahinter der bestätigte DMUB-Fehler steckt, ein defektes Monitorkabel, eine sterbende SSD oder ein beschädigtes Dateisystem, lässt sich ohne Prüfung nicht sagen. Genau diese Unsicherheit ist der Punkt, an dem falsche Entscheidungen fallen.

Der professionelle Weg unterscheidet sich in einem entscheidenden Punkt vom Vorgehen zu Hause: Es wird zuerst gesichert und dann gearbeitet – und zwar an einer Kopie, nicht am Original. Bevor irgendetwas am System verändert, ein Paket zurückgestuft oder ein initramfs neu gebaut wird, entsteht eine Sicherung des Datenbestands auf ein getrenntes Ziel. Selbst wenn ein Reparaturversuch anschließend fehlschlägt, sind die Daten dadurch nicht in Gefahr. Zu Hause passiert es dagegen regelmäßig, dass man am einzigen Datenbestand experimentiert.

Dazu kommt die Einordnung des Fehlerbildes. Wir kennen Regressionen durch Firmware- und Paketupdates, wir kennen die Logmuster, mit denen sich ein Anzeigefehler von einem echten Speicherdefekt unterscheiden lässt – etwa die dokumentierten Meldungen rund um die DMUB-Initialisierung gegenüber tatsächlichen I/O-Fehlern im Kernelprotokoll. Stellt sich dabei heraus, dass zusätzlich ein Laufwerk beschädigt ist, ist das ein völlig anderer Fall: Dann greifen die Verfahren der professionellen Datenrettung bei RESQ, bei mechanisch beschädigten Festplatten inklusive Arbeit unter Reinraumbedingungen und mit passenden Ersatzteilen. Für Fälle rund um Datenrettung von Festplatten und für Server- und NAS-Umgebungen mit RAID- und NAS-Datenrettung gelten jeweils eigene Vorgehensweisen.

Zeigt die Prüfung dagegen, dass wirklich nur der Grafikpfad betroffen ist und die Daten unversehrt sind, ist das Ergebnis eine gezielte Instandsetzung des Systems – ohne Neuinstallation. Auch das gehört zu unserem Leistungsspektrum, siehe Reparatur bei RESQ.

So läuft es bei RESQ ab

1. Kostenlose Ersteinschätzung: Sie schildern uns den Fall – Gerät, Grafikkarte, Zeitpunkt des Updates, Fehlerbild. Wir sagen Ihnen, wie wir die Lage einschätzen und welche Schritte sinnvoll sind. Der Weg dafür ist der kostenlose Kostenvoranschlag beziehungsweise die Ersteinschätzung.
2. Analyse im Labor: Wir prüfen, ob Datenträger und Dateisystem intakt sind und ob das Fehlerbild zum dokumentierten Firmwareproblem passt.
3. Ehrliche Aussage zu den Aussichten: Datenrettung ist immer eine Einzelfallprüfung. Wir versprechen kein Ergebnis, sondern sagen Ihnen offen, was möglich ist und was nicht.
4. Kostenvoranschlag: Sie erhalten eine konkrete Aufstellung, bevor gearbeitet wird.
5. Ihre Entscheidung: Erst danach entscheiden Sie, ob wir tätig werden. Wenn Sie direkt beauftragen möchten, können Sie über Ihr Kundenkonto einen Auftrag anlegen.

Die Kernbotschaft ist einfach: Wer sichergehen will, dass seine Daten nicht durch Selbstversuche verloren gehen, lässt den Fall prüfen, statt am einzigen Datenbestand zu experimentieren.

Gibt es schon einen offiziellen Fix?

Zum Recherchezeitpunkt am 15. August 2026 war im offiziellen Ubuntu-Changelog keine nachfolgende Noble-Paketversion mit einem dokumentierten Fix für Bug 2163303 sichtbar. Der Bugstatus lautete weiterhin „Confirmed“, die Bearbeitung ist einem Canonical-Mitarbeiter zugewiesen. Eine gesonderte öffentliche Stellungnahme von Canonical oder AMD zu diesem Bug liegt in den geprüften Quellen nicht vor; ebenso wenig eine CVE- oder Behördenmeldung. Belegt sind der Confirmed-Status, die Zuweisung und das offizielle Upstream-Revert-Commit von 2024.

Dokumentierte Übergangslösungen aus Betroffenenberichten sind die gezielte Rückstufung auf linux-firmware 20240318.git3b128b60-0ubuntu2.26 mit anschließendem Neubau des initramfs sowie – nur für fachkundige Anwender – die Wiederherstellung des korrekten DMUB-Symlinks beziehungsweise das Einspielen eines aktuellen Upstream-Firmwareblobs. Sobald eine offiziell korrigierte Paketversion erscheinen wird, sollte ein eventuell gesetzter Paket-Hold fachkundig wieder aufgehoben werden, damit künftige Sicherheitsupdates nicht ausbleiben.

Fazit

Der Black Screen nach dem Ubuntu-Firmwareupdate auf AMD Radeon RX 6800, RX 6800 XT, RX 6900 XT und RX 6950 XT ist ein bestätigter Fehler des Pakets linux-firmware 20240318.git3b128b60-0ubuntu2.29 – 28 Betroffene sind im Ubuntu-Tracker registriert, sechs Duplikatmeldungen kommen hinzu. Nach allem, was dokumentiert ist, sind Ihre Dateien dabei nicht beschädigt. Gefährlich wird die Situation erst durch übereilte Gegenmaßnahmen: Neuinstallation, Formatieren, Partitionsänderungen oder Wiederherstellungssoftware, die auf das eigene Quelllaufwerk schreibt.

Wenn Sie unsicher sind, ob hinter Ihrem schwarzen Bildschirm der Firmwarefehler oder doch ein Defekt des Datenträgers steckt: Verändern Sie nichts weiter und lassen Sie den Fall prüfen. Fordern Sie jetzt die kostenlose Ersteinschätzung mit Kostenvoranschlag an – Sie erfahren, wie Ihre Chancen stehen, bevor Sie eine Entscheidung treffen müssen.