Hi Julian,
On Thu, Oct 05, 2023 at 06:39:53PM +0200, Julian Andres Klode wrote:
> some of us would like to drop the following grub targets
> as we believe nobody uses them:
> * grub-coreboot
> * grub-efi-ia32
> * grub-firmware-qemu
> * grub-uboot
> * grub-xen
> Optimally also:
> * grub-efi-arm
> As in we would like the targets remaining to be:
> * grub-efi-amd64
> * grub-efi-arm64
> * grub-ieee1275 [dropping amd64 one, though; just keep ppc64el]
> * grub-pc
Why is it important to prune support for these targets? There is a lot of
stuff in the Ubuntu archive where we have no proof it's being used, but we
don't remove it unless it's become a maintenance burden. If you believe
nobody uses these targets, then there must not be bug reports about them, so
in what sense is it a maintenance burden to continue supporting them given
that support for them exists upstream?
Is there a proposal also to drop them in Debian? If not, doesn't this
divergence itself represent a greater maintenance burden?
I think the coreboot stuff remains an interesting target for potential
future development and we shouldn't necessarily prune it just because it's
currently unused.
(grub-efi-ia32, well, I can agree it's probably better to drop. There is
sadly hardware that requires it for boot, but we have never signed it for
SecureBoot and never will; and we have never supported it in the installer
and never will; so having the package in the archive in a sense just gives
users false hope. I think this is less an issue now than it used to be,
since the affected machines are by now also quite old.)
> Please let me know if that makes sense, if I missed anything
> (is anyone still using Xen?).
I think it's worth ensuring we explicitly hear from the Server Team on this,
but my experience is that even though xen is definitively in universe and
not a target that we explicitly support, over the past years whenever we
have done something that regresses Xen support, we hear about it from users.
So my expectation is that Xen is a small but ongoing concern for the
community.
> We really should revisit the question of BIOS support for 26.04
> or 28.04. Our grub postinst isn't updating BIOS grub for anyone
> anymore since boothole because stuff can break for BIOS systems
> if you upgrade them so um yeah. BIOS is a risky platform.
Well as the uploader of the change for
<https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1889556>, my
recollection was that this was intended to be a workaround for the immediate
breakage with the grub postinst and not that we disable BIOS grub updates
long-term. It is certainly programmatically possible to have a much more
robust upgrade path for grub-install on a pc-i386 target and make upgrades
possible again!
And if you're going to consider dropping grub-pc support then part of the
conversation needs to be about what sorts of hybrid boot support we choose
to have on our installer images, because we know historically that there are
machines which support UEFI when booting from internal hard disk but which
will only do BIOS boot from external devices (optical media and/or USB
stick). Just like 64-bit machines with 32-bit UEFI firmware, any such
machines are relics; but it would still be a shame for Ubuntu to drop
support for such hardware if it is otherwise still usable.
To be clear, it would make a lot of things easier if we did determine we
could drop not only BIOS boot support from our images, but also El-Torito
ISO boot support treating these images as only for flashing on USB drives.
It would remove one significant barrier for us adopting ubuntu-image for the
mastering of our installer images. But we should do the work to establish
that these things are no longer needed!
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer https://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org
