Dealing with a renamed Windows boot manager

Support
1

The thing is I’m currently trying to work around a potential quirk in the UEFI BIOS of my motherboard, where it appears to be trying to keep Windows Boot Manager as the first boot option in a rather hacky way.

If I change the boot order to boot something else first, and then actually booted it, like Manjaro GRUB, the BIOS would silently remove the Windows Boot Manager entry from the boot options. This does not have any apparent effect, except that since Windows Boot Manager is now gone from UEFI BIOS boot options, it has to be chainloaded from another place (like Manjaro GRUB or rEFInd).

If I at one point booted Windows again, regardless of where I booted it from (be it Manjaro GRUB or rEFInd), the BIOS would silently reinstate Windows Boot Manager as the first boot option so subsequent boots will go to Windows automatically.

I’ve already disabled things like Fast Boot (due to the use of ImDisk RamDisk) so one can rule out that be the cause of the issue.

For now I ended up renaming /EFI/Microsoft folder to something else like /EFI/Windoze as this would make Windows Boot Manager permanently disappear from the UEFI BIOS boot options so it would not be able to do its dirty tricks. This does have side effects. Namely, rEFInd and Manjaro GRUB (os_prober) could no longer detect the presence of Windows Boot Manager anymore. I could, however, copy the previously generated Windows boot option to 40_custom and point to the new path and confirmed this way works and I could boot Windows again. However, this means I can only boot this from Manjaro GRUB, and I’ll need to manually update the boot option in case anything vital got changed in the future…

I’m not sure what’s really causing the boot order issue in the UEFI BIOS, but I’m still looking for a better solution. From what I read, on some systems (like some HP laptops), renaming Windows boot manager was mandatory to get something other than Windows to boot.

By the way, does anyone here have experience with Quibble? I’m interested in using that to replace Windows’ original boot manager but I’m not sure whether os_prober or rEFInd could pick it up, and whether it’ll still work on a NTFS partition (Quibble was said to be used for booting Windows on Btrfs).

I’m not really confident about converting the system partition to Btrfs, due to a past experience while I was on vanilla Arch (about 4 years ago), where after converting to btrfs from ext4, the home partition became very unstable that it constantly entered a read-only state that I ended up backing up the contents and formatting the home partition with a fresh btrfs partition to get the issue fixed.

2

Some laptops do have such a logic, the firmware will stubbornly keep trying to boot anything named Windows Boot Manager. So what I did was name my rEFInd entry as Windows Boot Manager after renaming the original one into something else. Problem solved. I intended to use rEFInd as my boot manager anyway.

3

can you return

inxi -Fxza --no-host
test -d /sys/firmware/efi && echo efi || echo bios
sudo parted -l 
sudo efibootmgr -v
4

Just checked the commands, and I found no “Windows Boot Manager” related stuffs in it, since I’ve now moved the Windows Boot Manager away from the original path.

Turned out there was already an example in rEFInd config file for booting Windows. I enabled the example and modified it to point to the new path and now everything’s working like before.

It’s just that if os_prober can be configured to be more flexible in case of a Windows Boot Manager that has been renamed/moved away to deal with certain UEFI BIOS quirks, as currently I’m merely keeping a modified variant of a previously auto-generated Windows boot entry in GRUB (that needs to be maintained manually). It’d be better if the Windows Boot Manager entry can be auto-generated/updated even after renaming/moving it.

5