20.10 needs ESP on BIOS systems – existing, confirmed, unassigned bug

Foundations
1

I discovered, confirmed and reported a bug a month or 2 back. I found it in Ubuntu Unity & confirmed it in Xubuntu.

Groovy requires a UEFI ESP partition to be present even on BIOS-based systems which do not have UEFI. This applies on real hardware and also in BIOS-based VMs (the default in VirtualBox).

I filed a bug, posted it on the support mailing list and someone pointed me to an existing bug:

I marked mine as a dup of this.

This is a deal-breaker bug: it prevents installation completing successfully in 100% of cases.

All my machines both at home and work run in legacy-BIOS mode, including ones old enough to only have a legacy BIOS, and all the new ones because UEFI is a pain to use.

This is not a niche or edge case.

It also came up on Reddit yesterday:
https://www.reddit.com/r/Ubuntu/comments/mpkfv3/error_in_the_install_so_i_was_trying_to_install/

This is breaking installation for users in the real world.

The bug is unassigned, so nobody is looking at this and it is unlikely to be fixed in time for 21.04.

This is a serious oversight.

I thought I would raise it here but if there is no resolution in 24 hours – at least someone taking the bug on – I will continue trying to draw attention to it. I am very disappointed that this was shipped and is not being dealt with.

The last time I found a serious bug, it also went unaddressed: in the Unity era, it became impossible to operate LibreOffice menus with the keyboard. This was never fixed.

My email was on Tue, 23 Apr 2013, 19:05 with subject line “LibreOffice menu problem remains”

This is not the kind of attention to detail that I typically expect from Canonical. It is not good.

1 Like
2

If you create an ESP, you can install the system also in BIOS mode. That the installer is expecting an ESP in every case is more an aesthetic problem.

Most users in the real world are not affected by this bug or have no prejudice against FAT-formatted partitions.

3

[1] I do not want an ESP and I do not need an ESP. BIOS computers do not need ESPs. UEFI computers booted in Legacy mode do not need an ESP. If I already have an OS installed, e.g. Windows 10 in BIOS mode, adding an ESP could well break them.

[2] This is a new bug; it did not apply in 20.04. It does not apply to any other distro I have tried.

[3] Even if Ubuntu needs an ESP, then Ubuntu should create an ESP. It does not.

This is a bug. It is not a cosmetic issue.

4

I already understood, that you have an aversion against FAT-formatted partitions. No need to repeat it.

What do you mean with “could break them”? I never saw any forum posts that a Windows 10 in BIOS mode was broken after adding an ESP. And even if it were reproducible, you should file a bug against Windows 10, not Ubuntu.

And if it is not a bug, but an unexpected feature for 20.10 and newer releases?

I downloaded the Ubuntu 20.10 desktop ISO, started a VM in BIOS mode and installed it with the “Erase disk” option.
The installer created a bios_grub partition for the Grub core image, the ESP and the partition for Ubuntu. Everything as expected. I cannot reproduce your complaint, that the installer does not create an ESP.

Ohh, and after the installation, I commented out the line in /etc/fstab for the /boot/efi mount point and rebooted. And guess what, it worked.
You should also be able to remove the EFI-related Grub packages without problems.

5

This is obviously an issue with hirsute, as I’ve been unable to install Ubuntu hirsute on many boxes unless I can use a full disk installation (ie. overwrite all that’s there)

A system I use for support had four installed OSes; debian & lubuntu (bionic, focal & groovy; I use for support). I tried to replace the bionic (as it’s soon reaching EOL) with Ubuntu hirsute for a look & install fails with out of space problems.

My system is BIOS only so has never had an EFI/ESP partition.

The only error message on screen is grub-install failed. In the logs its “run out of space” though I wonder if it tried to install grub to the installation media (sdb) as sda has loads of space…

ubuntu@ubuntu:/$ df -h |grep target
/dev/sda1 658G 328G 297G 53% /target
/dev/sdb2 4.9M 4.9M 2.0K 100% /target/boot/efi

If my issue is the same, at a minimum I’d suggest improving the messages to at least explain to the user what the problem is.

I can however install Lubuntu hirsute without issue, the calamares installer gives a ESP warning message but install completes without error, and it boots (Ubuntu doesn’t after it’s install failure). I’m betting Ubuntu Studio likewise installs correctly too (given it uses calamares too).

It impacts most of my systems, but given my primary box is from 2009, my test hardware is even older.

6

But users might install in CSM mode and then turn CSM off, and then wonder why there machine doesn’t boot anymore. That’s why it sets up an ESP when booted via BIOS, it’s a feature to make boot more reliable.

As Steve wrote on the bug, there still seems to be a bug if you do not create an ESP, and that will have to be solved eventually, but hirsute release is in a few days, so it might have to wait for 21.10.

7

@lproven I just uploaded a fixed ubiquity to hirsute. Hopefully it migrates soon and will be in the release candidate images.

2 Likes
8

@juliank A lot of gratitude for the fix! :slight_smile:

9

:slight_smile:

but also :frowning: as Lubuntu/Ubuntu-Studio hirsute now has problems (20200414) on all systems as ubiquity is run instead of our normal calamares… we’ll get there…

10

The Lubuntu/UbuntuStudio issue was a consequence of the inopportune removal of localechooser from hirsute, unrelated to the latest ubiquity upload. Localechooser has been reintroduced so this problem should be resolved with the next image build.

1 Like
11

Thanks @vorlon …

I’m waiting to test Lubuntu 20200415 once it’s stopped re-building (status as reported on the ISO tracker) …

I’ll kick off my zsync of Ubuntu to give it a try in the mean time on my old BIOS hardware :slight_smile:

FYI: Ubuntu hirsute still fails to install with 20210415 but that may not have had the fixes… last resort is always a comment on release notes (something easy to point to for those of us involved with support)