I am installing Ubuntu 16.04 in an Intel NUC computer with UEFI enabled. I am using an SSD from another computer. During the installation I chose Erase the disk and make a new full install

At the end of the process I see:

grub-efi-amd64-signed failed installation /target/ Ubuntu 16.04 

And the system does not boot.

I tried to use boot-repair but apparently it does not solve the problem.

  • There can be several reasons for this. But one is a bad burn of the install media. Try reformatting it (with new partition table) and remaking the media. I've had this issue more than once and remaking the install media always fixed it. (Although other people with this issue have said it did not fix it.)
    – chaskes
    Jun 22, 2016 at 2:34
  • i recreated the liveusb but the problem remained.
    – Kaf
    Jun 22, 2016 at 2:46
  • 1
    I received the same issue when using a brand new SSD. Mar 22, 2017 at 15:13

12 Answers 12


I had exactly the same issue installing 16.04 64 desktop on a new SSD with UEFI enabled using USB install media. Unlike in the question I chose to create my own partitions as I had other disks to mount. I hit this error near the beginning of the package installation.

After a bit of googling I found this page:


which states in the General principles section:

if there was not any UEFI partition on your HDD, you first will have to create it

and points to:


Which states:

  1. Mount point: /boot/efi (remark: no need to set this mount point when using the manual partitioning, the Ubuntu installer will detect it automatically)
  2. Size: minimum 100Mib. 200MiB recommended.
  3. Type: FAT32
  4. Other: needs a "boot" flag.

So I reinstalled and when I came to partition my drive, I chose the EFI option from the list that includes filesystems and swap etc and made it 200MB at the start of the disk. I did not get the option to select the filesystem or set the bootable flag.

After this the rest of the install went fine.

This is how the partitions on this disk look after the install:

enter image description here

The same information can be seen by running parted:

$ sudo parted /dev/sda
GNU Parted 3.2
Using /dev/sda
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) p                                                                
Model: ATA Samsung SSD 750 (scsi)
Disk /dev/sda: 250GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: 

Number  Start   End    Size    File system     Name  Flags
 2      1049kB  200MB  199MB   fat32                 boot, esp
 3      200MB   242GB  242GB   ext4
 1      242GB   250GB  8000MB  linux-swap(v1)

(parted) q

Note that the partition that was created is an EFI System Partition (ESP) and the disk has a GUID Partition Table (GPT) rather than an MBR partition table.

If you look in /boot/efi or /sys/firmware/efi/ on this disk you should find them populated, likewise running sudo efibootmgr should provide real output, see the link below if you want more information.

More Information

If you wish to know more about how UEFI works then the post UEFI boot: how does that actually work, then? by Adam Williamson is highly recommended.

He describes the situation that causes this error in the article (note that he is a Fedora user but the same applies for Ubuntu):

Handling EFI system partition if doing manual partitioning

I can only give authoritative advice for Fedora here, but the gist may be useful for other distros / OSes.

If you allow Fedora to handle partitioning for you when doing a UEFI native installation – and you use a GPT-formatted disk, or allow it to reformat the disk (by deleting all existing partitions) – it will handle the EFI system partition stuff for you.

If you use custom partitioning, though, it will expect you to provide an EFI system partition for the installer to use. If you don’t do this, the installer will complain (with a somewhat confusing error message) and refuse to let you start the installation.

So if you’re doing a UEFI native install and using custom partitioning, you need to ensure that a partition of the ‘EFI system partition’ type is mounted at /boot/efi – this is where Fedora expects to find the EFI system partition it’s using. If there is an existing EFI system partition on the system, just set its mount point to /boot/efi. If there is not an EFI system partition yet, create a partition, set its type to EFI system partition, make it at least 200MB big (500MB is good), and set its mount point to /boot/efi

  • 4
    This worked flawlessly Jul 23, 2017 at 21:28
  • I think this is what I get for trying to create my partitions by hand without knowing enough about the UEFI standard. Thanks for the super helpful info. Aug 29, 2017 at 7:20
  • EDIT: For anyone lazy like me I fired up a Windows 10 install over USB and installed Windows first. This repaired the UEFI partition automatically. I then used the Disk Management software in Windows 10 to shrink the Windows partition and create room for Ubuntu. You can then manually define your partitions in the Ubuntu install afterwards or select the option to install along-side Windows. Both should work fine. Aug 29, 2017 at 7:51
  • 3
    Worked on Ubuntu 18.04. One note: /boot/efi wasn't an option on the dropdown; it only showed /boot which didn't work. I had to manually type in /boot/efi and then it worked.
    – Luke
    Apr 30, 2018 at 2:28
  • 2
    Also worked for me on Ubuntu 18.04. However, instead of choosing "Fat32" as the filesystem and specifying a mount point, I chose the "EFI" filesystem and it worked flawlessly.
    – Gillespie
    Apr 30, 2018 at 14:45

By luck I solved my problem.

I booted with the live usb and called Disks, and manually deleted all partions of the SSD.

Then I rebooted with uefi enabled in the computer firmware. I entered the live usb Ubuntu desktop and from there I installed Ubuntu.

I checked the two boxes saying install updates and software from others. This time the installation went fine.

  • 1
    It will install successfully with internet connected. You can try if you're lucky again without internet. I still got failed for now.
    – Franklin
    Nov 5, 2016 at 3:59
  • 1
    Franklin, check your /var/log/syslog, probably there are just before "grub-installer: info: Calling 'apt-install grub-efi-amd64-signed' failed" some lines like "Unable to locate package grub-efi-amd64-signed" and "Unable to locate package shim-signed". Probably Installer failed to reach deb packages from the "cdrom" (usb flash)?
    – osgx
    May 8, 2017 at 5:47
  • This happens to me but on a 32bit machine. Wondering if EFI does support 32 bit
    – chx101
    Feb 12, 2022 at 10:40

I had the same problem installing Ubuntu MATE 17.04. I was trying to make a dual boot alongside Windows 10. My Windows is on Legacy mode and the UEFI support was enabled in the BIOS settings. I went and disabled UEFI support and the installation completed flawlessly.Hope someone finds this useful.


I faced the same problem when I tried to install mint 18 kde on a gigabyte motherboard. My problem was i was trying to boot from usb in Uefi mode.

You have too boot in compatibility mode. You most likely need to change some BIOS settings to do that. In my case I had to select "legacy only" in boot mode selection.

If you boot in compatibility mode you will get a screen that says automatic boot in 10 seconds then you will get a menu But if you boot in Uefi mode you will get the menu directly.

  • Ubuntu is not Mint. If you read the answers you will note that the OP was able to install via EFI after deleting existing partitions.
    – Elder Geek
    Jan 15, 2017 at 15:30

Got the exact same message and resolved it by simply connecting my computer to the internet (I was using a USB installer to install to a completely new machine with brand new SSD with nothing on it).

When connected, the installer can download any dependencies missing in the installer, as was required for my setup.

The giveaway it was a dependency issue and not a partitioning/disk issue was in the /var/log/syslog file. The message about Grub failing to install can mean a lot of things and generally you should check out /var/log/syslog to find out what the true problem is.

  • I faced similar error during installation of Linux Mint 19 and in my case it was opposite. As it is discussed here forums.linuxmint.com/viewtopic.php?t=273058&start=20 there are some issues when downloading the package lists from the linuxmint.com and ubuntu.com mirror. Disconnecting from the internet helped to install grub2 successfully.
    – Akif
    Jul 16, 2018 at 20:27

You can also create a boot uefi partition, if the system allows it. I have the same problem, and unable the uefi is one option, and is more permanent, but I was in a run so I create the uefi boot partition: the option appears in the same option than /boot, in below


I faced the same issue. What worked for me, was during installation, when the installer asks you if you want to install in UEFI mode, tell it no. It should warn you of the repercussions of this, but having done it this route, I've faced no issues.

The other solutions I came across while researching this issue involved

  • Rebooting the computer with the same (or another) live disc and running boot repair on the problem computer.
  • Watching the install logs and turning off the computer when you see if installing GRUB just before the crash (I suppose this takes timing, though I highly recommend against this. You should always try to refrain from turning off a device while installing anything).

Had the same error message, turns out I had a corrupted directory in the EFI partition that was causing grub to give up at every install attempt.

fsck took way too long, so chkdsk from Windows quickly cleaned up the corruption and the second install went fine.


I found the above did not really work for me trying to install Ubuntu 16.04 onto a USB stick from another USB stick. After 2 days of heartache, this is what I did to get it going. This gave me a dual boot Windows 10 and Ubuntu installation on the same hard disk and in the process, solved this problem:

  • Use a target hard disk and a source cdrom hardware to install from
  • Download /burn to DVD windows 10 (generic for all versions) and ubuntu 16.04.3 versions. Ie 2 installation dvds are created.
  • Boot into the live version of ubuntu without installing.
  • Delete all partitions on the hard disk using ubuntu’s built in partition manager gparted.
  • Boot into systems bios and ensure only UEFI is selected and legacy boot is turned off. Also change boot order to ensure system will first boot from the cdrom if available and disk as 2nd option.
  • Insert windows disk and go ahead and install windows (I used windows 10 pro 64 bit) onto the hard drive. You do not need a license to do this – just say you do not have a license when prompted.
  • Boot windows and make sure it works. I found it would not shutdown properly but this did not seem to matter. I also allowed windows 10 to go through it full update cycles though this likely did not matter. It just takes ages.
  • Now boot again into the live ubuntu. This time use it to reduce the last data partition so as to create room for a ubuntu install. Just leave the free space unallocated. I needed windows anyway so left half the disk size for windows.
  • Select the install app built into the ubuntu dvd. Choose option to install alongside existing windows os. I left the default options so as to have it create 2 partitions root and swap in the free space.

That it was. When I now boot I get a prompt to ask whether I want windows or ubuntu or ubuntu advanced with more options. I had spent ages playing around with booting from USB sticks but that cost me a whole 2 days. Using the cdrom and hard disk, old style, seems to have helped.


My solution to the problem was the following.

1) Due to some reason my EFI disk was locked by Windows and that's why Grub was unable to be installed on my EFI.

I started Windows and shut it down (Windows -> Shut Down -> Shut Down, not restart). NB: in case of restarting, Windows may restart in Fast Restart mode which leaves EFI locked - this is what happened to me.

2) I run Ubuntu Live Disk, and run Boot-Repair utility (URL) using standard settings.

After this, my system started to boot normally via Grub.

The trick was that without item 1 (EFI was locked by Windows) Boot-Repair utility was unable to fix my Grub.


The issue itself was in grub package (grub-efi-amd64-signed_1.66.14+2.02~beta2-36ubuntu3.14+linuxmi.deb for details check here).

Workaround was to connect to the Internet and check Download updates during installation.


just for the record I faced the same issue by installing 16.04 on an Acer tmb117 I erased totally the internal disk using the live usb then rebooted and simply launched installation (standalone, no other system alongside Ubuntu) connection was turned off.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .