Update #4: As predicted resetting the boot order didn't work: sudo efibootmgr -o 4,0,1,2 did nothing.

Update #3: See bottom

Update #2: Might be because of HP's issue. Please see Rod's answer. This question remains unresolved.

Update: I did Boot-Repair and it didn't work. See the bottom section for details.

I just installed Ubuntu 16.04.2 LTS on a new 2017 HP EliteBook with a Ubuntu boot USB. I erased the Windows on it to just have Ubuntu. However the startup (see more info about the UEFI below) couldn't find an operating system unless I put the USB in.

So based on this answer I tried:

sudo grub-install /dev/sda

But I got the error:

Installing for i386-pc platform.
grub-install: error: failed to get canonical path of `aufs'.

Then I tried a suggestion from this answer which gave the same error.

sudo grub-install /dev/sda2

Because I wanted to actually install it on my hard drive, which is identified by:

sudo fdisk -l

Device      ... Size       Type
/dev/sda1       512M       EFI System
/dev/sda2       208.1G     Linux filesystem
/dev/sda3       15G        Linux swap

But I could not grep for boot in sudo fdisk -l.

I think the problem might be my root, /, is on aufs, based on this command:

> df
Filesystem   .. ... Mounted on

udev                /dev
aufs                /

More info:

  • The laptop has a 200 GB SSD
  • When I installed Ubuntu it gave me a warning saying UEFI might damage the BIOS operating systems. I left the boot as Hybrid Boot instead of Legacy because if I use Legacy it doesn't even recognize the Ubuntu USB drive. Then I force installed UEFI during the Ubuntu installation. (When it still had Windows 10 it might have been using BIOS, I couldn't get a definitive answer.)

Update: I tried boot-repair with the "install boot-repair in Ubuntu" option, got this paste2, shut down, took out my USB, turned on, and got:

BootDevice Not Found

Please install an operating system on your hard disk.

What should I do now?

Update #3:

Here are the results of sudo efibootmgr and df in Try Ubuntu with USB plugged in.

<code>sudo efibootmgr</code> and <code>df</code> in Try Ubuntu


  1. Clearly I should change so that the boot order does not go to USB first and Ubuntu last. How do I move it up?

  2. If there might be problems with the .efi file. I'm confused of what exactly I should rename and how. Currently I have my boot USB mounted at /cdrom. But in /cdrom/EFI there is only BOOT. Inside /cdrom/EFI/BOOT there are these files:


    2a. Should I somehow change the SUB mount from /cdrom to /mnt?

    2b. Which file should I rename and into what? Because ...

    ubfan1 says "rename the /EFI/ubuntu/shimx64.efi to /EFI/ubuntu/bootmgfw.efi

    "As a fallback, which I recommend, set up the disk bootloader, /EFI/Boot/bootx64.efi as a copy of /EFI/ubuntu/shimx64.efi. Since shimx64.efi needs grubx64.efi in the same directory, copy /EFI/ubuntu/grubx64.efi to /EFI/Boot/grubx64.efi

    "You did find the exact same setup used on the install media -- the /cdrom/EFI/BOOT/BOOTx64.efi is actually a copy of shimx64.efi. This is how the install media boots using its default bootloader in UEFI mode.


    Rod Smith says in a comment "you must look into the hackish workaround of renaming your primary boot loader or boot manager file as EFI/BOOT/bootx64.efi".

    I'm confused

  • You could try to use Boot-Repair, which is described at the same link you used (but another answer), askubuntu.com/questions/125494/… . See also this link, help.ubuntu.com/community/Boot-Repair – sudodus Mar 18 '17 at 17:00
  • sudodus, please see my update. Boot-Repair didn't work. Thanks. – Melissa Mar 18 '17 at 21:06
  • The boot info script 'thinks' that is was successful. I don't know why it failed, but things can be complicated in UEFI mode. If this is a fresh system without any personal data saved, I think the third option in @Rod Smith's answer is the best: re-install Ubuntu. I would try to set the computer to boot in BIOS mode, and install Ubuntu in BIOS mode. Other people will probably recommend that you install in UEFI mode. Both should work. My son has an old Elitebook, that works well in BIOS mode, but I don't know about the new Elitebooks. – sudodus Mar 19 '17 at 3:13
  • Try fixing the boot according to @ubfan1's answer before starting to re-install. :-) – sudodus Mar 19 '17 at 3:25
  • Thanks sudodus, I ran into problems too. Please see my comments to his answer. – Melissa Mar 19 '17 at 3:27
sudo grub-install /dev/sda

But I got the error:

Installing for i386-pc platform.
grub-install: error: failed to get canonical path of `aufs'.

Whether you know it or not, passing the /dev/sda device to grub-install implies installation of the BIOS-mode version of GRUB. (Of course, you may have passed that option in error.) Likewise, the response that GRUB is trying to install for the i386-pc platform also implies a BIOS-mode GRUB installation. I don't know offhand what the failed to get canonical path ofaufs'` message means. The BIOS-mode version of GRUB, though, is critical, because....

sudo fdisk -l

Device      ... Size       Type
/dev/sda1       512M       EFI System
/dev/sda2       208.1G     Linux filesystem
/dev/sda3       15G        Linux swap

The presence of an EFI System Partition (ESP) implies that the disk is set up for booting in EFI mode, not in BIOS mode. (As a side note, you've clearly cut lines of output from your fdisk command. You should not do this when you're asking for help. These lines might be helpful in diagnosing your problem, although they're probably redundant in this specific case.)

The vast majority of new computers today ship configured to boot in EFI mode by default. You can enable BIOS/CSM/legacy-mode support in the firmware, and some Ubuntu and Linux installation instructions recommend doing so; however, in most cases this is bad advice. See my page on the subject for information on why. It's unclear if you've made these changes yourself; the apparent presence of the BIOS-mode version of GRUB in your Ubuntu installation suggests you've installed in BIOS mode; however, the disk partitioning suggests you've installed in EFI mode.

Since this is a new installation, my recommendation is to configure your firmware to boot only in EFI mode and to then install an EFI-mode boot loader. There are many ways to do this. The three easiest are:

  • Use Boot Repair -- If you can get an Ubuntu emergency disk to boot in EFI mode, it should be able to re-install GRUB (in EFI mode) and you'll be good to go. The Boot Repair tool can do this semi-automatically; however, you must run it from an EFI-mode boot to be successful. If you switched to a BIOS-mode boot to work around problems booting the Ubuntu installation medium, you may need to re-create your Ubuntu installation medium or otherwise work around that boot problem first. See my page on the CSM, referenced earlier, for more on this subject.
  • Use rEFInd -- You can boot the computer using the CD-R or USB flash drive version of my rEFInd boot manager. (Download links for both are on that page.) Once you've booted, you can install the rEFInd Debian package or PPA. You should then be able to reboot and use rEFInd, rather than GRUB, to control the boot process.
  • Re-install Ubuntu -- If you reconfigure (if necessary) the firmware to boot in EFI mode and can get the installer to boot in that mode, re-installing Ubuntu is another option. This is overkill, but it may be easier than trying to fix your current installation, given that it's new.


From your Boot Repair output, there are some clues to the cause of the problem:

File system:       vfat
Boot sector type:  FAT32
Boot sector info:  No errors found in the Boot Parameter Block.
Operating System:  
Boot files:        /EFI/Boot/bootx64.efi /EFI/ubuntu/MokManager.efi 
                   /EFI/ubuntu/fwupx64.efi /EFI/ubuntu/grubx64.efi 

Note in particular the presence of Microsoft boot files (/EFI/Microsoft/Boot/bootmgfw.efi and /EFI/Microsoft/Boot/bootx64.efi). These files suggest that you did not delete the ESP, so the Windows boot loader files seem to be lurking alongside your Ubuntu installation. Also, check the efibootmgr output:

=================== efibootmgr -v
BootCurrent: 0000
Timeout: 0 seconds
No BootOrder is set; firmware will attempt recovery
Boot0000* USB Hard Drive 1 - Generic Mass Storage   BBS(HD,,0x900).......................................................................
Boot0001* Notebook Hard Drive   BBS(HD,,0x0).......................................................................
Boot0002* Notebook Ethernet BBS(128,,0x0).......................................................................
Boot0003* Windows Boot Manager  HD(1,GPT,2c19863f-1ed0-476e-a8e9-6d316ca2c4bb,0x800,0x32000)/File(EFIMicrosoftBootbootmgfw.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.}...a................
Boot0004* ubuntu    HD(1,GPT,17667422-8dfe-45ba-9baa-5458a67b71db,0x800,0x100000)/File(EFIubuntushimx64.efi)

The Windows boot entry is still present there, too, which isn't surprising; however, the truly messed-up bit is the report that No BootOrder is set; firmware will attempt recovery. A working EFI relies on a variable called BootOrder to identify the order in which boot loaders will be run. This variable is absent on your computer. I've seen the same problem on a rather old HP 6470b laptop that I own, and no matter what I try, I've been unable to create this variable. In any event, the likely result is that the computer is trying to launch either the fallback boot loader (EFI/BOOT/bootx64.efi) or the Microsoft boot loader (EFI/Microsoft/Boot/bootmgfw.efi). If the boot loader launched is the original Microsoft boot loader, then it would flake out at this point because Windows is not installed. If you've copied something else to those files (knowingly or not), it might flake out if its support files aren't also present.

Since you say your computer is new, my first recommendation is to return the computer to the store for a refund and buy something else. The problem may be a sample defect (a bad NVRAM chip or the like), or it could be a bug in HP's firmware. If the former, a new version of the same computer might work; but if it's buggy firmware, a new computer will do nothing. (OTOH, if it's buggy firmware, there's a slim chance that a firmware update will fix the problem. Resetting the firmware options to their defaults might also help.) If you return the computer to the store for a refund, be sure to tell HP you did that, and why. Manufacturers will continue selling defective products unless they're made aware of the fact that they're doing so, and they take some pain (in the form of returns) for doing so.

If you refuse to get a non-broken computer, you must deal with it. The best way is to delete those Windows boot loader files from the ESP and to copy GRUB to the fallback filename of EFI/BOOT/bootx64.efi. (There's already a file in that location, but it's not clear if that's another copy of GRUB, another copy of the Windows boot loader, or something else.) You'll need to copy grub.cfg and perhaps other files from EFI/ubuntu to EFI/BOOT, too. If you use Boot Repair, there's an option on its Advanced page that will do this semi-automatically.


You can change the boot order using the -o option to efibootmgr, as in:

sudo efibootmgr -o 4,0,1,2

This example should keep the existing boot entries shown, but add the ubuntu entry to the front. In theory, this will make GRUB the default boot program, and everything should then start working. You can learn more about efibootmgr by typing man efibootmgr. (The same trick works for other commands; for instance, man ls will tell you about the ls command.)

That said, the fact that you had a non-existent BootOrder variable at the start makes me skeptical this will work; I suspect there's something flaky about your EFI that will cause it to fail. (Both the original Ubuntu installation and Boot Repair should have added the ubuntu entry to the start of the BootOrder variable, assuming they were run in EFI mode -- and the Boot Repair output you showed revealed no BIOS-mode boot loader on your disk, which implies they were run in EFI mode.)

There are two EFI System Partition(s), or partitions that fill that purpose, on your system, and I think you're getting them confused:

  • On the hard disk -- The ESP on your hard disk is /dev/sda1, according to your Boot Repair output. This partition should be mounted at /boot/efi when you boot the Ubuntu on your hard disk; but when you use the Ubuntu installation medium in "try before installing" mode, it either won't be automatically mounted or it will be mounted somewhere else, in a subdirectory of /media, IIRC.
  • On the installation medium -- It's not technically an ESP, but /dev/sdb1 on your installation medium serves the same role. It contains an EFI/BOOT directory with various boot files. Adjusting these files is pointless at best, at least in your case, because you want to get the system booting to the installed OS without using your installation medium.

If you're booted with the installation disk, modifying files on your hard disk's ESP requires mounting the ESP and then modifying those files. You'd do something like this:

sudo mkdir -p /mnt/foo
sudo mount /dev/sda1 /mnt/foo
cd /mnt/foo/EFI
sudo mv Boot Boot-old
sudo cp -r ubuntu BOOT
sudo mv BOOT/shimx64.efi BOOT/bootx64.efi

Note that typos (by me or by you) could make these commands fail to work as expected, and such a mistake could even make matters worse. If it works, this sequence of commands will copy Shim (which handles Secure Boot authentication) to the fallback filename of EFI/BOOT/bootx64.efi. Shim will then launch GRUB (grubx64.efi), which continues the boot process. If the efibootmgr -o command I presented earlier does not work, this sequence should get the system booting.

Beyond this, you're asking a lot of fairly basic questions, which is turning this question and its answers into a tangled web. I suggest you do some outside reading:

Once you understand some of these basics, you may get more out of the answers here -- but be aware that we've traveled down a couple of blind alleys because of incomplete initial information and incorrect guesses. If you still have problems after reading at least some of the preceding, I recommend asking fresh questions, or taking the discussion to the Ubuntu forums, which are better set up for back-and-forth discussions. (This site is intended for answering relatively straightforward questions, not carrying on extended discussions.)

  • aufs indicates that the booted (and running) system is a live system. And it would be a bad idea to write the grub bootloader onto the live drive. – sudodus Mar 18 '17 at 17:42
  • Thanks Rod Smith (rod-smith). Didn't work. Please see my update. – Melissa Mar 18 '17 at 21:05
  • Please see my edit, above. – Rod Smith Mar 19 '17 at 14:51
  • @Rod Smith (rod-smith). I'll have to talk to HP tech support first since it's outside 30 days. Are there commands that I can run from Ubuntu (with the USB stick plugged in) that will clearly show us (esp. the HP tech support) that something is wrong? Because currently I'll have to basically relay to him verbatim your comment above and I'm afraid that he'll not be able to understand due to the length. – Melissa Mar 19 '17 at 15:57
  • The output of sudo efibootmgr, and especially the No BootOrder is set; firmware will attempt recovery line, shows the problem; however, most manufacturers will basically say "tough luck" once you mention you're using Linux, unless the computer shipped with Linux pre-installed. – Rod Smith Mar 19 '17 at 19:54

It looks like boot-repair did add the ubuntu shimx64 boot entry as item 0004 in the last run of efibootmgr in your paste link. 0004 was missing in the earlier runs of efibootmgr (in your paste).
Your latest manual run of efibootmgr however does not have 0004 in the bootorder, even though the item is listed. Add it yourself:

sudo efibootmgr --bootorder 0004,0000,0001,0003,0002

Leading zeros are optional, but the above uses the entries as they are shown.

However, this is an HP, with some vendor specific tweaks to UEFI which break the standard setup -- basically adding a specific approved name the boot loader must have (Windows Boot Loader). Additionally, the filename of the bootloader must be bootmgfw.efi. efibootmgr may be used to rename the bootloader entry:

sudo efibootmgr -b 0004 -l /EFI/ubuntu/bootmgfw.efi -L "Windows Boot Loader"

and just rename the /EFI/ubuntu/shimx64.efi to /EFI/ubuntu/bootmgfw.efi
edit VVVV
The rename is the file on the hard disk. Your df shows that the hard disk's EFI, sda1, is not mounted anywhere, so until you mount it, you cannot even see the /EFI directory which will appear where you mount it. Don't touch anything under the /cdrom directory.
edit ^^^^

That should work (search this site for HP UEFI problems, but I think that summarizes the solution).

Edit VVV Mount the hard disk's EFI partition at the /mnt

sudo mount -tvfat /dev/sda1 /mnt

Now under /mnt, you should see the EFI directory of the hard disk's sda1 partition. All modifications are done to these files /mnt/EFI/ubuntu/... and /mnt/EFI/Boot/...
Edit ^^^

As a fallback, which I recommend, set up the disk bootloader, /mnt/EFI/Boot/bootx64.efi as a copy of /mnt/EFI/ubuntu/shimx64.efi. Since shimx64.efi needs grubx64.efi in the same directory, copy /mnt/EFI/ubuntu/grubx64.efi to /mnt/EFI/Boot/grubx64.efi

That fallback bootloader may work independently of the nvram boot entry, and will keep your boot working if something decides to change the nvram boot list.

Awhile ago, I had a dual boot, secure boot enabled host with ubuntu/shim as the first nvram entry, and after creating an install media on a USB stick, the shimx64 entry was changed to grubx64.efi (which of course will not successfully boot with secure boot enabled). UEFI has other more serious problems when USB install media are created, so I eventually changed my default system to run in legacy mode.
What you found on the install media, the /cdrom/EFI/BOOT/BOOTx64.efi is actually the boot file for the USB. Don't alter it, since it works. Note that the BOOTx64.efi is just a copy of shimx64.efi. This is how the install media boots using its default bootloader in UEFI mode. This exact setup (well, case insensitive) is what you are putting on the hard disk as a fallback.

If sudo mount /dev/sda1 /mnt fails because "it's already mounted" then use df to see where, but that's odd if you didn't do it. It's not the /cdrom/EFI, that's a directory (but another source for bootx64.efi and grubx64.efi to put onto the hard disk). Possibly, the disks were re-enumerated, and the hard disk became sdb, leaving the sda to USB. See what df says, and change the mount to /dev/sdb1 if that's the case.

  • Hi ubfan1 thanks so much I'll try now. "will keep your boot working if something decides to change the nvram boot list" can you give me an example of that something so that I know how likely it will happen? And where is the /EFI/ubuntu/shimx64.efi? – Melissa Mar 19 '17 at 3:09
  • Where is the /EFI/ubuntu/shimx64.efi? I have found my boot USB mounted at /cdrom. But in /cdrom/EFI there is only BOOT. Inside /cdrom/EFI/BOOT there are only BOOTx64.efi and grubx64.efi – Melissa Mar 19 '17 at 3:26
  • I think you should mount the EFI partition /dev/sda1 for example sudo mount /dev/sda1 /mnt and then you find it at /mnt/EFI/ubuntu/shimx64.efi or some similar location. Browse to /mnt and search for it. – sudodus Mar 19 '17 at 3:30
  • I can't because it says it's already mounted (on /cdrom I assume). – Melissa Mar 19 '17 at 17:36
  • I have a truncated df in the question details above. I'll get a detailed output soon if it's not enough info (not with the hp pc at the moment). – Melissa Mar 20 '17 at 3:52

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.