Cannot boot from SSD after installing a secondary Qubes to a USB disk

[katiehill]

Yesterday, I had the same problem, except that the solution presented in the link here above (efibootmgr -v -c -L Qubes -l /EFI/qubes/xen.efi -d /dev/nvme0n1p1) did NOT work for me.

Instead, I got something like:

************************************************** ****
Warning! This MBR disk does not have a unique signature.
If this is not the first disk found by EFI, you may not be able
to boot from it without a unique signature.
Run efibootmgr with the -w flag to write a unique signature
to the disk.
************************************************** ****

What worked for me (if I remember correctly) was:

efibootmgr -v -c -d /dev/nvme0n1 -p 1 -w -L Qubes -l /EFI/qubes/xen.efi

with (from man efibootmgr):

-v | --verbose
Verbose mode - prints additional information
-c | --create
Create new variable bootnum and add to bootorder
-d | --disk DISK
The disk containing the loader (defaults to /dev/sda )
-p | --part PART
Partition number containing the bootloader (defaults to 1)
-w | --write-signature
> write unique signature to the MBR if needed
-L | --label LABEL
Boot manager display label (defaults to “Linux”)
-l | --loader NAME
Specify a loader (defaults to \elilo.efi )

I was wondering:

1. What changes were made (at which place) when we installed Qubes on an USB, making our main Qubes installation on our SSD later unbootable?

2. Which exact signature does the error message refers to? And how does the -w option exactly help to fix it?

3. What is the 1st step in the boot process? I mean: How does the BIOS know where all the EFI partitions containing bootloaders (such as the one containing xen.efi) are?

   I guess the answer to this 3rd question (how does the BIOS UEFI gets to xen.efi?) is the step before the ones presented by @icequbes1 in his very interesting post:

   @icequbes1

   Boot order on R4.0 with UEFI:

   [BIOS/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
   

   @icequbes1 wrote as well:

   @icequbes1

   it depends on your BIOS implementation on how it decides to find/boot EFI loaders

   But then, if this step is not standard, how does efibootmgr know how to fix the problem?

As a detailed understanding of the processes help to better fish alone, thank you so much for your explanations!