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 of
aufs'` 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.
EDIT:
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
/EFI/ubuntu/shimx64.efi
/EFI/Microsoft/Boot/bootmgfw.efi
/EFI/Microsoft/Boot/bootx64.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.4.7.9.5.}...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.
EDIT 2:
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.)