After successfull UEFI setup: BIOS Boot File Selection


I successfully installed Qubes OS (UEFI mode) on a storage with GPT following the guide with manually configuring boot partition sda1 mount point: /boot/efi file system: EFI System Partition

First boot failed and I recognized in my BIOS boot option was set on Legacy. As I changed it to UEFI I had to choose a file under EFI Boot Selection and I chose xen.cfg. After that booting into Qubes OS worked and I performed the first update. Everything is working.

After the update I wanted to get sure that Qubes OS is setup properly. I checked again my chosen Boot Option under BIOS and it was set then automatically to \EFI\qubes\xen.efi.

Here are the files I can choose under BIOS EFI Boot Selection:

  • xen.cfg
  • xen.efi
  • xen.cfg.anacbak
  • vmlinuz-4.19.155-1.pvops.qubes.x86_64
  • initramfs-4.19.155-1.pvops.qubes.x86_64
  • vmlinuz-4.19.94-1.pvops.qubes.x86_64
  • initramfs-4.19.94-1.pvops.qubes.x86_64

Was it correct to choose xen.cfg under BIOS Boot Selection?
Is it correct that after Qubes OS update the file under BIOS Boot Selection is set to xen.efi and how this was possible?
Why there are also older versions of vmlinuz and initramfs? Should I delete them and if yes what would be the best way to do this?
How can I generally access these files to check them? Is it preferred to access them from dom0 under Qubes OS or via installer Rescue mode on UEFI?
Could your provide a resource about the explanation of these files?

Thank you.

Assuming you are booting Qubes R4.0 with UEFI, xen.efi is the only thing your BIOS would load that would allow the system to boot Qubes. Unless your BIOS searches for the next EFI binary in the directory, your selection of xen.cfg should not have worked.

  • xen.efi: An EFI binary that contains Xen. This is the “bootloader” that your BIOS will load to start up Qubes.
  • xen.cfg: xen.efi references this file to determine boot options and which dom0 kernel to load
  • vmlinuz/initramfs: dom0 kernel and initramfs

If you kill any of these, your system will not boot.

What you do want to do is watch the free space in /boot and /boot/efi. Some EFI partitions can be tiny in size - if you are doing a fresh install without dual booting, it’s a good time to make it large enough.

When you perform a Qubes update, a new kernel (vmlinuz) gets installed and a new initramfs gets generated. The system keeps the latest 3 kernels. I’ve seen multiple times where the initramfs generation fails due to lack of space, and upon reboot, the system doesn’t boot. (For an UEFI R4.0 boot), that requires using a rescue disk and updating which kernel should boot in xen.cfg. If you boot with legacy BIOS it’s much easier since you only have to select a different GRUB menu option. Qubes R4.1 with UEFI does use GRUB; R4.0 with UEFI is the headache when your system doesn’t boot.

Boot order on R4.0 with UEFI:

--> [xen.efi] --> loads Xen hypervisor
--> [Xen reads xen.cfg] --> loads dom0 linux kernel (vmlinuz)
--> [dom0 linux kernel loads initramfs] --> transfers control to initramfs init
--> [initramfs init] --> gets root partition ready (eg unlock LUKS-encrypted disk) --> transfers control to rootfs /init (systemd)
--> [rootfs init/systemd] --> starts system

You are right as I installed Qubes R4.0 with UEFI. I forgot to mention this.

Thank you very much for your answer and detailed explanations. This was exactIy what I was looking for to get a better understanding. I set partition size of boot partition to 1G. I assume this should be enough.

Anyway the BIOS behavior is still strange because I’m really sure I chose xen.cfg after installation. Then I performed an update of the Qubes OS and after that I looked again into BIOS and recognized all the files. Do you have an explanation for this behavior? Is it possible that BIOS really changed something automatically as it searched for the next EFI binary?

I don’t have an explanation other than it depends on your BIOS implementation on how it decides to find/boot EFI loaders. The UEFI spec leaves a lot open to interpretation and implementation, which is one reason some boards have a harder time booting a non-Windows OS.

In addition, I feel the need to mention this to supplement the “boot order” text I wrote in case some users concerned about boot security see where the “vulnerabilities” can exist:

  • Qubes does not support (UEFI) Secure Boot0, but there is progress with Trammell Hudson’s safeboot1,2
  • Anti Evil Maid3 is available if booting with legacy BIOS, but requires an Intel CPU (and chipset) that supports Trusted Execution Technology (TXT) and a TPM(1.2).