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

User Support
1

I’ve installed Qubes to a USB from a computer that already had Qubes on its SSD.
Now I can no longer boot to the SSD because the boot option doesn’t show up.
Inspecting the SSD all the files and partitions seem to be intact. I think it is probably just that the EFI partition or a file on it has been marked as not bootable?

I’ve tried the Qubes rescue tools but they didn’t work.

What’s the easiest way to make Qubes boot from the SSD again?

1 Like
2

Solved here: [qubes-users] Boot Menu disappeared after 2-nd Qubes installation. Need Help! - #3 by load_gmail.com

3

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 wrote as well:

    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!

1 Like
4

I must say I can’t really answer these questions as I’m not too familiar with the internal workings of BIOS and EFI, but I would be interested to learn more.

3 Likes
5

Hi!

Last time, I was able to again boot Qubes on my hard drive because I was lucky enough that a black magic trick worked to repair my broken UEFI pointer (efibootmgr with funny options).

Since I did not understand what the trick did, I am afraid it could not work next time. And the question is not if next time will happen but when!

Could somebody explain how this UEFI pointer to Qubes got repaired? (the 3 questions here above).

Thank you so much!

1 Like