UEFI Boot Entry

qubiq · April 28, 2024, 7:50am

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?

apparatus · April 28, 2024, 7:58am

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

github.com/QubesOS/qubes-issues

Fall back to UEFI shell if Qubes boot entry is missing

opened 09:26AM - 02 Jun 22 UTC

closed 03:55AM - 12 Mar 24 UTC

mehrexe

T: enhancement P: default pr submitted r4.2-host-stable 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.

qubiq · April 28, 2024, 9:47am

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?

apparatus · April 28, 2024, 9:54am

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.

qubiq · April 28, 2024, 11:11am

$ 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 ..

apparatus · April 28, 2024, 11:15am

Update your dom0 and it should work for you.

qubiq · April 28, 2024, 11:16am

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

apparatus · April 28, 2024, 11:18am

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

qubiq · April 28, 2024, 11:21am

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?

apparatus · April 28, 2024, 11:30am

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.

qubiq · April 28, 2024, 11:56am

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

foxyportal · April 28, 2024, 1:59pm

Yeah (actually it was windows lol)

qubiq · April 28, 2024, 6:04pm

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?

apparatus · April 28, 2024, 6:14pm

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:

github.com/QubesOS/qubes-issues

No Qubes/VMs starting - libxenlight failed to create new-domain in 4.2.1

opened 03:32PM - 24 Apr 24 UTC

closed 10:57PM - 26 Apr 24 UTC

scallyob

T: bug C: Xen P: major R: declined diagnosed affects-4.2

[How to file a helpful issue](https://www.qubes-os.org/doc/issue-tracking/) #…## Qubes OS release 4.2.1 ### Brief summary I did a full update on April 23 and rebooted April 24. First reboot since April 1. Now no Qubes/VMs will start. ### Steps to reproduce 1. Update dom0 and all VMs. 2. reboot ### Expected behavior VMs set to autostart start up ### Actual behavior "libxenlight failed to create new-domain" pop ups for sys-net, sys-firewall, etc qvm-ls - shows all VMs halted /var/log/libvirt/libxl/libxl-driver.log shows: > libxl: libxl_dm.c:2857:stubdom_xswait_cb: Domain 1: Stubdom 2 for 1 startup: startup timed out > libxl: libxl_create.c:1975: domcreate_devmodel_started: Domain 1:device model did not start -9 This repeats many times with the Domain # changing (there are also errors related to PCI device, but these are present for previous boots as well and are not new. The errors above do not appear until today in the log.)

qubiq · April 28, 2024, 6:18pm

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

qubiq · April 28, 2024, 6:20pm

Today has turned into a nightmare.

apparatus · April 28, 2024, 6:24pm

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.

qubiq · April 28, 2024, 6:35pm

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.

apparatus · April 28, 2024, 6:48pm

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

qubiq · April 28, 2024, 6:59pm

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.