Is there a post explaining the BIOS settings for Qubes, other than UEFI is not preferred, (and bios should support virtualization features mentioned in the hardware requirements page)?
I had a Qubes installation working good, running from USB drive. I had played with UEFI Bios options for it to work: enable the two Intel hardware virtualization features, no secure boot, no raid, no hyper-threading.
I reset the bios configuration to defaults, and USB drive is no longer recognized as an option in the boot menu.
The EFI entries are stored in NVRAM and after you reset your BIOS they were removed as well.
So you’ll have to restore your EFI entry by booting from another system and running this command, assuming that /dev/sda is your Qubes drive and 1 is your EFI System partition number: efibootmgr -v -c -u -L QubesOS -l /EFI/qubes/grubx64.efi -d /dev/sda -p 1
If you’re asking which BIOS options do you have to set to be able to boot from your Qubes USB drive then the answer is none (almost certainly). Missing Qubes boot option in your BIOS has nothing to do with you BIOS options being misconfigured, you need to restore your EFI entry.
I encountered again this issue. Linux is installed in one disk, and Qubes in another disk. Both OSes were working just fine.
Until today that selecting the Qubes entry in the EFI boot menu brings up “grub>” she’ll prompt, and Qubes doesn’t boot. I deleted the Qubes entry and added it again, by issuing the command above. The entry is added, but Qubes doesn’t boot, I end up in the grub shell.
Maybe your grub config in missing in your Qubes OS EFI partition for some reason.
You can try to boot from your other Linux OS and check the grub config content in: /boot/efi/EFI/qubes/grub.conf
If the file is missing or the content is not what it should be then you’ll need to mount and chroot to your Qubes OS from your Linux OS and regenerate the grub config.
Disk is encrypted, and I enter grub shell before even being asked for the LUKS password. With LUKS, boot is also encrypted. Then, it should be related to the files in the EFI partition in unencrypted form.
/boot/efi/EFI/qubes/grub.conf is file stored on EFI System partition, the path in partition should be /EFI/qubes/grub.conf.
If it’s corrupted/missing then to regenerate it you’d need to decrypt your Qubes OS disk, mount it and chroot into your Qubes OS.
File grub.cfg is a readable text file. The Linux has a similar system partition, except that the BOOT directory is not empty, instead of xen-4.17.2.efi I have shimx64.efi, and there are additional files, like, mmx64.efi.
Also maybe you’ve selected wrong drive name or partition number in the command?
Did you make sure that your Qubes OS drive was /dev/sda when you run this command? efibootmgr -v -c -u -L QubesOS -l /EFI/qubes/grubx64.efi -d /dev/sda -p 1
The location and command I are correct . The grub.cfg file is just 3 lines.
After searching fedora forums, I might have to backup and copy grub.cfg.rpmssve (mentioned above, which looks like what you linked) to grub.cfg, boot and if successful install grub in fedora?
I copied grub.cfg.rpmsave grub.cfg and booted. This time, the grub shows Qubes booting options: boot the Xen hypervisor, and boot in recovery mode. Selecting either leads to: fail to find the xen compressed images, you should load the kernel first.
The kernel images are in encrypted LUKS partition. It has to first ask me for password to unlock the p3 partition, and it doesn’t.
In full disk encryption, in Linux in general and Qubes as well, the kernel images are encrypted. I selected encrypt the disk in Qubes , so yeah, all I see preboot via grub command line in system partitions, for both operating systems, are EFI and grub .efi and .cfg files, and similar config files, but no kernel image in plaintext.
Is there a tutorial for the change root option that you mentioned, see how /EFI/Qubes files can be regenerated?
If you have default Qubes OS partitioning then you should have 3 partitions e.g.:
/dev/sda1 - EFI System partition
/dev/sda2 - ext4 /boot partition - this partition in unencrypted by default and should contain your initramfs that grub is looking for
/dev/sda3 - LUKS encrypted LVM partition
So check your /boot partition content and check its UUID, compare it with the UUID and files that grub is looking for.
This seems to be a bug, somehow triggered under some circumstances. See the post that I linked above.
In UEFI bios window options, there is a possibility to “Add a Bios Option”. That shows all available drives in the computer. For each drive, one could browse the system partition and see the available files. I essentially have two relevant files: grub.cfg and grubx86.efi. I selected both and each time defined a new boot option. I always end up with the grub shell. My system partition has a EFI folder that contains just a few config files. The kernel images are encrypted, and not there.
Do you have a link to a tutorial to regenerate /EFI files (by booting via a second OS and change root)?
Before that clarify whatever you’ve encrypted your /boot partition specifically e.g. like this or not:
If you didn’t do this specifically and you have default Qubes OS partitioning that was done by Qubes OS installer automatically then you should have unencrypted /boot partition.
In that case the problem is somewhere in your /boot partition and not your EFI partition or grub config.
I have used the Qubes installer with the default settings, and the partitions were created automatically.
It looks like that the Qubes update did not generate initramfs images. As the problem has been better clarified and is not a Bios issue, I created a new post clarifying this issue here. Other users encountering this problem can better find it: