UEFI Boot Entry

For example, any other trivial Linux can boot directly from a disk/flash drive without having a corresponding UEFI entry or even if it is there, then after deletion I can still boot the system from the disk/flash drive. But Qubes is demanding to write within UEFI, and this is very annoying, because I want to use one instance of Qubes on different devices of the same type, and a separate instance is tied to a specific UEFI record. Why is it so complicated and how can it be changed?

1 Like

If you have Qubes OS 4.2 then update your system.
The default UEFI fallback path was added recently:

1 Like

Thanks for the reply, but nothing is clear. I installed 4.2.1 but the problem still remained. Could you link to a more specific instruction rather than a discussion of something that doesn’t quite relate to my problem?

1 Like

What’s the output of these commands in dom0 terminal?

dnf list grub2-efi-x64
sudo ls -la /boot/efi/EFI/BOOT/

If your grub2-efi-x64 package version is 2.06-3 or higher and /boot/efi/EFI/BOOT/BOOTX64.EFI file is present then you should be able to boot Qubes OS directly from your disk EFI entry.

$ dnf list grub2-efi-x64
Installed Packages
grub2-efi-x64.x86_64                         1000:2.06-2.fc37                         @anaconda

$  sudo ls -la /boot/efi/EFI/BOOT/
total 8
drwx------ 2 root root 4096 Jul 21  2022 .
drwx------ 5 root root 4096 Feb 19 01:10 ..


Update your dom0 and it should work for you.

Do you mean to say after the update I can delete the entry from the uefi?

Yes. But check that you can boot directly from the disk before you delete it.

Okay. And if another linux was installed on the disk first, how will the disk behave? Will the partition that has the boot/esp flag be selected for boot?

If you have another Linux alongside Qubes OS installed on the same disk and this Linux was set as fallback UEFI then after updating grub2-efi-x64 in dom0 it won’t overwrite your other Linux BOOTX64.EFI file but create a separate file BOOTX64.EFI.RPMNEW and you should overwrite BOOTX64.EFI with BOOTX64.EFI.RPMNEW manually if you want to boot Qubes OS when you boot from your disk:

That is considering you’re using the same EFI System partition for both Qubes OS and your other Linux.
I’m not sure what happens if your disk has multiple EFI System partitions.


Okay, I’ll give it a try and write what I got

Yeah (actually it was windows lol)

After the update, all hell broke loose. The computer has become noticeably slower, Qubes has difficulty booting, hanging on the password screen, then booting after a while, but no cubes start. As a result, I had to remove the system completely. On another computer, version 4.2.0 refuses to install packages via qubes-dom0-update: “error loading repository ‘qubes-dom0-current’ has failed” In version 4.2.1, the sleep mode (suspend) does not work correctly. And finally, on the first device where qubes crashed after the update, everything slows down terribly, it took at least 5 minutes before the first window of the qubes installer, although usually it happens instantly. What is this diabolical update?

There was a security patch in Xen recently that patched CPU bugs:

And this noticeable slowed down some old machines.
In some cases this caused inability to use Qubes OS on the machine:

I don’t have an old device. The problems began after the update. Was there a Trojan in the update?)

Today has turned into a nightmare.

What’s your hardware?
Did you have any errors during dom0 update?
Check the dom0 log, maybe there would be some errors.

Not impossible, but it’d be a half-assed one if it’d cause such noticeable effects.

I already had 4.2.1 updated from 4.2.0 but the latest update killed everything

11th generation, NVMe. I didn’t notice any errors, I checked “dnf list grub2-efi-x64”, saw “2.06-3” and rebooted. I’m already trying to put a fresh qubes, no logs. The fresh qubes has been installing for 30 minutes and is stuck on configuring kernelx86_64, and the first stage of installation took me about 5 minutes. The update destroyed the hardware.

I doubt it, but you can check it in your other OS that you have installed alongside your Qubes OS on the same disk.

there are no other OS nearby, I was loading into Live and it was very slow. I would have never believed it either until it happened, right now.