I have an odd problem that I have never come across before. First off, the hardware:

HP x360 Spectre Kaby Lake (i7-7500u) Ubuntu 17.10 64bit

The laptop dual boots between Windows and Ubuntu. In setup, I have Ubuntu as the default so I could choose between Windows or Ubuntu from grub. However, when I turn on my laptop, or reboot, the system goes to Grub as expected, but then freezes. The countdown timer stays at 10 seconds and it takes no input.

The weird part is, if I press F9 to bring up the UEFI boot menu, and select the first entry (Ubuntu), grub loads and works fine. I can't figure out what the difference is to have setup boot the Ubuntu EFI entry without my intervention compared to me selecting it from F9 boot menu.

Update: Adding additional info

Files under /boot/efi:

root@localhost:/boot/efi# find .
./System Volume Information
./System Volume Information/IndexerVolumeGuid

For gdisk, I'm assuming this is what is requested?

root@localhost:/boot/efi# gdisk /dev/nvme0n1
GPT fdisk (gdisk) version 1.0.1

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.

Command (? for help): p
Disk /dev/nvme0n1: 1000215216 sectors, 476.9 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): A2E05477-2E06-47DD-865C-60C3C58F9E7B
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 1000215182
Partitions will be aligned on 2048-sector boundaries
Total free space is 12909 sectors (6.3 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048          534527   260.0 MiB   EF00  EFI system partition
   2          534528          567295   16.0 MiB    0C01  Microsoft reserved ...
   3          567296       768909311   366.4 GiB   0700  Basic data partition
   4       975620096       977627135   980.0 MiB   2700  Basic data partition
   5       977627136      1000204287   10.8 GiB    0700  Basic data partition
   6       768909312       975620095   98.6 GiB    8300  

Command (? for help): 

Output of fdisk for good measure:

root@localhost:/boot/efi# fdisk --list
Disk /dev/nvme0n1: 477 GiB, 512110190592 bytes, 1000215216 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: A2E05477-2E06-47DD-865C-60C3C58F9E7B

Device             Start        End   Sectors   Size Type
/dev/nvme0n1p1      2048     534527    532480   260M EFI System
/dev/nvme0n1p2    534528     567295     32768    16M Microsoft reserved
/dev/nvme0n1p3    567296  768909311 768342016 366.4G Microsoft basic data
/dev/nvme0n1p4 975620096  977627135   2007040   980M Windows recovery environmen
/dev/nvme0n1p5 977627136 1000204287  22577152  10.8G Microsoft basic data
/dev/nvme0n1p6 768909312  975620095 206710784  98.6G Linux filesystem

Partition table entries are not in disk order.
  • Its most likely that GRUB is missing one of its stages for the one that freezes and there may be a different GRUB loading with UEFI or it's using stub. There's a lot that could cause that. It would help to get a full list of the files under your EFI system partition and the output of gdisk when it first opens. – jdwolf Oct 21 '17 at 1:13
  • @jdwolf , added extra info per request. – fog Oct 21 '17 at 3:13
  • Alright MBR is protective so there is no legacy boot rom in it at least. That rules out some weird leftover from non-EFI grub. – jdwolf Oct 21 '17 at 3:16
  • Just to rule it out could you try disabling the CSM? ESP looks okay. – jdwolf Oct 21 '17 at 3:21
  • Just checked my bios, no option for disabling CSM (very limited BIOS). – fog Oct 21 '17 at 4:43

Unfortunately, Boot Repair doesn't handle NVMe disks properly, so a bunch of important information is missing from your BootInfo report; however, it does show a single ubuntu entry in the NVRAM boot manager list, so it's unlikely that the system is booting through some other path -- EXCEPT that you have a fallback boot loader (EFI/BOOT/bootx64.efi) that, from the other file in that directory (fbx64.efi), is probably a tool to recover the boot setup in case of a firmware failure. This tool, and how to configure and use it, is described in my rEFInd documentation (although it's not part of rEFInd; that page just has the most complete and concise description of fbx64.efi that I know about):


It's possible that your computer is losing its boot order variable, booting through Shim (as EFI/BOOT/bootx64.efi) and fbx64.efi, which then kicks the boot process over to the regular ubuntu entry (which launches a second Shim and then GRUB), which then hangs; but when the ubuntu entry launches directly, it works fine. This could happen because of bugs involving two copies of Shim being launched, because fbx64.efi itself is causing problems, or for some other reason. This hypothesis is very speculative; it's based on very little evidence and quite a few assumptions. It also assumes bugs in your firmware, and likely in Shim, fbx64.efi, and/or GRUB. It is consistent with the symptoms you're seeing, though, and it's the only explanation that springs to mind. If it's what's happening, you could try, as diagnostic procedures or to fix the problem:

  • Rename the EFI/BOOT directory on the ESP -- If you rename this directory and the problem persists exactly as it has, then my hypothesis is wrong. (This is because renaming EFI/BOOT will prevent the computer from attempting to launch the Shim and fbx64.efi stored in that directory; so if it keeps booting, it must be that the boot order and boot variables are being retained and honored, contrary to my hypothesis.) If, however, the computer begins booting correctly, or booting straight to Windows, then that's evidence that it had been booting in this way, and my hypothesis becomes much more likely. You should be able to rename the directory back to EFI/BOOT to restore the (failing) boot operation, which will be necessary for the next three repairs....
  • Disable Secure Boot -- Disabling Secure Boot will alter the way Shim works, and if my hypothesis is correct, this might get things working -- or it might have no effect. Even if my hypothesis is correct, this change will work only if the failure is caused by Secure Boot, which might not be the case.
  • Copy EFI/ubuntu/grub* to EFI/BOOT -- If you copy GRUB (grubx64.efi) and its configuration file (grub.cfg) from EFI/ubuntu to EFI/BOOT, then Shim in EFI/BOOT (that is, EFI/BOOT/bootx64.efi) should launch GRUB directly from EFI/BOOT, rather than going through fbx64.efi. This should bypass the problem, if my hypothesis is correct.
  • Use rEFInd -- My rEFInd boot manager boots in an entirely different way from GRUB, so chances it won't be affected by the problem. With Secure Boot active, though, you'll need to enroll a key or two in your MOK list, as described in the rEFInd Secure Boot documentation. Also, you may need to delete or rename the EFI/ubuntu/BOOTX64.CSV file on your ESP. (Rename it to something with a filename that does not end in .CSV, or any case-altered variant of that, like .csv.) The reason is that fbx64.efi looks for .CSV files to regenerate the NVRAM-based boot entry, so if that file is present, there's a 50/50 chance it will take precedence over the BOOT.CSV file that rEFInd creates for itself, thus causing the system to boot to GRUB and continue failing in the way you describe.
  • Update your firmware -- If your manufacturer offers a newer firmware (probably called a "BIOS") than what you're using now, you can upgrade it. This is a shot in the dark, though; your problem sounds exotic enough that it's unlikely to have been addressed in a firmware update.

I recommend you try the first of these options as a diagnostic. If the boot behavior changes as I've described, you can then restore EFI/BOOT to the way it had been and try any of the next three options -- or more than one, if your first attempt fails. If, OTOH, renaming EFI/BOOT has no effect, then the next two options are unlikely to work (although disabling Secure Boot might help). Installing rEFInd becomes the option that's most likely to work in this case, but that's really a shot in the dark. Updating the firmware might work even if the first diagnostic option doesn't change the behavior, but as I said, that's a desperate option that's unlikely to work no matter what the cause is. Still, it's worth trying if you have no other options (or maybe even if you do -- firmware updates can fix all sorts of problems, add features, and improve performance).

Good luck fixing your problem!

  • Was never able to fix the issue myself. However, some recent update within the past few weeks fixed the issue for me. No longer does it freeze. – fog Jan 23 '18 at 22:43
  • Had almost the same problem on an ASUS ZenBook 13 UX333FN. Your tip 'update your firmware' saved my day! After the bios-update ubuntu started working again. Thanks. – Kapitein Witbaard Aug 1 at 12:58

It would seem the issue is multiple installations of GRUB mismatch. GRUB installed at /EFI/ubuntu/grubx64.efi is nonworking while GRUB installed at /EFI/Boot/bootx64.efi is.

You should be able to correct this by reinstalling GRUB to ESP.

sudo grub-install --efi-directory=/boot/efi /dev/sda

  • EFI/ubuntu/grubx64.efi is GRUB, but EFI/BOOT/bootx64.efi is most likely Shim. The message described (Selected boot image did not Authenticate) indicates a Secure Boot problem, and I'm 80% sure it's a message from the firmware. This is understandable and expected if Secure Boot is enabled and you try to launch GRUB directly, which your diagnostic procedure had fog do. In fact, the two failures (booting without intervention and booting GRUB directly) produce different symptoms, so you're likely on a wild goose chase with this solution; but maybe re-installing GRUB will fix it by chance. – Rod Smith Oct 21 '17 at 14:52
  • I agree the message is related to secure boot. The OP indicates he has a dual boot system with Windows which is itself booting. Because of that shim (which loads grub) should also be working. However UEFI should not contain entries launching unsigned grub directly or for that matter unsigned grub at all. Since grub is verified BY the shim and the shim loads my thinking was to first try Ubuntus built in method for installing grub: grub-install. If you have a suggestion on how to mentally tweak the signing process Ubuntu uses in a way that's compatible go right ahead and edit my answer. – jdwolf Oct 21 '17 at 15:50
  • Should this be: sudo grub-install --efi-directory=/boot/efi /dev//dev/nvme0n1 ? One other small note, this is new notebook, and the first time I've installed any other OS on it, so it's not as if I had installed a bunch of other distros first creating multiple UEFI entries. – fog Oct 21 '17 at 19:04

I had the exact same problem on the exact same hardware model. As the original poster noted, the problem goes away after an update is applied. Unfortunately, the problem reappears. The fix is to disable secure boot following the instructions on this page: https://support.hp.com/us-en/document/c04784866

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.