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.