The installation fails with a "GRUB installation failed" message.

[OE]

Release: Ubuntu 18.04 LTS (Bionic Beaver)
Summary: The installation fails with a "GRUB installation failed" message.
         Workaround available, see below.

Since 16.04 installed fine, you could see this as a regression...

* System setup (relevant part only)
- UEFI enabled
- Secure Boot disabled
- SSD with a pre-install MBR (msdos) partition layout
/dev/sda
  /dev/sda1 ext4 / (format)
  /dev/sda2 ext4 /home (do NOT format)
  /dev/sda3 swap

* During the install (relevant part only)
- Installation type: select "Manual"
- Prepare partitions: see layout above

>>> What I expected to happen: installation success!
>>> What happened instead: (see below)

After the complete installation is done, an alert box pops up:

Alert box: GRUB installation failed
"""
The 'grub-efi-amd64-signed' package failed to install into /
target/. Without the GRUB boot loader, the installed system will
not boot.
"""
Button: OK

Side note: I think this alert box fails to fill in the "/target/" part...

After clicking on [OK] an "Installer Crashed" window appears. Before I can read anything, the window disappears. (This also looks like a bug!). Then the installer flips back to the live desktop with the "Install" icon on the desktop.

I reboot the system. The next error appears:

"""
error: file '/boot/grub/i386-pc/normal.mod' not found.
Entering rescue mode...
grub rescue>
"""

At this point I can't do anything because grub is missing files! I consider this also a bug, the installer should always install GRUB full because failures are unforeseen by their very nature. You should always have a full GRUB installation available when this happens, even when the installer assumes(!) it's doing the right thing... Do -not- assume Murphy's law doesn't apply to you, because then it will hit you even harder...

My guess on what went wrong:

The installer detected that UEFI was enabled, then (wrongly) assumed/detected that Secure Boot was also enabled. Then logic dictates (...) that the HDD/SSD should be a GPT disk with the appropriate layout and (wrongly) "thinks" MBR is not an option. Now GRUB fails because it encounters a MBR disk.

======================
=== The Workaround ===
======================

The simple workaround is; use a GPT disk with the appropriate partition layout. When using a GPT disk with the appropriate partition layout is not an option, then use this three step workaround:

1) Fix the wrong GRUB installation
2) Manual boot the system with GRUB
3) Run update-grub so the system will boot correctly

* Step 1: Fix the wrong GRUB installation

- Boot into the live desktop
- Open a terminal
- Find the boot disk...
  ...in this case it is: /dev/sda
- Find the partition where /boot is installed...
  ...in this case it is: /dev/sda1
- Now run the commands:
  (replace /dev/sda1 and /dev/sda with the appropriate values)

sudo mount /dev/sda1 /mnt
sudo grub-install --boot-directory=/mnt/boot /dev/sda

* Step 2: Manual boot the system with GRUB

- Boot the system, the "grub>" prompt should appear.
- Find the partition where /boot is installed...
  ...in this case it is: (hd0,msdos1)
- Find the partition where / is installed...
  ...in this case it is: /dev/sda1
- Heads-up: pay attention to the "ls" commands,
  the vmlinuz and initrd filenames may differ!
- Now run the commands:

ls
ls (hd0,msdos1)/boot
set root=(hd0,msdos1)
linux /boot/vmlinuz-4.15.0-20-generic root=/dev/sda1
initrd /boot/initrd.img-4.15.0-20-generic
boot

- The system should boot now...

* Step 3: Run grub so the system will boot automatically

- The system is now booted
- Open a terminal
- Now run the command:

sudo update-grub

- Now reboot the system
- The system will boot normally now ... if everything went well...

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Rainer Bunger (rbunger)]

great description of the bug and the workaround!

[oldfred (oldfred)]

Issue is really that to boot in UEFI mode you should have gpt.
And most systems now have gpt as windows in UEFI mode requires gpt. But if installing in BIOS/Legacy/CSM boot mode to gpt drive, you must have a bios_grub partition which is only 1 or 2MB unformatted with bios_grub flag.

Or if installing in UEFI boot mode to gpt drive, you must have an ESP - efi system partition which is fat32 with boot flag.

If you do not have correct partitions for boot mode, then grub install fails.
Boot-Repair will tell you that you need the correct partition, and grub should at least explain why it is not installing, like Boot-Repair does.

[OE (onno-ebbinge)]

@oldfred; I understand your argument, but this doesn't take reality in account. I've looked for similar bugs (very likely duplicates of this one or visa versa) and there are more than 250 reports regarding grub failures at the end of the installation or upgrade. In theory you are right, in practice there are a lot of people who have troubles. The Linux kernel itself is full of "reality patches" that defy theory but work nevertheless.

Also take into account that the previous LTS installed fine and GRUB behaved as expected, even when dual-booting Windows 7. It's really easy to argue that this is a regression and should be fixed accordingly.

In conclusion; when a large portion of your user-base is experiencing trouble where they don't expect it and/or had none before, it should be fixed. Especially when a fix is (easily) feasible and expands the use of Ubuntu and it derivatives considerably.

[apt-ghetto (apt-ghetto)]

The installation fails because you have booted the installer in UEFI mode and there is no EFI-System-Partition.

Your workaround describes how to install Grub in the BIOS legacy mode, which works because Grub can be installed into the MBR.

First of all, the workaround is not really necessary because you can install Ubuntu in BIOS mode simply by booting the installer in the BIOS mode. (Depending on the UEFI you have and how you created the USB stick, this is not always a simple task)
And there is probably another problem, because during the installation in UEFI mode, some Grub packages are removed, e.g. grub-pc. Therefore I am not sure if you have really a complete installation or a standalone Grub, that will never receive updates.

Unfortunately there are no log files.

[OE (onno-ebbinge)]

@apt-ghetto

Thanks for you're analysis. I have no option to boot in legacy mode...

@apt-ghetto said:
> ......you can install Ubuntu in BIOS mode simply by booting the installer in the BIOS mode.
> (Depending on the UEFI you have and how you created the USB stick, this is not always a simple task)

So this the real solution then; detect / make it easy to boot in legacy mode! But this a regression then, I had no problems while installing 16.04 via USB stick.

[Martin Wudenka (martin-wudenka)]

I just want to add that I'm experiencing the same bug on a gpt partition as well. I tried to install ubuntu 18.04 on my surface pro 4. Even totally wiping all partitions and setting up a new gpt partition table didn't help. I had to disable secure boot to get a working installation. With 17.10 everything was working fine.

[Karl William (karl-william)]

I have also tried to install 18.04 LTS and it failed several times.
Seeking a solution I read somewhere about leaving 1-2 MB of space before efi partition. In the beginning of linux era as I remember there was a practice of leaving some space before adding partitions.
So I did so through Ubuntu installer:
- Create 2 MB FAT32 partition
- Create 1024 MB efi partition
- Create / (root) partition on the rest
- Delete 2 MB partition

Click on Install now!

I haven't changed anything else, just these 2 MB and voila it installed without any problem!