10

When I'm trying to install Ubuntu 18.04 on my desktop, it shows the following error:

error popup with ubiquity

The 'grub-efi-amd64-signed' package failed to install into /target/. Without the GRUB bootloader, the installed system will not boot.

How to fix this error?

4
  • does your computer support EFI? looks like you are trying to install grub-efi on and MBR disk or, did you create an EFI System partition? verify your bios settings and update your question with more details about your problem Apr 27, 2018 at 19:13
  • 1
    Post the link to the Create BootInfo summary report. Is part of Boot-Repair: help.ubuntu.com/community/Boot-Info
    – oldfred
    Apr 28, 2018 at 3:56
  • 1
    I was having the same problem. What worked for me was selecting the non UEFI boot option on the USB installer. May 6, 2018 at 12:03
  • - assign 150mb to EFI while partioning.follow the image for more details
    – snowden
    Jul 3, 2018 at 7:15

5 Answers 5

4

If after getting this error message, you rebooted your PC and can't boot Ubuntu because of GRUB booting error, you need to reinstall GRUB manually into the EFI system partition (ESP) through chroot. Here's how I did to fix the problem in my case.

Use Live Session

Boot into your LiveUSB (or LiveCD) and select 'Try Ubuntu without installing'. Later, you may need to ensure you can connect to the Internet on your live session.

Chroot

Let's suppose you installed Ubuntu in /dev/sdXY partition, and an already existed ESP is in /dev/sdXZ partition, on the hard drive /dev/sdX. Open a terminal and execute these commands :

$ sudo mount /dev/sdXY /mnt
$ sudo mount /dev/sdXZ /mnt/efi
$ for i in /dev /dev/pts /proc /sys /run; do sudo mount -B $i /mnt$i; done
(Now, if you customized Ubuntu installation by dividing some directories up into different partitions (eg. '/boot', '/opt', etc.), you should mount them too under `/mnt` directory. You may refer to `/mnt/etc/fstab` file to remember what you did on the installed Ubuntu system)
$ sudo chroot /mnt

Reinstall grub2 with the right EFI version

Once you chroot successfully into your installed Ubuntu system, make sure to (re)install the right grub-efi-* package for your PC architecture :

# apt-get install --reinstall grub-efi-x86_64 (the one I used for Intel i5 CPU)

or

# apt-get install --reinstall grub-efi-amd64

or

# apt-get install --reinstall grub-efi-ia32, etc... You can get the list of available packages with # apt-cache search ^grub-efi

Finally, to install grub2 into your drive:

# grub-install --boot-directory=/boot --bootloader-id=ubuntu-fix --target=x86_64-efi --efi-directory=/efi
# update-grub

Please note the --target=x86_64-efi can be different depending on your system (eg. i386-pc by default, maybe amd64-efi, etc.). Check # grub-install --help for more info.

Exit chroot, unbind/unmount safely directories & reboot

  1. Exit chroot with Ctrl+D or # exit
  2. Unmount safely and reboot :

    $ for i in /sys /proc /dev/pts /dev; do sudo umount /mnt$i; done
    $ sudo umount /mnt/efi
    (Unmount any other customized partitions, if you had any)
    $ sudo umount /mnt
    $ sudo reboot
    

Ubuntu should now boot normally.

References:

1
  • I had also installed package grub-efi-amd64-signed and used the --uefi-secure-boot option with grub-install command. I guess this could be essential for when Secure Boot in turned on. Apr 8, 2019 at 9:26
2

Edited and modified original answer, AFTER further 20+ experiments on both of my machines. To make it short answer, I will remove all incorrect assumptions and conclusions in the old answer.

----------------My computers ARE 1. Fujitsu LIFEBOOK-LH532, which UEFI BIOS in the mainboard was destroy by ubuntu EFI ubiquity version 12.04, in 2012 https://bugs.launchpad.net/ubuntu/+source/efibootmgr/+bug/1082418 Obviously I choose manual BIOS installation on my NoteBook UEFI LH532. SINCE I DON'T WANT TO open MY NOTEBOOK TO SHORT CIRCUIT JUMPER cl1&cl2 ON THE MAINBOARD again SINCE I "THE BUG" IS STILL THERE. ***I forced manual BIOS mode by not provide EFI partion on any hard disk. BUT ALL INSTALLATIONS WILL DETECT UEFI MAINBOARD AND WILL TRY TO INSTALL EFI UBUNTU "FIRST".

  1. Old Gigabyte xenon server non UEFI mainboard.

    Which has no errors at all.

The errors exactly as the topic is, resulted in problems with "UEFI"NOTEBOOK ONLY.

  1. NON botable UEFI notebook(LH532). Ubiquity Destroy the existing UBUNTU GRUB.
  2. "OR IF LUCKY" will just use the old Bios grub installed by 16.04 and boot into new 18.04 (in the old 16.04 partitions) with some error at the beginning of the booting time.

I FIXED THE BOOTING BY

  1. Pain?? complex? Using Boot-Repair (failed to use grubcustomiser) installed into existing ubuntu installation on other partitions or BOOTED Live usb. And follow instructions which were different from one time to the others depend on the configuration of hard disks in the systems as well as the flavour of ubuntu 18.04 used.

https://help.ubuntu.com/community/Boot-Repair

  1. Easy and Excellent "most of the time". I used 16.04 of UBUNTU OR LUBUNTU do a new installaion on other partitions of hard disk in that same computer, that you have installed "18.04" and failed to install grub with this ERROR.

So that 16.04 will make your system boot. And yes, you can access to Great 18.04 versions from that 16.04 grub.

And YES, I use UBUNTU 18.04 to write this answer, after LUBUNTU 16.04 INSTALLed NEW GRUB FOR my LH532 notebook with the correct option to choose 18.04.

Reasons for the error of this topic is you don't provide EFI partitions for the manual "something else" installation mode.

So if you purposely, like me, not to have EFI partition. you will have this error.

But 16.04 versions, have a smarter UBIQUITY or ? whatever? than 18.04. It will found that you install with BIOS installation (no efi partition in the hard disk) and let you chose to "GO BACK" to install ubuntu with BIOS mode. But the 18.04 will do installation with out any choice in my case and possible yours.

I will call those poorer quality in these circumstances of 18.04 as "BUG". But it could be the programmers intention to force us to use only proper clean automation only???, which they should have remove "something else" option.

  1. I have correct the issues by completely REFORMAT my SSD. Install Windows 10 UEFI mode. Which it automatically create EFI partition.

Then install UBUNTU 18.04 with no errors, though it jealously prohibit me to boot into MANJARO LINUX which I installed after Windows 10 with no issues too.

And of course, UBUNTU 18.04 destroy my BIOS F12. JEALOUSELY PROHIBIT me to install any other OS, and I have to open the notebook case to short circuit jumper CL1 and CL2 to get F12 to choose boot media back.

I did report this to lunchpad as the link I provide above.

Sorry off the topic a bit but let you all knows there are more bugs in ubiquity or installation process more than this issue.

1

I have a similar error when installing ubuntu 18.04 from boot USB. I made a BOOT CD and installation was successful.

1
  • Thanks for your response, but this seems like a sub-optimal answer. Installing 18.04 from USB is possible and part of the intended design, so it is likely to be an issue other than USB to being the correct install medium.
    – Jeremy
    Apr 30, 2018 at 23:36
0

I think you have three options:

I hope this helps, regards,
Onno

0

I had this exact same problem, when installing from a USB flash memory stick using the UEFI boot. When that failed, I followed one of the comments here, booting from the non-UEFI generic flash disk to do the install, and that worked. At the time, I knew nothing about UEFI and had no idea why one method worked but not the other.

Since then, I have looked into it a bit, and now understand that UEFI (Unified Extensible Firmware Interface) is a successor to BIOS and has different requirements. In particular, Linux requires a /boot/efi partition if using UEFI, which I had not created (I was creating the partitions manually).

The error messages could certainly be clearer. The UEFI disk partition program should require the efi boot partition before allowing you to proceed. Instead, it performs most of the Linux install before giving the "GRUB installation failed" error.

2
  • question ... a /boot/efi partition or directory ??? i was also having this issue with grubn2 being blown away ... but I thought it was because I have a 2 SSD setup with my first being GPT the second MS-DOS partition ... i thought the issue was GPT being first even though trying to install on second and specifying that for the boot. SO ... make /boot/ /book/efi swap / as partitions huh??? i just installed Fedora on the second and it worked Jun 9, 2018 at 4:11
  • @georgeBarbaz I believe it has to be a partition. Here is some Ubuntu UEFI information from a few years ago, for an earlier release: UEFI info
    – Tom Karzes
    Jun 9, 2018 at 9:46

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