Bug#1030846: Bug#1030939: e2fsprogs: generates filesystems that grub-install doesn't recognize

[Daniel Leidert]

Am Dienstag, dem 14.02.2023 um 10:45 +0000 schrieb Steve McIntyre:
> On Tue, Feb 14, 2023 at 11:34:13AM +0100, Daniel Leidert wrote:
> > Am Montag, dem 13.02.2023 um 21:35 -0500 schrieb Theodore Ts'o:
> 
> ...
> 
> > > But a generalized requirement that we be able to use debootstrap and
> > > vmdb2 to be able to bootstrap an arbitrarily old distribution doesn't
> > > seem to be reasonable.
> > 
> > You are completyl wrong. This breaks a standard way of installing any
> > system supported by deboostrap with a grub without a fix to deal with
> > this version of e2fsprogs. This isn't just about vmdb2.
> > 
> > What you are saying is ignorant.
> > 
> > If this isn't cared about, then this version of e2fsprogs shouldn't
> > make it into Bookworm. We are in the middle of a freeze and this breaks
> > toolchains and a standard way (see [1]) of installing Debian.
> 
> Sorry Daniel, but I have to (mostly!) agree with Ted here. If you're
> creating an image of an older release using newer tools then you'll
> need to be aware that sometimes the newer tools will create things
> that don't work there. If there's a bug here, I would strongly argue
> that it's in vmdb2. deboostrap (for example) includes some
> release-specific knowledge to cope with issues like this.

debootstrap does nothing related to grub. So it is a bad example. Again
I refer to [1]: If the host system contains the problematic e2fsprogs
and the target system doesn't contain a grub with the fix [2], then
this breaks installations. This breaks older systems *and* current
systems. For example, I neither see the necessary grub patch in both
Ubuntu 20.04 and 22.04 either. So they also cannot be installed using
the deboostrap method and the toolchain in Sid (and Bookworm if
e2fsprogs makes it there). 

[1] https://www.debian.org/releases/stable/amd64/apds03
[2] Even "our" grub only contains a patch and not an upstream version
with support. So how can you even expect the target system to contain a
fix and be able to handle the created filesystem?!

Whe whole handling is completely wrong here. First, grub should have
been fixed upstream. And the change in e2fsprogs should have been done
only after "fixed" grub versions had settled. If we do it the other way
around, we have to patch grub in affected distributions as well. And
for Debian that means at least to patch Bullseye and any other release
we want to be able to install from Bookworm. I even a lot of companies
using Buster still.

> If we don't allow for this kind of change, that wouldn't allow us to
> *ever* make breaking changes in some packages, and that's just not
> sustainable.

I'm critizicing the way of handling that breaking change and the
ignorance shown reagarding the impact, not that fact that there is a
breaking change. And it breaks a lot! This doesn't affect just a few
minor use cases. It affects the basic way of installing a clean Ubuntu
or Debian (or derivative) on a remote server using the debootstrap
method.


And again: We are in the middle of a freeze here. And e2fsprogs pushes
a breaking change that is not even handled by any existing grub
upstream release, and is also not properly handled within Debian?!

Daniel