After updating my Fedora Rawhide install today, it finally happened. After 2 years and a month, I can’t boot anymore.
Grub loads, but it lands me in a prompt without a menu. And when I “ls” the disks… i get errors. (See the image)
does anyone have any experience with this or what’s going on… and of course if i can fix this. 
Thank you in advance,
Ari
If it is software issue it can only be related to grub2, but last grub2 update in rawhide was last month. So I suspect it is related to some hardware issue like bad blocks around the EFI or boot partition that breaks the system.
So, grab a liveUSB, boot the system from it, backup your files, find some tool to check what is happening with the disk and filesyste.
Had the same yesterday, simply install over with the Fedora 43 live .iso - it will keep your /home untouched (the first option as shown below):
I’ve tried chrooting first, but when it came ro fiddle with disk UUIDs it became too rediculous for a manual fix…
Here is my screenshot from yesterday… 
This Bugzilla ticket appears to be the same issue:
Comment 9 suggests reverting to an older GRUB build from koji. (I assume you do these commands after chroot-ing into the install.)
1) Install koji client:
sudo dnf install -y koji
2) Download the older Fedora 44 build (example: grub2-2.12-48.fc44):
mkdir -p ~/koji/grub2-2.12-48 && cd ~/koji/grub2-2.12-48
koji download-build --arch=x86_64 --arch=noarch grub2-2.12-48.fc44
3) Install/downgrade from the local RPMs:
sudo dnf downgrade --disablerepo='*' ./*.rpm
# (or: sudo dnf install --allowerasing --disablerepo='*' ./*.rpm)
Tell me when I can just do it from an fedora rawhide iso
I have the same problem after updating on an Asus ROG laptop with the inability to boot into the system or view existing disks and their contents through GRUB.
And I see a similar problem when trying to run a live image of Fedora-Workstation-Live-Rawhide-20260111.n.0.x86_64
In today’s new live image of the disc Fedora-Workstation-Live-Rawhide-20260112.n.0.x86_64.iso the problem with GRUB has been fixed.
The live image loads without problems.
The system installed from it also boots without the above-described problem with GRUB.
Updating the installed system is not required - there are the most “fresh” packages.
So at the moment, the current version of Rawhide works without problems with GRUB.
Rawhide is expected to break from time to time. Nothing you should use on a daily basis unless you are developer or doing dedicated testing (reporting useful bug reports)..
Why do you guys @ariaan @rbirkner not running Fedora 43, the latest stable?
I personally would prefer a more “rolling” release mode …and of course the bleeding edge, rawhide is almost it - and while using it for years I have rarely issues (not more than with stable, which runs on my wifes and sons laptops)
btw: if you can manage to boot, now a downgrade is available…
The problematic grub2 package was untagged for now:
Hopefully it can get sorted and fixed, it’s being worked on.
Fixed in latest rawhide iso build.
For folks who had this problem (and anyone else!): the bootloader team needs testing on another attempt to fix the original problem without breaking things for anyone else. If folks who were affected by this problem could help test the new build and see if it boots OK for them, that’d be great. Instructions are here. Sorry about the requirement to disable Secure Boot - it’s because this is a scratch build and the system won’t allow scratch builds to be Secure Boot-signed. You can reinstall a ‘known-good’ grub and turn SB back on again once you’re done testing.
Thanks a lot!
It works now thanks for the fix. It would be nice if it was checked to see if it boots via a VM or something as a test.
We do always test that, but this bug was specific to UEFI firmwares with particular properties. Neither the bug we were trying to fix in the first place, nor the bug that was caused by the initial fix for that, show up in VM testing (or testing on most other hardware).
