grub-install command line options incompatible with Debian

[Antonio Terceiro]

I'm working on creating an autopkgtest-build-qemu tool for autopkgtest using vmdb2. When vmdb2 is trying to setup grub in an Ubuntu VM image, it fails like this:

ERROR: Command failed: chroot /tmp/tmpvsayg7te grub-install --target=i386-pc --no-nvram --force-extra-removable --no-floppy --modules=part_msdos part_gpt --grub-mkdevicemap=1
b''
b"grub-install: unrecognized option '--force-extra-removable'\nTry 'grub-install --help' or 'grub-install --usage' for more information.\n"

I noticed by reading the changelog that grub2 diverges from Debian there, and I don't particularly care about the details. However, having incompatible command lines unnecessarily breaks stuff that works in Debian and would otherwise Just Work in Ubuntu.

So, I would suggest that the --force-extra-removable option is kept in Ubuntu as a no-op.

[Mathieu Trudel-Lapierre (cyphermox)]

I disagree. This needs to be fixed in Debian as well -- none of the options are crazy hacks, they are taken as explicit decisions meant to fix actual problems that people are having.

I have to rebase the patches for Debian, sure; but I don't think we should leave breadcrumbs around because a test would otherwise fail because of slight differences between Debian and Ubuntu.

[Colin Watson (cjwatson)]

As the Debian maintainer, I entirely disagree. Even though it's now the default behaviour, --force-extra-removable should be kept as a no-op, because it's used by other software. Interfaces matter.

[Colin Watson (cjwatson)]

(To be clear, I disagree with Mathieu and agree with Antonio.)

[Mathieu Trudel-Lapierre (cyphermox)]

I have an issue with leaving cruft around instead of actively fixing whatever depends on old behavior; months from now, or even years, we'll still have this switch around that does nothing -- that's more confusing for users than actively moving forward.

That said, I'll defer to Colin and add the no-op.

Are you saying that you otherwise have no issues with the idea of this patch and would consider including it in the Debian package?

[Launchpad Janitor (janitor)]

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

[Colin Watson (cjwatson)]

Thanks.

I think I'm basically OK with the idea of this patch, but I'd want to see it in isolation rather than needing to dig through the whole Ubuntu delta for it. Maybe I could have a merge request or something?

[TimSmall (tim-seoss)]

Hello,

FWIW this breaks the vmdb2 on Ubuntu ("grub: uefi" steps break), and makes it impossible to build uefi bootable Ubuntu images. It would be great to get his merged as a noop, perhaps it would best if the output warned that this is a deprecated flag and is a noop, to discourage its future use, and make sure it eventually goes away when this no longer risks breaking anything.

[Florian Bruhin (the-compiler)]

This also keeps me from using vmdb2 to build a custom Ubuntu image. FWIW I opened https://gitlab.com/larswirzenius/vmdb2/-/issues/36 to discuss fixing this from the vmdb2 side instead, which might be an alternative solution.

[Zygmunt Krynicki (zyga)]

I've sent a patch to https://gitlab.com/larswirzenius/vmdb2/-/issues/36#note_485816538 which enables support for Ubuntu and Debian

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "This patch is against the vmdb2-0.19 upstream tag" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

[Zygmunt Krynicki (zyga)]

This is now fixed upstream https://gitlab.com/larswirzenius/vmdb2/-/merge_requests/83