Fedora Version: Server Edition (Minimal) with Sway -- Rawhide(please hear me out)
I understand the rants and restrictions around future release versions. I am only looking for a pointer (redirection) to help relevant parties track this down – at least some people won’t have to pass through this experience in that ‘proper’ future.
This may be the result of a hardware problem but the pattern suggests otherwise. Here is what happens.
I install a minimal version (adding standard and network packages) of a recent server edition of Fedora. Installation goes fine for Dual booting (with UEFI and a Windows 10 OS in there). This involves recent packages – no need for updates
The machine shows the GRUB menu as expected. It boots and it works for two or three days (usually within a week). Then on one surprising morning …
The strange part is that it works after re-installation. Which component is suspect? I am able to boot with a Live media of Fedora 42 and access the filesystem left by the installation. Reinstalling GRUB after the error doesn’t fix it. It only adds another EFI entry. Both entries fail to boot with the same error message.
Could this be a drive sector issue (hard disk)? Otherwise, why does it work after re-installation? Windows is still booting on the machine … using its own Boot Manager.
I am looking to file a report against a component. Which one, and with which files? Is Windows OS altering something perhaps? Any ideas?
Next time this happens, you could try booting a live Fedora USB and running efibootmgr in the terminal. If Windows has messed with the NVRAM boot entries, that should show up there.
BootCurrent: 0004
Timeout: 0 seconds
BootOrder: 0000,0001,0002,0007,0008,0009,0004,0003
Boot0000* Windows Boot Manager HD(1,GPT,XXXXX-XXXX-XXXX-XXXX-XXXXXXXXXX,0x800,0x400000)\ ....
Boot0001* USB Floppy/CD VenMedia(XXXX-XXXX-XXXX-XXXX-XXXXXXXXXX,0500000001)0000424f
Boot0002* USB Hard Drive VenMedia(XXXX-XXXX-XXXX-XXXX-XXXXXXXXXX,0200000001)0000424f
Boot0003* Fedora VenHw(XXXXX-XXXX-XXXX-XXXX-XXXXXXXXXX)
Boot0004* Fedora HD(1,MBR,0x11ff9a,0x800,0x39567e0)/\EFI\FEDORA\shimx64.efi
Boot0007* UEFI: IPv4 Realtek PCIe GBE Family Controller PciRoot(0x0) ...
Boot0008* UEFI: IPv6 Realtek PCIe GBE Family Controller PciRoot(0x0) ...
Boot0009 Fake Legacy Option VenMedia(XXXXX-XXXX-XXXX-XXXX-XXXXXXXXXX,0600000000)0000424f
It appears the Machine is set to boot Fedora but I am noticing a strange entry for the drive. MBR? That’s strange for a GPT Drive. So, then grub2-mkconfig may be indicted?
Did you have CSM (Compatibility Support Mode, i.e. legacy BIOS mode) enabled when you installed Fedora, and/or do you have it enabled now? That can be a problem, e.g. this similar report on an HP machine with Ubuntu.
However, I don’t know why the problem would only emerge after a few days.
The BIOS Setup Utility does not provide that option. There’s:
Legacy Support Disable
Secure Boot Enable
Key management
Clear Secure Boot Keys Don't Clear
Key Ownership HP keys
Fast Boot Disable
That’s it.
I had referenced that post before. I don’t see CSM here
The BIOS does not allow me to Enable Legacy Mode without disabling SecureBoot which is impossible on a GPT Drive. I am, therefore, doubtful that Legacy mode was active during installation. Like I said earlier, it works after installation. Unless, a package pulled in newer grub packages. Something is off.
I gave up on dual booting with Windows 10 and 11 because of boot failures 3 months in a row after installing Windows updates. Windows was renabling “fastboot”, so I had to boot Windows and use the System Recovery option to boot the Live USB drive. For me, efibootmgr often showed the alternate grub2 PciRoot.. entry format so I added a correct entry and later deleted the pciroot entry.
I have confirmed that Microsoft Windows is responsible for this anomaly. I had silently reinstalled Fedora after posting this reply (i.e. on September 4, 2025). Everything went well (including dual-booting).
The issue resurfaced yesterday after Windows insisted on an update. Now only Windows boots – quite malicious, that product. Apparently, Windows is corrupting boot entries associated with Fedora. There has to be a plausible way to remedy or restore affected entries without re-installation.
