The installation fails with a "GRUB installation failed" message.
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
grub-installer (Ubuntu) |
Confirmed
|
Undecided
|
Unassigned |
Bug Description
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-
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/
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-
* 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-
initrd /boot/initrd.
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...
affects: | ubuntu → grub-installer (Ubuntu) |
tags: | added: bionic |
description: | updated |
Status changed to 'Confirmed' because the bug affects multiple users.