Do you see any errors on boot? This is definitely fixed on various systems that were affected, multiple folks have reported that.
I’m running as dualboot. I’ve previously installed Fedora 39 using a workaround, have OpenSUSE Tumbleweed currently installed. Between those and Windows 11 is Fedora really that much heavier?
I don’t think the memory is the issue.
I’ll give this another shot tonight and let it sit for a while just in case.
No errors, just the underscore in the top left. I gave this another shot using FMW, Rufus, and Ventoy. Ventoy was the only method that allowed me to boot into the Live USB, specifically using GRUB mode and not Normal mode. However, once I installed Fedora 40 and rebooted, I hit the same issue when attempting to load the kernel. The only thing that worked was to repeat the install, chroot before restarting, and use the steps suggested by bukkfrig here. Just to be clear, my issue wasn’t freezing on the Microsoft logo!
That doesn’t sound like quite the same thing as we were tracking here. There is someone on Mastodon who reported that Beta works fine without modifications on their Surface Pro 3, though they seem to be using one of these things, which is a bit of a wild card.
Also, the exact bug tracked here did not affect boot after install, only boot of the install media.
1 Like
Ah, my apologies, mistakenly assumed it was a related issue.
Still have this issue, downloaded latest workstation beta and kde spin beta 2 days ago
Hardware: HP spectre x360 14" 2024
Still have this issue, on surface pro 8 (older fedora version boot with no problem)
for anyone still seeing an issue similar to this, it would probably be best to file a bug report, either at bugzilla or upstream shim - Issues · rhboot/shim · GitHub . there was definitely a specific problem in the old shim that was resolved with the one in Fedora 40. remaining issues have to be something a bit different. thanks!
1 Like
Yes, when I installed Fedora 36, the UEFI problem was solved. So how can I update Fedora 36 to version 40? Because I think it is updated as 37-38-39 and 40 respectively?
Yes, the update path is 36 → 37 → 38 → 39 → 40.
That can be done from the command line using dnf and updating one version at a time following the instructions here.
Those instructions have worked well for me with no problems for a long time and many releases of fedora.
1 Like
I once upgraded a Fedora 34 installation on my external drive directly to version 39, as an experiment, and the only thing missing were the GPG keys for the new version; installed them from Koji and the upgrade was flawless. I know this method is not officially supported and I’m not advocating for it, just an anecdote.
how did you do that. the second question is, isn’t the GPG key installed later as well?
The GPG keys for each upcoming release are installed by running dnf upgrade --refresh just before beginning the system-upgrade download step to upgrade to the next release. It is not necessary to use koji except in special cases such as was noted just above by @vrkvdd
@computersavvy I upgraded from 38 to 40 in gnome update checker
@kparal Is it not possible to integrate and install the shim file, which contains the bug, into the Fedora 40 ISO?
No. Altering the ISO is not possible. It is possible to create your own iso though.
The fix that I remember is to install f39, then upgrade to f40 using dnf and the system-upgrade plugin. That gets the proper shim file since it upgrades each package to the latest versions during the upgrade.
1 Like
Folks, if you read the description, you can see that only Fedora 37 - 39 is affected. Fedora 40 install media are fixed.
If you still see any issue with booting the F40 install media in UEFI mode, it’s a different issue, and please report it separately, see Adam’s response.
The UEFI problem continues in the Fedora 40 installation media. As you said, I installed and upgraded 36, it worked