Installation of Ubuntu Groovy with manual partitioning without an EFI System Partition fails on 'grub-install /dev/sda' even on non-UEFI systems

Bug #1893964 reported by Jan Rathmann on 2020-09-02
This bug affects 16 people
Affects Status Importance Assigned to Milestone
ubiquity (Ubuntu)
Status tracked in Hirsute

Bug Description


trying to install current daily-live images of Groovy in VirtualBox fails for me when I'm using manual partitioning without an EFI System Partition (ESP).

Steps to reproduce:

1. Partition layout I have used in VirtualBox:
 * Partition table: MBR
 * A single primary ext4 partition (/dev/sda1) using up the entire virtual harddisk with 1 MB free space before start of the partition
2. Boot current Groovy daily-live image, click on "Install Ubuntu"
3. Choose "Something else" (manual partitioning)
4. Select /dev/sda1 as target for '/', check "format partition".
5. Ignore warning about missing EFI system partition.


The installation proceeds until GRUB is about to be installed.
Then an error dialog appears: "Executing 'grub-install /dev/sda' failed. This is a fatal error." (screenshot attached).
If I click 'Ok', after a moment Ubiquity nevertheless shows the usual dialog saying "Installation is complete. Please restart." The only option the dialog offered was to click on "Restart now".
After that, booting the failed installation succeeds, but it is obvious that Ubiquity couldn't complete its job: Packages like ubiquity itself, which usually get purged from the fresh system at the end of a successful installation, are still installed. There is also a pop-up in gnome-shell showing an error regarding package management (screenshot attached, not sure if this is related to the failed install).

Modifying the setup by creating an ESP manually like described in #7 makes the installation complete successfully without error.

The setups I have tested (my machine and VirtualBox) don't support UEFI or don't have UEFI support enabled respectively (and thus don't actually require an ESP to boot).

To send this report, I was running 'sudo ubuntu-bug ubiquity' on the "failed", but nevertheless booting fresh installation.

Kind regards, Jan

ProblemType: Bug
DistroRelease: Ubuntu 20.10
Package: ubiquity 20.10.9
ProcVersionSignature: Ubuntu 5.4.0-42.46-generic 5.4.44
Uname: Linux 5.4.0-42-generic x86_64
NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
ApportVersion: 2.20.11-0ubuntu45
Architecture: amd64
CasperMD5CheckResult: skip
Date: Wed Sep 2 16:55:14 2020
InstallCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.4.0-42-generic root=UUID=6ba06971-16c7-4df6-afcc-3bc101cba9a5 ro quiet splash
SourcePackage: ubiquity
UpgradeStatus: No upgrade log present (probably fresh install)

Jan Rathmann (kaiserclaudius) wrote :
Jan Rathmann (kaiserclaudius) wrote :

This happens also when I try to install Kubuntu Groovy, the only thing that's different is that after the "grub-install /dev/sda failed" dialog there is for 1-2 seconds a window telling "Sorry the installer had crashed" which disappears again without interventention, and then there is dialog with the following message:

"The installer encountered an unrecoverable error. A desktop session will now be run so that you may investigate the problem or try installing again."

That dialog sends you to the live session.

But that seems to be the only difference between Kubuntu and Ubuntu - the installation will boot despite the failure, but is "not complete", as described above.

Jan Rathmann (kaiserclaudius) wrote :

Still happening with Kubuntu daily-live image 20200930.

Ubuntu QA Website (ubuntuqa) wrote :

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:

tags: added: iso-testing
Changed in ubiquity (Ubuntu):
milestone: none → ubuntu-20.10
Jan Rathmann (kaiserclaudius) wrote :

To be a bit more precise, I found out that this bug isn't limited to VirtualBox, it also happens the same way when I try to install Groovy directly on my hardware (older mainboard without UEFI, no ESP partition, LVM setup, Btrfs filesystem on root).

summary: - Installation of Ubuntu Groovy in VirtualBox with manual partitioning
- fails on 'grub-install /dev/sda'
+ Installation of Ubuntu Groovy with manual partitioning fails on 'grub-
+ install /dev/sda'

Further testing, I found out that the grub installation failure seems to be related to whether there is an EFI System Partition (ESP) or not.

I did the following change to my VirtualBox setup to manually create an ESP:
- Shrink the single partition on my virtual HD with GParted so I get 512MB free space at the end of the disk
- Create an additional primary FAT32 partition with 512MB size, mark it as ESP (with cfdisk)

So I have the following partition layout:
/dev/sda1: primary partion, size ~9,5GB, ext4
/dev/sda2: primary partition, size 512MB, fat32, marked as ESP

With this partition layout and selecting /dev/sda1 as root (marked for formating) the installation will complete successfully without an error regarding grub installation, and the installed system boots fine.

So it seems that this bug happens if there is no ESP on the system - even if the system doesn't support UEFI at all and thus doesn't need an ESP.

summary: - Installation of Ubuntu Groovy with manual partitioning fails on 'grub-
- install /dev/sda'
+ Installation of Ubuntu Groovy with manual partitioning without an EFI
+ System Partition fails on 'grub-install /dev/sda' even on non-UEFI
+ systems
description: updated
Jan Rathmann (kaiserclaudius) wrote :

Manual workaround for those who are affected:

1. Start Ubiquity by running 'ubiquity -b' (doesn't install grub and will not trigger this bug)
2. After installation is completed, don't reboot and install grub manually with the following commands in a terminal (assuming your have installed Ubuntu to /dev/sda1, change accordingly):

sudo mkdir uroot
sudo mount /dev/sda1 uroot
sudo mount -o bind /dev uroot/dev
sudo mount -o bind /sys uroot/sys
sudo mount -t proc /proc uroot/proc
sudo chroot uroot
grub-install /dev/sda1
sudo umount uroot/proc
sudo umount uroot/sys
sudo umount uroot/dev
sudo umount uroot

3. Then reboot, new installation should boot up fine.

Jan Rathmann (kaiserclaudius) wrote :

Sorry, typo in my last post, the command to install grub of course has to be:

grub-install /dev/sda

tags: added: rls-gg-incoming
Launchpad Janitor (janitor) wrote :

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

Changed in ubiquity (Ubuntu):
status: New → Confirmed
ajgreeny (ajg-charlbury) wrote :

I have this same problem when installing Xubuntu-20.10 using KVM/QEMU and virt-manager.
The iso file boots properly and live system runs as expected but there is a cpmplete failure to install grub to /dev/sda.
Looking at the filesystem in thunar shows that this appears to be a UEFI install with an EFI partition and also for some reason a small BIOS-boot partition, but attempting to install grub to either of those two partitions also fails leaving the installed system unbootable.
A bug was created by the installer after this failure at

Changed in ubiquity (Ubuntu):
milestone: ubuntu-20.10 → none
tags: added: rls-hh-incoming
removed: rls-gg-incoming
Brian Murray (brian-murray) wrote :

Given that there is a warning presented for this situation we've decided to same this for fixing in the HH release of Ubuntu.

nmaxx (nmaxx) wrote :

Where is that warning mentioned in comment #12 ?
I did not find anything in the 20.10 release notes' "known issues" list:
And do I read this correctly that you'll not release a fixed 20.10 image but wait for 21.04 ?

Jan Rathmann (kaiserclaudius) wrote :

@nmaxx I think Brian's comment is not referring to the release notes but to the warning during the installation process where the installer complaints that installation will likely fail without an ESP.

Steve Langasek (vorlon) wrote :

Two guidelines we should enforce here:

1. we shouldn't allow the user to leave the partitioner with a config that will lead to an install failure later
2. if the user can't have an ESP for whatever reason, we should let the install proceed without setting up shim-signed/grub-efi*

We should still encourage wherever possible that the user set up an ESP, for compatibility with firmware changes or moving disks between hosts.

Changed in ubiquity (Ubuntu):
importance: Undecided → High
tags: removed: rls-hh-incoming
tags: added: fr-876

Same error (grub-install failing) when trying to install Ubuntu Mate onto bare metal. I have no ESP (and have no room to make one), but saw no warning about a missing ESP.

What's worse: the installation failed to boot: it hung while trying to mount something. Rebooting into another distro and examining the /etc/fstab on the Mate partition, it contained an entry for /boot/efi on /dev/sdb3 -- the installation medium! Surely this should never happen: any entries in /etc/fstab that refer to the installation medium should be removed before rebooting, also when any amount of errors occur during installation. After removing the line, I could then boot into Mate.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers