Cannot boot into Qubes 4.1 - what has changed in 4.1 boot routine (UEFI)?

User Support General
1

Hello,
after a temporary disk swap, I cannot boot into an existing Qubes 4.1 installation anymore unfortunately (UEFI).

From my experience with 4.0, Qubes OS is nitpicky regarding disk device changes. What I have usually done from Live rescue mode is:

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

This does not work with Qubes 4.1 (“no bootable device”).

I discovered in this post a slight change in the specified bootloader:

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

1.) Is latter the proper command for Qubes OS 4.1 now?

2.) is there any information, what exactly has changed in 4.1 boot routine? For example, why the change from xen.efi to grubx64.efi? (Does this have anything to do with the change from LUKSv1 to LUKSv2?)

I am no expert on UEFI and would be glad to read a bit more on this topic, preferably Qubes-specific.

Thanks in advance!

2

Here is an update: I can confirm the correct command now is:

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

Note the grubx64.efi bootloader instead of xen.efi.
On my system, I got a non-critical error at boot time, before the GRUB menu starts:

Welcome to GRUB!

error: file ‘/EFI/qubes/fonts/unicode.pf2’ not found.

I have no idea, why this file has been removed. But it does exist on the Qubes OS rescue disk (here /dev/sda):

mkdir /mnt/sda1
mount /dev/sda1 /mnt/sda1
ls -al /mnt/sda1/EFI/BOOT/fonts/unicode.pf2

One probably can copy this over again, but I don’t want to do any file copy operation to dom0, which is involved in the boot process. This file seems to be non-critical.

But maybe, someone is more clever than me and can explain all this :slight_smile:

1 Like
3

Yes, except drive and partition number

This is more complicated, i believe it’s related to secure boot, for more detail see here The rEFInd Boot Manager: Managing Secure Boot

and it doesn’t have anything related to luks version.

Ideally this should call from grub2 folder, when you generate grub, grub is building theme, configuration and etc from this folder (/boot/grub2 if i’m not mistaken).

I can say that there’s something wrong with your grub2 configuration.

In 4.1 boot is separated from root partition, because we using luks2 as default.

It’s part of grub2 theme, and yeah that’s not critical, i even dont need that.

1 Like
4

Thanks @51lieal !

After swapping disks, this unicode.pf2 file hs been deleted automatically - I have never customized GRUB config. Fresh Qubes 4.1 installation had started without any errors.
This might be some sort of GRUB auto clean issue.

Just glad, aforementioned command will fix the Qubes boot entry. In the past I had … bad experience … fixing GRUB issues by hand:

index
index2158×1855 282 KB

:cowboy_hat_face:

5

As far as what changed from 4.0 to 4.1,

  • R4.0/UEFI does not use GRUB2. xen.efi is the EFI loader executed by the firmware, and xen.efi requires a xen.cfg configuration file for Xen and kernel parameters. Xen, the linux kernel, and the initramfs live on the EFI System Partition, which can be an issue during upgrades if the partition is too small.
  • R4.1/UEFI uses GRUB2. grubx64.efi is the EFI loader executed, which requires a grub.cfg file specifying to boot Xen using the multiboot protocol. GRUB2 lives on the EFI System Partition, but Xen, the linux kernel, and the initramfs are loaded from the /boot partition.

In R4.0, if you wanted to change Xen or linux parameters before booting, you had to use a livecd to modify xen.cfg and reboot. Or if you’re brave, save a reboot by booting into the UEFI shell, using the text editor in the shell to modify xen.cfg, and then executing xen.efi.

In R4.1, with GRUB2, modifying boot options is simple as hitting ‘e’ on a boot entry, make your changes, then booting the entry.

The latest unstable version of Xen now supports a unified EFI file structure which wraps xen.efi, xen.cfg, linux kernel and the initramfs into a single EFI loader. That would allow for allowing Xen to be booted using Secure Boot seamlessly as long as it was signed properly. This might then take GRUB2 out of the picture again.

4 Likes