Ubuntu firmware update causing black screen on AMD Radeon RX 6800: display dead, but data most likely untouched
Since 11 August 2026, Ubuntu has been distributing the package linux-firmware 20240318.git3b128b60-0ubuntu2.29 via noble-updates. On machines with AMD graphics cards of the Navi 21 class – Radeon RX 6800, RX 6800 XT, RX 6900 XT and RX 6950 XT – this Ubuntu firmware update causes black screens, half-black images and green stripes. A loss of user files has not been documented so far. Access via the graphical interface, however, fails.
And that is exactly where the real risk lies: anyone who mistakes the black screen for a hard drive failure and reinstalls, formats or recreates partitions "just to be safe" overwrites their own data – in the case of an error that never touched that data in the first place.
What exactly happened?
On 12 August 2026, bug report Bug 2163303 was opened in Ubuntu's bug tracker Launchpad. The initial report describes an upgrade of the linux-firmware version from 0ubuntu2.27 to 0ubuntu2.29 at 11:44 p.m. – and immediately afterwards the broken display output. The automatic Launchpad Janitor upgraded the report shortly thereafter:
"Status changed to 'Confirmed' because the bug affects multiple users."
Launchpad Janitor, Bug 2163303 in the Ubuntu tracker
When retrieved on 15 August 2026, Launchpad showed 28 affected people as well as six bug reports marked as duplicates. The bug carries the tag regression-update and is assigned to a Canonical employee.
The technical cause: an outdated DMUB firmware file
At startup, the AMDGPU graphics driver loads what are known as firmware blobs – small program packages that run directly on the graphics card. For Navi 21, the file responsible is sienna_cichlid_dmcub.bin.zst, which supplies the display microcontroller (DMUB, the microcontroller for the display output).
The bug history documents the following: in versions .26 and .27, this file was a symlink – that is, a reference – to beige_goby_dmcub.bin.zst with microcode version 0x02020020. In version .29, there is instead a standalone file with the outdated version 0x01000000. Accordingly, the system logs of affected users contain messages such as "Wait for DMUB auto-load failed: 3" and "DMUB hardware initialized: version=0x01000000".
A user comment in the Launchpad bug sums it up:
"Due to removed symlink in 0ubuntu2.29, DMUB is stale 1.0.0 and breaks display output on Navi 21."
Sebastian, technical comment on Bug 2163303
Remarkably, the official linux-firmware upstream had already reverted this exact change on 3 September 2024 with commit 96af55bd – title: "amdgpu: Revert sienna cichlid dmcub firmware update". The reasoning given by commit author 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
Who and which devices are affected?
- Operating systems: Ubuntu 24.04 LTS (documented up to 24.04.4) and Linux Mint 22.3, which is built on the Ubuntu 24.04 base.
- Problem package: linux-firmware 20240318.git3b128b60-0ubuntu2.29 (in noble-proposed since 13 July 2026, in noble-updates since 11 August 2026).
- Graphics cards: AMD Navi 21 / sienna_cichlid – Radeon RX 6800, Radeon RX 6800 XT, Radeon RX 6900 XT, Radeon RX 6950 XT.
- Kernel: The bug has been reproduced with 6.8.0-137-generic, 6.14 and 7.0.0-28-generic, among others – so it is not tied to a single kernel version.
These are the symptoms affected users report
- Exactly half-screen vertical image corruption or a completely black right or left half of the screen from the graphical login onwards – the mouse pointer may still be displayed correctly.
- Green or coloured vertical stripes and artefacts that can change after a restart.
- Flickering followed by a complete black screen during boot or immediately after login.
- In multi-monitor setups, individual screens remain black.
- In recovery mode or with the boot parameter nomodeset, the display is partly correct.
- Curious, but documented: in one report, a screenshot created via software was completely inconspicuous, even though the physical monitor showed the faulty image.
How to check whether you are affected by the Ubuntu firmware update with black screen
The following steps are purely diagnostic and change nothing about your data:
- Do not reinstall, do not format. First note whether the problem occurred immediately after an update or restart on or after 11 August 2026.
- Identify the graphics card: Is a Radeon RX 6800, RX 6800 XT, RX 6900 XT or RX 6950 XT installed? A look at your purchase documents or at the card itself is enough – the case does not have to be opened if you have the invoice.
- Compare the symptom pattern: half of the screen black, vertically corrupted, green stripes, flickering, complete black screen or no graphical login at all.
- Check the package version read-only: If text access via recovery mode or a text console is possible, the command dpkg -l linux-firmware documented by Canonical lists the installed version. What matters is exactly 20240318.git3b128b60-0ubuntu2.29. This command only reads, it changes nothing.
- Test the access path: If the display appears correctly in recovery mode or with nomodeset, that is an indication of the display error described here – but neither proof nor a repair.
If everything comes together – Navi 21 graphics card, package version .29, matching fault pattern – that is a strong indication. Other causes such as a defective monitor cable, monitor damage or an actual hardware defect can only be ruled out through a genuine inspection of the device.
What you should do now
- Stay calm. None of the sources reviewed report a loss of user files. A black screen proves neither data loss nor a defect of the SSD, hard drive or graphics card.
- Do not trigger any further updates and suspend automatic update attempts for the time being so that the system state does not change any further.
- Do not install anything new – neither drivers nor "repair tools" from the internet.
- Back up important data as soon as safe read access is available – exclusively to a separate external storage medium, never back onto the source drive. If you want to get your backup strategy in order anyway, the backup assistant offers structured guidance.
- Use recovery mode or nomodeset only as a temporary means of access, not as a solution.
- Only have the firmware package downgraded with sufficient Linux experience or professional support. In several reports, installing linux-firmware 20240318.git3b128b60-0ubuntu2.26 (or .27) together with rebuilding the initramfs restored the display output. That is a workaround documented in user reports – not an officially published Canonical repair instruction.
- Take additional warning signs seriously: If I/O errors, unreadable files, unusual drive noises or a storage device that is no longer detected occur, that is a separate suspicion of a storage defect – in that case stop immediately and have it examined.
What you must never do
This section is the most important one. The display error itself destroys no data – the typical rescue attempts, however, very much do.
- No reinstallation of Ubuntu or Linux Mint as a "quick fix". A reinstallation overwrites partitions and files. No source documents it as necessary or effective for fixing this firmware bug.
- Do not format, do not create or modify partitions. That is exactly what turns a harmless display problem into genuine data loss.
- Do not let recovery software write to the same drive. The GNU ddrescue manual explicitly warns that if a device or partition is selected as the destination, the data present there will be overwritten. A rescue image always belongs on a different medium.
- In the case of genuine I/O errors, never "repair" a file system on the original medium. The GNU ddrescue manual puts it unambiguously: "Never try to repair a file system on a drive with I/O errors; you will probably lose even more data." This warning applies to an additional storage device fault – with the pure display bug, no such fault has been demonstrated.
- No unauthorised tinkering with DMUB files, symlinks or dpkg diverts if you cannot reliably judge the consequences. Such workarounds do appear in the bug history, but they are not something for affected users without professional support.
- A package hold is no substitute for a backup – and it can permanently block later security and bug-fix updates if it is forgotten.
In our practice it is almost always the same pattern: it is not the original fault that costs the data, but the well-meant attempt to fix it yourself. The black screen looks like a total loss, so the system is "set up fresh" – and at that very moment photos, projects and accounting records really are gone. Anyone who overwrites nothing keeps all their options.
Why this case belongs in professional hands – and how RESQ helps specifically
At first glance, a black screen after an Ubuntu firmware update is a purely software matter. In practice, however, the situation is confusing for those affected: all they see is that the computer no longer starts. Whether the confirmed DMUB bug is behind it, a defective monitor cable, a dying SSD or a damaged file system cannot be said without an inspection. It is precisely this uncertainty that leads to the wrong decisions.
The professional approach differs from doing it at home in one decisive respect: first a backup is made, then the work begins – and it is done on a copy, not on the original. Before anything on the system is changed, a package downgraded or an initramfs rebuilt, a backup of the data is created on a separate target. Even if a repair attempt subsequently fails, the data is not at risk as a result. At home, by contrast, it happens regularly that people experiment on their one and only copy of the data.
On top of that comes the assessment of the fault pattern. We know regressions caused by firmware and package updates, we know the log patterns that allow a display error to be distinguished from a genuine storage defect – for example the documented messages around DMUB initialisation as opposed to actual I/O errors in the kernel log. If it turns out that a drive is damaged as well, that is a completely different case: then the procedures of professional data recovery at RESQ apply, including work under cleanroom conditions and with suitable spare parts in the case of mechanically damaged hard drives. Cases involving hard drive data recovery and server and NAS environments with RAID and NAS data recovery each follow their own procedures.
If, on the other hand, the inspection shows that only the graphics path is really affected and the data is intact, the outcome is a targeted repair of the system – without a reinstallation. That, too, is part of our range of services, see repair at RESQ.
How things work at RESQ
- Free initial assessment: You describe the case to us – device, graphics card, time of the update, fault pattern. We tell you how we assess the situation and which steps make sense. The way to do this is the free cost estimate or initial assessment.
- Analysis in the lab: We check whether the storage device and file system are intact and whether the fault pattern matches the documented firmware problem.
- An honest statement about the prospects: Data recovery is always a case-by-case assessment. We do not promise a result; we tell you openly what is possible and what is not.
- Cost estimate: You receive a concrete breakdown before any work is done.
- Your decision: Only then do you decide whether we go ahead. If you would like to place an order directly, you can create an order via your customer account.
The core message is simple: anyone who wants to be sure that their data is not lost through DIY attempts has the case examined instead of experimenting on their only copy of the data.
Is there an official fix yet?
At the time of research on 15 August 2026, no subsequent Noble package version with a documented fix for Bug 2163303 was visible in the official Ubuntu changelog. The bug status was still "Confirmed", and processing is assigned to a Canonical employee. No separate public statement from Canonical or AMD on this bug is available in the sources reviewed; nor is there any CVE or official agency advisory. What is documented is the Confirmed status, the assignment and the official upstream revert commit from 2024.
Documented interim solutions from affected users' reports are the targeted downgrade to linux-firmware 20240318.git3b128b60-0ubuntu2.26 with a subsequent rebuild of the initramfs, as well as – only for knowledgeable users – restoring the correct DMUB symlink or installing a current upstream firmware blob. As soon as an officially corrected package version is released, any package hold that has been set should be properly removed again by someone competent, so that future security updates are not missed.
Conclusion
The black screen after the Ubuntu firmware update on AMD Radeon RX 6800, RX 6800 XT, RX 6900 XT and RX 6950 XT is a confirmed bug in the package linux-firmware 20240318.git3b128b60-0ubuntu2.29 – 28 affected users are registered in the Ubuntu tracker, plus six duplicate reports. According to everything that is documented, your files are not damaged by it. The situation only becomes dangerous through hasty countermeasures: reinstallation, formatting, partition changes or recovery software that writes to your own source drive.
If you are unsure whether the firmware bug or in fact a defect of the storage device is behind your black screen: change nothing further and have the case examined. Request the free initial assessment with cost estimate now – you will find out how your chances stand before you have to make a decision.
