MSI motherboards defy boot manager after BIOS update

Not only Qubes but also Arch (as opposed to Debian, not sure about Fedora) loose their boot capability after a BIOS update which sets Secure Boot on; a consecutive setting to off does not fix the following problem: no boot option exits anymore in the BIOS and the system becomes unusable.

MSI motherboards do not allow fixing the problem via:

efibootmgr -v -c -u -L QubesOS -l /EFI/qubes/xen.efi -d /dev/nvme0n1 -p 1

when in a Secure Shell from the installation media or through chroot as explained here Lost EFI entry in boot menu after removing and re-connecting drive - #2 by waterfrontpark

but require a full installation of the bootloader:

grub2-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=qubes --force --verbose

which fails due to (intentionally?) missing grub2-efi-x64-modules that cannot be post-installed.

The specific hardware is a MSI Z590-A PRO - a similar board has added to the HCL list recently, if I am not mistaken.

It might be possible to copy bootloaders around but that is probably not the canonical way of solving the issue.

I’m using the MSI Z690-A Pro with the Dasharo firmware, and was able to restore the boot menu using the EFI tools in the firmware.

I don’t know if the stock firmware has the same options, but I didn’t need to run any commands. In the BIOS, I could browse the EFI filesystem and select the file I want to load, and then I just added it to the boot options as the default. This restored my boot options after a firmware update.

1 Like

Good to know. However, I am having the same issue on an MSI Laptop:

MSI Modern 15 A5M-042 Ryzen 7 5700U

which is surprisingly faster running Qubes than on the workstation (not now though :slightly_smiling_face:)

The solution is rEFInd. It even executes from any external boot stick under Linux or Windows (manual). No configuration required and only takes a second. It finds any EFI files and presents them as an icon.

Qubes OS then starts fine after a BIOS update on MSI motherboard or when the boot manager gets lost otherwise.

A second precautionary solution is to execute on a running installation in dom0:

sudo qubes-dom0-update grub2-efi-x64-modules

Then, grub2-install will work later on when needed.