Scumbag
February 25, 2024, 1:20pm
1
There have been several topics on disappearing UEFI boot entry for Qubes, when booting into Windows or changing the internal drive. Those offered a few commands to manually repair/restore the boot entry.
Marmarek explained that is unfortunately how many UEFI implementations behave:
opened 09:26AM - 02 Jun 22 UTC
T: enhancement
P: default
pr submitted
C: boot
[How to file a helpful issue](https://www.qubes-os.org/doc/issue-tracking/)
#… ## 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.
Two possible fallbacks were discussed, but the PR’s have not been merged yet.
One is the startup.nsh file:
QubesOS:main
← rustybird:fallbacks
Install a startup.nsh file at the root of the EFI System Partition, with
%config… (noreplace) to avoid clobbering an existing file. For
grub2-efi-x64 it will contain the line: \EFI\qubes\grubx64.efi
If the Qubes OS boot entry is missing, there's a chance that the system
will boot into a UEFI Shell and that the UEFI Shell will look for a
startup.nsh file on our drive (more likely if it's an internal one) to
execute, usually after a 5 second countdown.
(The file is *not* packaged for the "alt architecture" subpackage -
which is only grub2-efi-ia32 built for x86_x64 - because subpackages
cannot easily include different content at the same file location.)
Fixes QubesOS/qubes-issues#7542
It is possible to manually create this file from Dom0 terminal, to avoid having to repair the boot entry later?
If so, could someone provide the commands to do this?
sudo tee /boot/efi/startup.nsh <<< '\EFI\qubes\grubx64.efi'
2 Likes