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

[Liam Proven]

> No this is a feature. Both bootloaders are setup.

I understand the argument now but I am not convinced. I still think that
the real situation here is not being understood.

*If* this is a clean install on an empty hard disk, then OK, argument
accepted.

Additionally: *if* one of the automatic disk partitioning options is
accepted, either "use the whole disk" *or* the option to automatically
partition a disk and take some space off Windows, OK.

But there is a circumstance which is not being considered here: if the
user picks "do something else" *and* ALL of the following set of
conditions are met:

 - the PC is in BIOS mode, which means no ESP is needed;

 - AND the disk is MBR, which means that only 4 partitions are allowed
and requiring an unnecessary additional partition is actively harmful;

 - AND there is an existing OS, meaning the ability to change firmware
boot modes is already limited by the other, which means you CANNOT
predict what the other OS will do or what it needs.

The error is wrong: no ESP is needed in BIOS mode.

ALSO it is spurious: many PCs can't be toggled, AND if there is another
OS, such as Windows or DOS or anything non-Linux, then it MUST NOT be
toggled because it will break the other OSes.

AND it is wasting a precious resource.

Whoever had this idea did not think it through enough, and the alleged
"feature" of being able to boot in 2 modes does not apply if the machine
is dual-booting.

Basically if it is a custom install, it is in BIOS mode, and there's
another OS, then it means the user cannot, may not and must not change
the  boot mode, then DON'T COMPLAIN.

The errror is spurious, it gives false info, it pointlessly alarms users
about something that is not a problem.

If you let users do their own partitioning then trust them and don't
warn them over something that is not a problem.

The design is wrong. The decision is bogus. The assumptions are
incorrect.

This a Red Hat level of wrong-headedness, and I speak as a former RH
employee.

It is against the Ubuntu guiding principles of freedom and helping
users.

It is actively user-hostile because of things that whoever designed this
didn't think of.

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to ubiquity in Ubuntu.
https://bugs.launchpad.net/bugs/1893964

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

Status in ubiquity package in Ubuntu:
  Fix Released
Status in ubiquity source package in Hirsute:
  Fix Released

Bug description:
  Hello,

  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.

  Result:

  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)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1893964/+subscriptions