Boot device not recognized / troubleshooting instructions question

crowizz · January 25, 2024, 6:37pm

I just built a PC for Qubes, and after the installation process went great, the computer just booted to the UEFI BIOS setup instead of Qubes. I found the troubleshooting section above that seems to apply, but I had a few extra questions as a new user. The problem seems to be that my BIOS does not recognize the Qubes partition as bootable.

Quick note, I am quite surprised that this system has this issue as I used identical motherboard and parts to certified hardware specifically this system trying to avoid problems like this one–

The Dasharo FidelisGuard Z690 is a desktop based on the MSI PRO Z690-A DDR4 motherboard.

I have determined that I have a system that does not recognize the UEFI EFI that Qubes uses and ignores it as a boot option. I thought it might be the nvme, but installing ubuntu on it boots.

I can’t follow the troubleshooting instructions because from the rescue shell, even if it is decrypted with my passphrase or if I install Qubes without an encrypted LVM LUKS, it still says, “You have no Linux partitions”.

I can’t get to the /boot/efi/EFI/qubes because any partition I can mount using Ubuntu has an empty boot directory. I have tried the “How to mount a Qubes partition from another OS,” and still, I keep hitting a wall. I actually put a spinning disk in and installed Ubuntu on that, hoping I could get into the partitions I couldn’t get from the rescue shell, but I couldn’t find the pertinent boot folder.

Please keep in mind I still have never seen Qubes past the install screen, so I don’t know much about the partitioning and where to find what, and the troubleshooting doesn’t specify much in my case. Kinda pulling my hair out because I built this PC just for Qubes after my other system had hardware issues and couldn’t even get to the install screen.

Thanks in advance for any help at all. I hope I was descriptive enough, if more information would help just let me know. I really love the idea of this OS and would love to use it!

Edit: I can’t use CSM or Legacy boot mode because the integrated graphics mode does not allow it on my Intel chip, so I am stuck with UEFI mode.
nvme0n1p1 = EFI partition
nvme0n1p2 = ext4
nvme0n1p3 = lvm

Which of these partitions do I need to mount and change the EFI files on, and can it be done from the rescue shell somehow? I have tried following old posts to resolve this, and I am still not even sure this is my actual issue. Sorry for the long-winded post.

screenshot of my partitions after non-ecrypted LUKS installation:

apparatus · January 25, 2024, 8:43pm

Did you try to mount /dev/nvme0n1p1? Is it empty?
If it’s not empty then you can try to add EFI boot menu entry using this command in Ubuntu or in Qubes OS installer shell:

efibootmgr -v -c -u -L "Qubes OS" -l /EFI/qubes/grubx64.efi -d /dev/nvme0n1 -p 1

If it won’t work then you can try this:

github.com/QubesOS/qubes-issues

Fall back to UEFI shell if Qubes boot entry is missing

opened 09:26AM - 02 Jun 22 UTC

mehrexe

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.

github.com/QubesOS/qubes-issues

Raw disk backup of Qubes EFI is unbootable

opened 02:53PM - 15 Jul 23 UTC

adrelanos

T: bug P: default needs diagnosis affects-4.1 C: boot

### Qubes OS release R4.1 and R4.2 ### Brief summary When making a raw …disk backup from a Qubes installed to an internal hard drive to an external hard drive, the external hard drive is unbootable. raw disk backup means a backup using `dd` or 1 to 1 exact copy. ### Steps to reproduce 1. install Qubes normally on a computer that only support EFI booting on the internal harddrive 2. reboot 3. brief test that Qubes is working normally (yes) 4. shutdown Qubes 5. boot from an external drive, boot a live DVD or live USB such as Debian Live 6. perform a raw disk backup from the internal disk to the external disk 7. unplug that disk and try to boot from it in a different computer (or the same Qubes computer) ([example instructions for raw disk backups](https://www.kicksecure.com/wiki/Raw_Disk_Backup)) ### Expected behavior The raw disk backup of Qubes is bootable. ### Actual behavior The raw disk backup of Qubes is unbootable. ### Additional information According to my research that might be because of missing entries in the EFI firmware's NVRAM which is stored on the motherboard. Unfortunately, the EFI boot process doesn't seem by default to be self-contained on 1 harddrive but require extra settings stored outside harddrives on the motherboard (EFI NVRAM). Using `grub2-install` with options `--removable` / `--force-extra-removable` during Qubes installation might help? > [--removable](https://manpages.debian.org/bookworm/grub2-common/grub-install.8.en.html#removable) > the installation device is removable. This option is only available on EFI. > [--force-extra-removable](https://manpages.debian.org/bookworm/grub2-common/grub-install.8.en.html#force~2) > force installation to the removable media path also. This option is only available on EFI. Qubes does not have good support for multiboot support anyhow: * https://github.com/QubesOS/qubes-issues/issues/8351 * https://www.qubes-os.org/faq/#can-i-install-qubes-os-together-with-other-operating-system-dual-bootmulti-boot * It's "patches welcome". (And that's okay.) This ticket is not a feature request to improve multiboot support. Why do I mention this? Because otherwise, when considering options `--removable` / `--force-extra-removable` one *might* argue "but that breaks mutliboot support". I would argue that being able to boot a raw disk backup of Qubes is more important than mutliboot support. [Why do I like full raw disk backups? See this link.](https://forum.qubes-os.org/t/how-do-you-organize-your-backups/3986/16?u=adrelanos) Manually updating the NVRAM can be challenging: * It's vendor dependent because of many different EFI BIOS versions. * Some BIOS don't even have such an option. * Might require booting into an operating system installed on USB and running console commands to fix it. * Difficult, impossible for far most users to do or even to find instructions for it. Qubes with legacy BIOS booting as far as I remember didn't have this issue. However, never notebooks sometimes (or often, dunno) don't even support legacy BIOS booting anymore. Therefore "use legacy BIOS booting" is a non-solution. Also not a good long term solution in either case because of Qubes planned Secure Boot support. This bug might also make Qubes "non-portable". Meaning, Qubes installed to an external drive such as a USB SSD might be bootable on the computer where it was installed but unbootable when attempting to boot the same Qubes USB SSD on another computer. I didn't test this very part mentioned in this very chapter. Anaconda by Fedora might be using `grub2-install` with options `--removable` / `--force-extra-removable` already when installing to external devices (USB) instead of internal harddrive. Where is the Qubes code which defines bootloader / grub2 / EFI installation? Or is this currently all done by upstream's Anaconda?

ChrisA · January 25, 2024, 10:13pm

Hi Crowizz

To just test your installation, you could try to find the boot partition from the USB-installer:

it might be

(hd0,gpt1)/EFI/qubes/grub
(hd1,gpt1)/EFI/qubes/grub
(hd2,gpt1)/EFI/qubes/grub

you should look for (depending on the number of drives in your machine) …

If it works, you can follow the steps from @apparatus to either add it with efibootmgr or create the fallback path.

crowizz · January 25, 2024, 10:24pm

I got the EFI partition mounted using the rescue shell now… however the instructions say to rename xen.cfg to BOOTX64.cfg after copying the contents of /EFI/qubes to /EFI/BOOT in the troubleshooting section.

My folder does not contain xen.cfg, the only cfg file is grub.cfg in the qubes directory. here are the files:
fonts grub.cfg grub.cfg.rpmsave grubx64.efi xen-4.17.2.efi

so now that I have the EFI partition mounted, I am not sure what to move or rename to the BOOT folder. I also tried running the efibootmgr command but it still did not show up as a bootable device. Any idea why the troubleshooting says to rename files that aren’t present or am I mounting the wrong partition?

Thanks again so much for the help.

ChrisA · January 25, 2024, 10:28pm

I think the xen.cfg reference is from Qubes OS 4.0 (IIRC) - with Qubes OS 4.2, you should look for [something like]

cp -r qubes/* BOOT
cd BOOT
mv grubx64.efi bootx64.efi
mv grub.cfg bootx64.cfg

crowizz · January 25, 2024, 10:29pm

Thank you so much! I will bookmark this page so I can get qubes to boot next time I need to update it! I got it booted now, thanks again!

ChrisA · January 25, 2024, 10:32pm

Since the GRUB config has been copied to BOOT, you’ll probably have to copy it again, when Qubes OS updates the kernel/GRUB config …

Edit: Strike that! – I keep forgetting, that Qubes OS 4.2 introduced the unified GRUB config … so you should be fine with the copy (with Qubes OS 4.2, the updates always goes to /boot/grub2/grub.cfg)