The USB Port Was the Problem

I was trying to boot Bazzite from a live USB. It should have been simple. Instead, it turned into one of those hardware failures that keeps changing masks: first Secure Boot, then the GPU, then RAM, then what looked exactly like counterfeit flash storage.

The problem was not the ISO. It was not the USB drive. It was not the GPU or the memory either. The evidence pointed back to the USB path itself: on my MSI PRO Z890-A WiFi, the port group I had been using was behind a Genesys Logic GL3523 USB hub controller. Moving the exact same flash drive to a chipset-direct rear port fixed the boot immediately.

This is an account of what I observed on one system, not a claim that every GL3523-equipped board is defective. The important part is the pattern: if the media fails in a way that moves around from boot to boot, but the physical port stays the same, the port/controller path deserves to be on the list.

What it looked like

The sequence was messy enough that each new symptom made a different explanation feel reasonable.

At one point, booting with nomodeset systemd.unit=multi-user.target plymouth.enable=0 reached a working bazzite login: prompt. That was an important clue in hindsight: the kernel and base userspace were not simply dead. Specific blocks on the live USB were failing to read.

SQUASHFS error: Failed to read block 0x9a384f27: -5
SQUASHFS error: Unable to read fragment cache entry [...]
SQUASHFS error: Unable to read page, block ..., size ...

The GPT message was equally unsettling:

GPT:Primary header thinks Alt. header is not at the end of the disk.
GPT:13883135 != 121145343
GPT:Alternate GPT header not at the end of the disk.
GPT: Use GNU Parted to correct GPT errors.

The sector number that disagreed changed between the physical USB drives I tested. The reported capacity stayed consistent because the drives were the same model/batch. That moving target was the reason I kept suspecting the media.

Everything I blamed first

Every one of these was worth checking. None of them turned out to be the root cause.

The one thing I had not varied enough was the port. Every failed attempt had been made through the same rear USB port group.

The part that actually mattered

On this board, the rear ports are not all on the same path. The 10Gbps rear ports are chipset-direct; the 5Gbps group is routed through an onboard third-party hub. The controller involved here was a Genesys Logic GL3523, a configurable USB 3.2 Gen 1 hub controller designed for, among other things, motherboard use.[2]

Every useful log showed the live USB enumerating as a child of that hub:

usb 4-3: New USB device found... Product: USB3.2 Hub, Manufacturer: GenesysLogic
usb 4-3.1: New USB device found... Product: USB DISK 3.0

That made the pattern make sense. The drive itself was not consistently bad; scattered reads were being corrupted or dropped somewhere in the hub-routed path. So every boot had a new collection of unreadable blocks, every USB drive looked suspicious, and the live filesystem kept failing in a way that resembled dying flash storage.

The fix was embarrassingly simple: I moved the installation USB to a chipset-direct rear port — the 10Gbps/red-labeled ports on this board — and retried. Same drive. Same ISO. First clean boot.

Why this was so easy to misdiagnose

This was an unusually good red-herring machine.

• The GPT mismatch looked like the classic signal of a counterfeit or fake-capacity flash drive.
• The failed SQUASHFS offsets shifted between attempts, which looked like unstable NAND.
• The graphical hang and the apparent improvement under nomodeset looked like a GPU/driver issue.
• The MokManager error was not imaginary: Bazzite does require its signing key to be enrolled when Secure Boot is enabled, and its documentation explicitly describes the MOK enrollment process.[3] [4]
• Memtest, a BIOS update check, checksum verification, and GPU reseating are sensible checks — but none of them are going to tell you a particular onboard USB path is intermittently corrupting reads.

If this sounds familiar

Before you re-download the ISO for the fourth time or RMA a flash drive, try this sequence:

1. Check the board manual for the rear USB port map and look for distinct controller/hub groups.[1]
2. Boot with verbose logging and look at the USB enumeration immediately before the mass-storage device appears. A drive listed as a child of a hub is not necessarily a problem, but it is a useful clue.
3. Move the live USB to a port that is documented as chipset-direct, then retest before changing the media or ISO.
4. If the behavior changes completely with the port, stop treating the drive as the only suspect.

Environment

Maybe the broader lesson is just this: when a hardware problem looks random, write down what you are actually changing. I was varying the drives, the images, the boot flags, the GPU configuration, and firmware settings. The only constant was the port. Once I finally changed that, the mystery disappeared.