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

Closed
anthonyjmartinez opened this Issue Oct 16, 2016 · 12 comments

Comments

Projects
None yet
8 participants
@anthonyjmartinez

anthonyjmartinez commented Oct 16, 2016

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

This comment has been minimized.

Member

andrewdavidwong commented Oct 17, 2016

Related: #1782

@cklin

This comment has been minimized.

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.

@testaccnta

This comment has been minimized.

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

This comment has been minimized.

qpaz commented Nov 2, 2016

+1
confirmed on lenovo thinkpad p50

@anthonyjmartinez

This comment has been minimized.

anthonyjmartinez commented Nov 7, 2016

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

@andrewdavidwong

This comment has been minimized.

Member

andrewdavidwong commented Nov 8, 2016

@anthonyjmartinez: Thanks for reporting back with your solution!

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

@marmarek

This comment has been minimized.

Member

marmarek commented Nov 16, 2016

@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 andrewdavidwong changed the title from Unable to boot R3.2 with UEFI + NVME SSD to Bootloader: After creating EFI boot target, validate it as bootable Nov 19, 2016

@andrewdavidwong andrewdavidwong added enhancement and removed bug labels Nov 19, 2016

@andrewdavidwong

This comment has been minimized.

Member

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?

@anthonyjmartinez

This comment has been minimized.

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.

@andrewdavidwong

This comment has been minimized.

Member

andrewdavidwong commented Nov 25, 2016

@anthonyjmartinez: Fair enough.

@elimisteve

This comment has been minimized.

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

@johnfzc

This comment has been minimized.

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