Ubiquity does not raise an informative error when device for bootloader has MBR (should be GPT)

[Benjamin Bach]

Thanks for a good installation experience :) I have one unfortunate experience that took me many many hours to work through.

Ubiquity should raise an error when a device chosen for the bootloader has an unsupported MBR table and not GPT. AFAICT, Ubuntu's grub installation only supports EFI so that requires GPT.

Error suggestion: "Invalid partition table detected. Cannot complete installation. Please install bootloader on another device or choose New Partition Table (warning: All data will be lost)."

User experience is this: I chose "Something else" to do manual partitioning. I tried many different options for partitioning and restarted the installation many times. They all lead to a grub installation error at the final step after copying all files. As a user, I'd persistently try to make the existing partitions work to avoid copying gigabytes of data in and out of the drive.

It's possible to claim that manual partitioning should be 100% the user's responsibility, but I would still expect an error to be raised if something in the setup is incompatible.

The error from grub itself is also not informative.

By rewriting the partition table, I got a valid GPT layout and the installation succeeded.

[Benjamin Bach (benjaoming)]

Adding this for context.

[Chris Guiver (guiverc)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. Please execute the following command only once, as it will automatically gather debugging information, in a terminal:

apport-collect 2008948

When reporting bugs in the future please use apport by using 'ubuntu-bug' and the name of the package affected. You can learn more about this functionality at https://wiki.ubuntu.com/ReportingBugs.

No specifics as to ubiquity version, what release, what ISO you were using were provided as I see it, if you use apport tools to file the bug report these are automatically provided. Please boot your installation media & run `apport-collect` from there, OR you could try your installed system (the installed system won't have `ubiquity` installed which maybe a problem (for apport-collect), but it will have ubiquity's log). If the log is required it maybe requested & you can upload then.

(You do realize `ubiquity` is on ~life-support; 23.04 is expected to have ISOs available with the replacement installer and an alternate ISO with `ubiquity`, so if due to problems with the desktop-installer their is the alternate with ubiquity installer. This may change with beta about to hit & hopefully we'll get loads of testing)

[Benjamin Bach (benjaoming)]

It's understandable that Ubiquity is on lifesupport and issues have to have a certain seriousness to be addressed, I'll leave that to someone else to assess: the situation is that something has disrupted how Ubiquity is designed, namely that EFI is now the only valid bootloader and MBR isn't supported (right?).

There was nothing of interest in logs because the grub-installer message isn't very good (that could be a separate report).

This is the error message:

error: Failed to register the EFI boot entry: Operation not permitted.

I did trawl through all other approaches that I could find and I'm very sure that this error message is due to the MBR/GPT issue, since the error was 100% persistent in all attempts to fix it until I rewrote the partition table. I was debugging by running grub-install from chroot /target.

While using the wrong partition table, I could run grub-install --nonvram without errors, but that didn't leave /dev/sda in a bootable state.

> You do realize ubiquity is on ~life-support

Now you mention it, I remember the headlines -- I'll be installing Ubuntu 22.04 until 24.04 is out and stable :) I really like Ubiquity, but I have noticed that it has developed almost nothing on the UI surface in the past 4-5 years which of course makes it understandable from a user's POV: the old installer project has declined enough to make it necessary to rewrite. This issue is the kind of issue that could be triaged for ubuntu-desktop-installer as well: Does subiquity fail with an informative error message if the current partition table is detected to be invalid?

I also noticed advice that an efi partition must be a primary partition, but since GPT only has primary partitions, I'm not sure if that is necessary to validate.

Maybe the easiest method is to schedule a systematic triage of issues in Ubiquity to copy over the feedback that is relevant for ubuntu-desktop-installer. Once beyond simpler issues that are currently on the ubuntu-desktop-installer GitHub tracker, discovering a bug in the installer will become harder and harder and reporting things will get heavy on users and testers. Therefore, old feedback scenarios might be valuable. And might not :)

[Dan Bungert (dbungert)]

> Does subiquity fail with an informative error message if the current partition table is detected to be invalid?

Subiquity screens for this sort of problem ahead of time, it has checks for if we think the system will be bootable or not and only allows the user to proceed if we think it will boot. Subiquity also knows how to handle all four cases of (BIOS boot, UEFI boot) x (DOS partition table, GPT), so it is actually valid to do something like UEFI boot on a MSDOS partition table.

[Aki Ketolainen (akik)]

> You do realize `ubiquity` is on ~life-support

Are you going to test the existing bug reports against Subiquity? The Ubuntu 22.04 LTS still uses Ubiquity so I don't understand why there wouldn't be fixes to it.