So I’m currently stuck doing this after every dom0 update: UEFI troubleshooting | Qubes OS and its driving me up the wall. I dread to think what I’ll have to do when the 14.1 → 14.2 in-place upgrade option becomes available. I half imagine it just won’t work at all and I’ll have to start from scratch.
I’m willing to accept “Just keep buying new motherboards until you get one that fits your requirements and doesn’t hate Qubes” as a solution. I’d just like to check that there’s definately no other options first.
Alternatively, if this kinda thing is likely to be resolved by the QubesOS team i’d accept “Just wait for Qubes 5.0” as a solution. But I’m skeptical its a priority.
I suppose “Quit bothering us an go and report this properly on github” could be the real solution here. But the uefi-troubleshooting page kinda implies that I’m already doing the official solution. So I don’t want to bother the devs if it turns out QubesOS simply doesn’t support, and never intends to support my motherboard due to MSI not following some kind of open boot standard.
Sadly 3MDeb’s MSI PRO Z690-A’s don’t support my processor. So I imagine there’s a few headaches still to come and/or wallet aches.
Hence why I was hoping somebody was going to ride in on a white horse and tell me there’s some secret way to force anaconda to install QubesOS to “/boot/efi/EFI/BOOT/” and that qubes would happily update to there afterwards. But alass, twas just a dream…
Wow, if that works it’ll be a fantastic solution thank you noskb! I can even get rEFInd from the fedora repo and avoid expanding my trust circle much.
I’m struggling to see much of a downside to your solution, other then probably making the user slightly more vulnerable to an “evil maid” attack (I assume), but that’s not something I care about.
It’ll be a while before I can test this, but I’ll report back and mark your answer as the solution if it works.
Well the obvious downside is that your motherboard still contains boot firmware containing the UEFI bootloader. From a security standpoint, it is a significantly large attack surface compared to Coreboot-related solutions, provided that your threat model is capable and willing to utilize its vulnerabilities.
With the deadline for upgrade to 4.2 looming ever closer with no clear in-place upgrade guidance to fallback UEFI bootloader folks like myself I finally felt enough pressure to try out rEFind and am happy to report:
rEFInd from the fedora repo installed to a usb stick (seemingly) worked perfectly!
This is a much less stressful solution then the constant messing around in /boot/efi/EFI/BOOT from my guide. I’ll test drive it a while longer and see if it holds up through the OS upgrade, if all goes well I’ll write a howto for bypassing the issue using rEFind and put it in my guide thread.
Apologies for the thread necromancy, I just thought I should leave this here for anyone googling about the same issue.
rEFInd continued to work after in-place updating to QuebsOS R4.2.1, however I stopped using it because, miraculously…
QubesOS R4.2.1 fixed all my booting issues somehow!
So I won’t bother making a guide for rEFInd as it appears such a workaround is nolonger necessary.
Ofcourse because my QubesOS on my computer is some kind of demon which operates almost entirely on Faustian bargains, two essential keys from my keyboard are now rendered inoperable by the OS and my sound is broken but that’s a problem for another thread …
QubesOS R4.2.1 fixed all my booting issues somehow! 
…