The Silent Trap - Ubuntu 24 on Fedora (virt-manager)

While installing Ubuntu 24 as a virtual machine on Fedora using virt-manager, the installer may appear to start normally, only to disappear into silence. The splash screen shows up, the screen goes black, the mouse cursor turns into a black “X”, and then you hear the Ubuntu welcome sound. The system is clearly alive — but nothing is visible, and installation becomes impossible.

Stage One – The Black Screen Illusion

At first glance, this looks like a graphical crash. Many people assume the installer froze, or that Wayland failed, or that the ISO is corrupted. In reality, none of that is true.

The installer is running. Audio works. The system reaches the desktop environment. You are simply not seeing it.

That’s what makes this issue dangerous. It fails silently, without logs or warnings, and it looks far more complex than it really is.

Stage Two - The Real Cause (No, It’s Not Ubuntu)

The problem does not come from Ubuntu 24 itself, nor from Fedora. It comes from a small but critical default choice made by virt-manager.

By default, virt-manager sets the virtual display device to Virtio GPU. Under certain conditions, Ubuntu 24’s graphical installer fails to initialize properly with Virtio during early boot. When this happens, the system continues to load, but the display never renders.

That is why you hear sound but see nothing. The system isn’t broken — the screen is.

Stage Three - Disarming the Trap (Display Fix)

The fix starts with powering off the virtual machine completely. Once the VM is shut down, open its hardware settings in virt-manager and navigate to the display configuration.

Here is the key change: switch the display type from Virtio to QXL.

QXL is far more forgiving during graphical installation phases and tends to behave correctly with Ubuntu installers on Fedora hosts. After applying this change, start the virtual machine again.

In most cases, the installer UI immediately appears, as if nothing was ever wrong.

But sometimes, there is one more trap waiting.

Stage Four – The “No Bootable Disk Found” Ambush

After shutting down the VM to apply the display fix, you may be greeted by a completely different error:
“No bootable disk found.”

This feels confusing and unrelated, but it’s actually another virt-manager quirk.

During shutdowns and hardware changes, virt-manager can leave behind an empty CDROM device. The ISO is silently detached, and the VM is left trying to boot from nothing.

Stage Five - The Ghost CDROM

When you open the VM hardware list, you may notice a CDROM device with no ISO attached. This empty device blocks the boot process and triggers the misleading error.

The fix is simple but easy to overlook.

Remove the empty CDROM device entirely. Then add a new CDROM device and explicitly attach the Ubuntu 24 ISO again.

To avoid any ambiguity during boot, enable the boot menu and make sure the CDROM device is placed at the top of the boot order, followed by the main disk.

Once applied, start the VM again.

This time, the installer boots normally and continues as expected.

Why This Hits Hackers the Hardest

People working in offensive security rely heavily on virtual machines. We spin up labs, test unstable environments, and rebuild systems constantly. When something fails without feedback, it breaks flow and wastes time.

This issue is particularly frustrating because it feels deep and complex, when in reality it’s caused by two small configuration details: a display backend and an empty CDROM entry.

What This Teaches Us

A black screen with sound does not mean a frozen system. Virtio GPU is not always a safe default for graphical installers. QXL remains a reliable fallback when visuals disappear. And when a VM suddenly claims it has no boot device, always check the CDROM configuration first.

These small checks can save hours.

Final Words from BreachRift

Virtualization is supposed to make experimentation painless. But sometimes, the smallest defaults become the sharpest traps.

This wasn’t an Ubuntu bug.
It wasn’t a Fedora issue.
It was a silent installer trap.

If this guide saved you time, frustration, or a full VM rebuild, then it served its purpose.

Break systems — not your workflow.

— BreachRift