Fall back to UEFI shell if Qubes boot entry is missing

[mehrexe]

How to file a helpful issue

Qubes OS release

Latest as of posting, 4.1.0

Brief summary

I manually unplugged every drive on my computer except for the target drive for the installation, which was all free space unpartitioned. Installer ran typically, chose automatic for the installation type. Booted into the OS' configuration and then the full OS.

GRUB is verified to have worked because I managed to see it when initially booting for configuration and because of a later restart due to a display artificating and then system lockup problem I had that I attribute to Nvidia.

After using another drive and then unplugging it, and plugging the Qubes drive back, there was no detectable boot source.

I booted a live OS and found that the partition structure was intact but didn't investigate further and reinstalled Qubes.

I then got the idea to see if this issue happened if I BIOS disabled drives instead of unplugging them. I disabled my Qubes drive and enabled another, and booted into it fine. I then disabled my other drive and reenabled the Qubes drive and the same issue happened again where my system does not see any boot entries.

The system does see the drive, and switching on CSM and legacy boot I can boot from the drive but get an error screen saying to boot from proper media.

This second time, I kind of fixed it but I must do these steps every time I remove the drive or disable it in BIOS. I lose the option to boot without the Xen hypervisor and the boot hiccups. I essentially have to boot my install media, run Anaconda rescue and:

1. Mount the bootloader partition
2. Copy the contents of /mnt/EFI/qubes/ to /mnt/EFI/BOOT/
3. Rename grubx64.efi to bootx64.efi
4. Rename grub.cfg to bootx64.cfg
5. efibootmgr -v -c -u -L Qubes2 -l /EFI/BOOT/bootx64.efi -d /dev/sda -p 1

Steps to reproduce

I believe the best way to reproduce this issue is to do a fresh install of Qubes on hardware similar to mine:

Asus Prime Z-390-A Motherboard Intel i7-9700K CPU 16GB DDR4 RAM 1TB HDD

Most notably, this motherboard. I will be filing a compatibility report soon, but I believe this motherboard may have something to do with how it reads the GRUB bootloader as it's configured for Qubes.

Further, these are the only non-stock BIOS settings:

• Disabling the Intel LAN Controller (it causes a PCI reset error and ends the last step of the configuration, doesn't matter since I don't use it, and I believe the fact that it's unplugged is the reason this issue happens)
• Enabling Virtualization
• Enabling Vt-d
• Disabling all other drives

Expected behavior

The GRUB bootloader is supposed to appear after the BIOS initializes regardless of whether the drive was previously unplugged from the system or not (safely of course).

Actual behavior

Please read above.

After unplugging the drive or disabling it in BIOS, the entry for GRUB is missing.

[Geblaat]

I experienced this as well on a HP 8300 Elite. I'm not sure this is a Qubes issue. Recently I had the same issue with Plague OS, which also uses UEFI boot. I haven't tried any other OS using UEFI boot besides Qubes and Plague, but I never had any issues with removing HDD's with any OS(including Qubes) when standard BIOS boot is used.

[Rot127]

I had the same problem. Though I did not remove the drive. It started randomly after a clean shutdown of Qubes. Also the GPT was corrupted. After repairing it (backup GPT was fine) the BIOS did not found the boot entry.

Your fix helped. Updating the BIOS didn't.

Hardware data: TUXEDO Pulse 14 BIOS: Vendor: American Megatrends Inc. Version: N.1.07.A05 Release Date: 04/25/2022

[Rot127]

Also shouldn't https://www.qubes-os.org/doc/uefi-troubleshooting/#boot-device-not-recognized-after-installing get updated (with something like the above)? The instructions seem no longer up to date. Is this correct (@kulinacs)?

[andrewdavidwong]

Also shouldn't https://www.qubes-os.org/doc/uefi-troubleshooting/#boot-device-not-recognized-after-installing get updated (with something like the above)? The instructions seem no longer up to date. Is this correct (@kulinacs)?

In case you (or any others reading this) are not already aware, the documentation is a community effort, and everyone is welcome to contribute. (That's how things like this get updated!) So, if you'd like to get involved with the project, this is a great way to do it. You can read more about how to submit documentation changes here:

https://www.qubes-os.org/doc/how-to-edit-the-documentation/

You may also be interested in the documentation style guide:

https://www.qubes-os.org/doc/documentation-style-guide/

[marmarek]

After using another drive and then unplugging it, and plugging the Qubes drive back, there was no detectable boot source.

This is how many UEFI implementations behave - if you unplug the disk, UEFI removes boot entries that were associated with that disk. Personally I think it's annoying and wrong, but there isn't really much we can do here, besides improving documentation how to deal with it.

[andrewdavidwong]

there isn't really much we can do here, besides improving documentation how to deal with it

Converted this to a documentation issue.

[rustybird]

there isn't really much we can do here

How about automatically creating a startup.nsh file on the root of the EFI partition, containing just the line

\EFI\qubes\grubx64.efi

That way even if the boot entry for Qubes OS is missing, as long as the system is configured to fall back on a UEFI Shell (and it's not preempted by another boot entry) it would still boot Qubes OS after a 5 second countdown.

ArchWiki claims that this "will work with almost all UEFI firmware versions you may encounter in real hardware". (Not with a stock T420 though, because that doesn't even have a UEFI Shell yet.)

[marmarek]

How about automatically creating a startup.nsh file on the root of the EFI partition, containing just the line

I like the idea. PR welcome :) (somewhere in core-admin-linux?)

[rustybird]

somewhere in core-admin-linux?

Or the grub2-efi-<arch> package in qubes-grub2.git, so that the line could be generated using

\EFI\%{efi_vendor}\%{grubefiname}

[adrelanos]

The referenced git commit implies that this was implemented?

[rustybird]

@adrelanos If you follow the last commit, below the commit message there's a link to the (still open) PR at https://github.com/QubesOS/qubes-grub2/pull/14