Fedora Producing '00' Q-Code on Crosshair VII Board

I’m getting a ‘00’ Q-code on a CrossHair VII Hero wifi board Fedora 28/Fedora 29 (Rawhide). Other distributions produce the ‘24’ indicating a normal boot.

It’s on a week-old Ryzen 2700x system.

To be precise, Fedora also boots to a ‘24’, then displays ‘00’ as soon as I log in and the display manager, e.g., GDM on Gnome, goes away. Live images, which do not show users a display manager, also produce the ‘00’.

I see this on installed Gnome, and live Gnome, live Cinnamon and live MATE.

The motherboard manual says ‘00’ is ‘Not used’. Google says its reserved for thing like CPU failure, warped/broken boards, shorts, etc. None of those things affect the board here and it’s apparently doing fine.

What kind of things could Fedora be doing to affect the motherboard this way? Anything possible for me to check on?

(Board’s BIOS is current and running with “Optimized Defaults”.)

is secureboot off?

try turning off xmp and booting with jedec 2133

might just be a failed memory strap application, and if it’s not wholesale preventing boot then you can just ignore it

Well, after a few installs and throwing several live images at it, what the '00" Q-code producers have in common that the non-producers do not is a 4.17 kernel. Of course, they might have a million other things in common.

The thing hasn’t refused to boot or melted down so I’ll stop looking at the numbers.

It’s interesting that the Asus manual for the board says ‘00’ is not used, while a quick search turns up reports of it appearing on non-booting Asus boards.

If I remember right (i have the same thing) its just that its not talking with it. 00 seems to be a default “no code” code.

Basically, it isnt an issue, nothings wrong.

I get the same 00 Q-code with C7H/2700X/Fedora28. I had the impression that’s normal. On the contrary, I would think having a code remain after a successful boot would be abnormal.

If i can find the source i had I’ll link it. If I remember, it had something to do with Fedora not talking to the motherboard correctly via the ACPI stuff (or whatever the qcode stuff uses), its a bug, but its not a hardware issue or an issue with failed hardware.

The motherboard aren’t tested on Linux so it never comes up. Since 00 isnt an error, its not used, its just a failure to talk to the system.

Maybe @wendell has seen this with his various testing also?

Mine otherwise shows “24” at the end of a successful boot. I read someplace that happens simply because it’s the last code displayed.

I had the “00” code problem and I returned my board because basically the board will boot 2 times out of 5 roughly.

This is not your case but a “00” is basically the board is not working/nothing is inizialized on it. It’s not something you should see. Also the 24 is not right either. The correct boot code should be A0.

Have you tried booting windows to see what happens? This board sounds not good to me really.

It’s 24 consistently in Windows. The board’s manual has A0 as “IDE initialization is started”.

The trio of LED’s under the numeric readout have never indicated a problem.

If the system works and performs as expected, the qcode isn’t of any use.

The precision and correctness of codes is a joke.
What ever the Devs intended, experience suggest that its far off from what they wrote in the Documentation.

Just some related Info, nut necessarily useful:
Most boards have an AMI bios, even Asus.
MSI for example displays current cpu temp on the “qcode” display after successful boot.

What code does the board display when you boot it without ram ?
What when you have the stick in a secondary slot of a channel so it will find ram, but can’t boot ?
Many more examples.

It’s usually not what the docs state as Ram problem codes.

Yeah, that means the control of the system has been handed to what’s on the drive you’re booting from. In all the tech reviews I’ve seen on Asus motherboards, when systems are booted into an OS, the code shown is A0.

If you want when I get my new PSU I’ll make you a slowmo video of all the codes my Asus board goes through, maybe can be helpful for you to see how it should behave.

The Asus support site isn’t all that great but in a quick look I noticed Q-code listings that don’t match the one in this board’s manual. The differences look to be more than choice of phrasing by documentation writers.

Since the board has a mechanism to report errors and it isn’t, I’ll leave things as they stand. Sending the board back would mean taking the machine apart and putting it back together. No thanks on that.

I always reference the manual that came with the board, don’t look at what’s on the site.

Well it’s reporting you errors since it’s stuck on code 24 after boot and just stops working with Fedora. Maybe you can try to manually update the BIOS through a USB stick and see if that fixes the issue. Even a reflash of the latest BIOS might work too.

Fedora works fine. Every distribution I’ve tried works fine. I thought it was interesting on Fedora that the code is 24 while GDM, or LightDM in the spins, has control, and then goes to 00 after logging in.

I actually updated the BIOS before noticing this Q-code business. Can’t remember if it was happening before the update. I’m likely to notice if it goes away with the next update.

I see code 24 as soon as the OS starts booting, and if the LEDs are set to stealth mode, the q-code turns off as soon as it hits code 24. Code 00 shows up when the DE (MATE) or login manager load, before I even log in.

Can also report a “24” code after successful boot (Win10) with C7H and 2700X…