Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

anthonyjmartinez opened this issue Oct 16, 2016 · 12 comments


Copy link

@anthonyjmartinez anthonyjmartinez commented Oct 16, 2016

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


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!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 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:


Copy link

@andrewdavidwong andrewdavidwong commented Oct 17, 2016

Related: #1782

Copy link

@cklin cklin commented Oct 17, 2016

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.

Copy link

@testaccnta testaccnta commented Oct 17, 2016

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

Copy link

@qpaz qpaz commented Nov 2, 2016

confirmed on lenovo thinkpad p50

Copy link

@anthonyjmartinez anthonyjmartinez commented Nov 7, 2016


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 andrewdavidwong added C: installer and removed C: core labels Nov 8, 2016
Copy link

@andrewdavidwong andrewdavidwong commented Nov 8, 2016

@anthonyjmartinez: Thanks for reporting back with your solution!

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

Copy link

@marmarek marmarek commented Nov 16, 2016

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

Most likely yes. Relevant code is here:
I wonder how does it work on plain Fedora - it looks they don't have the modification discussed here.

@andrewdavidwong andrewdavidwong changed the title Unable to boot R3.2 with UEFI + NVME SSD Bootloader: After creating EFI boot target, validate it as bootable Nov 19, 2016
Copy link

@andrewdavidwong andrewdavidwong commented Nov 19, 2016

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?

Copy link

@anthonyjmartinez anthonyjmartinez commented Nov 24, 2016

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

Copy link

@andrewdavidwong andrewdavidwong commented Nov 25, 2016

@anthonyjmartinez: Fair enough.

Copy link

@elimisteve elimisteve commented Apr 17, 2017

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

Copy link

@johnfzc johnfzc commented Apr 29, 2017

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
8 participants