Bootloader: After creating EFI boot target, validate it as bootable

[anthonyjmartinez]

Qubes OS version (e.g., R3.1):

3.2

Affected TemplateVMs (e.g., fedora-23, if applicable): N/A

---

Expected behavior:

Successful boot into Qubes R3.2 post-installation

Actual behavior:

• Qubes R3.2 installation completes successfully
• On reboot, 'Qubes' option in UEFI Boot Menu fails in such a way that it appears nothing was attempted.
• UEFI Boot Menu reappears in 1-2s

Steps to reproduce the behavior:

Install R3.2 on Lenovo T460s with an NVMe SSD using https://groups.google.com/forum/#!msg/qubes-users/-xXKdAkIjxU/9wKoF8SHPgAJ as a guide for BIOS setup (though all attempted BIOS configurations result in the same failure to boot)

General notes:

Having tried every suggestion in the UEFI Troubleshooting page on qubes-os.org without success I note the following:

After booting into recovery from the Qubes USB installer efibootmgr -v returns:
Boot0000 Qubes HD(1,0,000...,0x0,0x0)/File(\EFI\qubes\xen.efi)

After installing Ubuntu 16.04.1 LTS just to get a new EFI entry I know is bootable (also using disk encryption and LVM) efibootmgr -v returns:
Boot0001 ubuntu HD(1,GPT,d020fcf2-e75d-429c-8f67-3ba6f556d434,0x800,0x100000)/File(\EFI\ubuntu\shimx64.efi)
Note that even if I delete the UEFI entry for Ubuntu in the BIOS I am still able to boot the OS via the NVMe default entry (protected) and Grub.

---

Related issues:

#794

[andrewdavidwong]

Related: #1782

[andrewdavidwong]

Related: #1782

[cklin]

I experienced the same problem. I think it is caused by an issue mentioned in the UEFI troubleshooting page.

Calling efibootmgr -d /dev/nvme0n1 -p 1 creates a busted UEFI boot entry.
Calling efibootmgr -d /dev/nvme0n1p1 creates a working UEFI boot entry.

The installer probably calls efibootmgr using the first form as opposed to the second. It would be nice if the installer can verify the created UEFI entry does not contain HD(1,0,00000000...0,0x0,0x0), and, if it does, retries with the second form.

[cklin]

I experienced the same problem. I think it is caused by an issue mentioned in the UEFI troubleshooting page.

Calling efibootmgr -d /dev/nvme0n1 -p 1 creates a busted UEFI boot entry.
Calling efibootmgr -d /dev/nvme0n1p1 creates a working UEFI boot entry.

The installer probably calls efibootmgr using the first form as opposed to the second. It would be nice if the installer can verify the created UEFI entry does not contain HD(1,0,00000000...0,0x0,0x0), and, if it does, retries with the second form.

[testaccnta]

Up voting this.
My Specs:
host Apple Mid-2014 i5 16GB
VMware FusionPro 7
NOTE: I installed xfce, whoix gateway + whonixOS, and debian 8 templates during initial install. Ive tried 3.1 and 3.2.

Initial install with 3.1 works however if I begin update process to 3.2 via dom0 AND then reboot after update (NOTE: updates without issue to 3.2.14) it fails. Grub begins the boot process without issue but then seconds later after loading (dmsg info scrolls briefly) then goes blank and permanently hangs. I let the OS attempt to boot up but after 10 minutes of blank screen, I gave up.

Ive attempted this with a fresh 3.2 iso install also and again after grub boots and dmsg info appears and begins to scroll briefly, the install hangs and presents the user with a black blank screen...

It appears with a 3.1 iso install with above specs (VMware FusionPro 7, etc..) I was able to get qubes 3.1 to work but attempting, sudo qubes-dom0-update as per instructions at https://www.qubes-os.org/doc/upgrade-to-r3.2/ I got the confirmation via, yum info qubes-core-dom0, that dom0 had in fact updated to 3.2.14. Great! But I then rebooted via dom0 terminal only to have the screen go black and permanently hang.

[testaccnta]

Up voting this.
My Specs:
host Apple Mid-2014 i5 16GB
VMware FusionPro 7
NOTE: I installed xfce, whoix gateway + whonixOS, and debian 8 templates during initial install. Ive tried 3.1 and 3.2.

Initial install with 3.1 works however if I begin update process to 3.2 via dom0 AND then reboot after update (NOTE: updates without issue to 3.2.14) it fails. Grub begins the boot process without issue but then seconds later after loading (dmsg info scrolls briefly) then goes blank and permanently hangs. I let the OS attempt to boot up but after 10 minutes of blank screen, I gave up.

Ive attempted this with a fresh 3.2 iso install also and again after grub boots and dmsg info appears and begins to scroll briefly, the install hangs and presents the user with a black blank screen...

It appears with a 3.1 iso install with above specs (VMware FusionPro 7, etc..) I was able to get qubes 3.1 to work but attempting, sudo qubes-dom0-update as per instructions at https://www.qubes-os.org/doc/upgrade-to-r3.2/ I got the confirmation via, yum info qubes-core-dom0, that dom0 had in fact updated to 3.2.14. Great! But I then rebooted via dom0 terminal only to have the screen go black and permanently hang.

[qpaz]

+1
confirmed on lenovo thinkpad p50

[qpaz]

+1
confirmed on lenovo thinkpad p50

[anthonyjmartinez]

Update

I am now able to boot Qubes R3.2 on my T460s.

As @cklin mentioned it is necessary to create the UEFI entry with -d /dev/nvme0n1p1 in your efibootmgr call. The method by which I accomplished this was to reboot into recovery mode, mount, and chroot into my new installation. From there I deleted extraneous UEFI entries, and added the new one as such:

efibootmgr -v -c -L Qubes -l /EFI/qubes/xen.efi -d /dev/nvme0n1p1

No additional tweaks were necessary, and I believe this could also be done by dropping to a shell from within the graphical installer prior to rebooting - though I have not explicitly tested this myself.

@andrewdavidwong I believe it would be a step in the right direction to have the portion of the installer responsible for creating UEFI entries validate that the created entry should be bootable. A match of HD(1,0,000...,0x0,0x0) may indicate the entry is invalid and could trigger a new attempt to create an entry that should be more likely too boot like HD(1,GPT,d020fcf2-e75d-429c-8f67-3ba6f556d434,0x800,0x100000)

[anthonyjmartinez]

Update

I am now able to boot Qubes R3.2 on my T460s.

As @cklin mentioned it is necessary to create the UEFI entry with -d /dev/nvme0n1p1 in your efibootmgr call. The method by which I accomplished this was to reboot into recovery mode, mount, and chroot into my new installation. From there I deleted extraneous UEFI entries, and added the new one as such:

efibootmgr -v -c -L Qubes -l /EFI/qubes/xen.efi -d /dev/nvme0n1p1

No additional tweaks were necessary, and I believe this could also be done by dropping to a shell from within the graphical installer prior to rebooting - though I have not explicitly tested this myself.

@andrewdavidwong I believe it would be a step in the right direction to have the portion of the installer responsible for creating UEFI entries validate that the created entry should be bootable. A match of HD(1,0,000...,0x0,0x0) may indicate the entry is invalid and could trigger a new attempt to create an entry that should be more likely too boot like HD(1,GPT,d020fcf2-e75d-429c-8f67-3ba6f556d434,0x800,0x100000)

[andrewdavidwong]

@anthonyjmartinez: Thanks for reporting back with your solution!

@marmarek: Can the installer be patched in the manner @anthonyjmartinez describes?

[andrewdavidwong]

@anthonyjmartinez: Thanks for reporting back with your solution!

@marmarek: Can the installer be patched in the manner @anthonyjmartinez describes?

[marmarek]

@marmarek: Can the installer be patched in the manner @anthonyjmartinez describes?

Most likely yes. Relevant code is here: https://github.com/QubesOS/qubes-installer-qubes-os/blob/master/anaconda/pyanaconda/bootloader.py#L1752-L1769
I wonder how does it work on plain Fedora - it looks they don't have the modification discussed here.

[marmarek]

@marmarek: Can the installer be patched in the manner @anthonyjmartinez describes?

Most likely yes. Relevant code is here: https://github.com/QubesOS/qubes-installer-qubes-os/blob/master/anaconda/pyanaconda/bootloader.py#L1752-L1769
I wonder how does it work on plain Fedora - it looks they don't have the modification discussed here.

[andrewdavidwong]

Ok, I've converted this from a bug report into a feature request to implement @anthonyjmartinez's proposed solution.

@anthonyjmartinez: Any interest in taking this on?

[andrewdavidwong]

Ok, I've converted this from a bug report into a feature request to implement @anthonyjmartinez's proposed solution.

@anthonyjmartinez: Any interest in taking this on?

[anthonyjmartinez]

@andrewdavidwong - I'm wondering now if this isn't more of an upstream fix that should happen in anaconda? Validation of the execution parameters passed to efibootmgr ought to take place before the call is ever made. I don't know that I have the resources, or frankly the skills, to create a robust solution that works across devices and isn't limited to what I've found to work for a T460s with a 950 Pro NVMe SSD.

[anthonyjmartinez]

@andrewdavidwong - I'm wondering now if this isn't more of an upstream fix that should happen in anaconda? Validation of the execution parameters passed to efibootmgr ought to take place before the call is ever made. I don't know that I have the resources, or frankly the skills, to create a robust solution that works across devices and isn't limited to what I've found to work for a T460s with a 950 Pro NVMe SSD.

[andrewdavidwong]

@anthonyjmartinez: Fair enough.

[andrewdavidwong]

@anthonyjmartinez: Fair enough.

[elimisteve]

efibootmgr -v -c -L Qubes -l /EFI/qubes/xen.efi -d /dev/nvme0n1p1

That command also worked for me on my T460s. Just wanted to add how exactly I was able to get to the point where I could run that command in case it's unclear to some people:

1. Reboot
2. Press as laptop is booting to change how it boots up
3. Select your USB flash drive (that you just used to install Qubes from) from the menu
4. Of the 4 options listed, select the last -- "Rescue a Qubes system"
5. Wait a few seconds for it to boot up, then in the rescue prompt, press 3 then
6. Type the command above: efibootmgr -v -c -L Qubes -l /EFI/qubes/xen.efi -d /dev/nvme0n1p1
7. Type "exit" then press

Your T460s should now boot into Qubes 🎉.

[elimisteve]

efibootmgr -v -c -L Qubes -l /EFI/qubes/xen.efi -d /dev/nvme0n1p1

That command also worked for me on my T460s. Just wanted to add how exactly I was able to get to the point where I could run that command in case it's unclear to some people:

1. Reboot
2. Press as laptop is booting to change how it boots up
3. Select your USB flash drive (that you just used to install Qubes from) from the menu
4. Of the 4 options listed, select the last -- "Rescue a Qubes system"
5. Wait a few seconds for it to boot up, then in the rescue prompt, press 3 then
6. Type the command above: efibootmgr -v -c -L Qubes -l /EFI/qubes/xen.efi -d /dev/nvme0n1p1
7. Type "exit" then press

Your T460s should now boot into Qubes 🎉.

[johnfzc]

I've tested the installer included with the 4.0 alpha r1 release and it does not suffer from this issue. It's important that you select option 3 when rescuing your system, mounting read only will prevent you from running the efibootmgr command.

[johnfzc]

I've tested the installer included with the 4.0 alpha r1 release and it does not suffer from this issue. It's important that you select option 3 when rescuing your system, mounting read only will prevent you from running the efibootmgr command.