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

[Steve McIntyre]

On Tue, Feb 14, 2023 at 12:50:18PM +0100, Daniel Leidert wrote:
>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.

That's why I said *like* this, not *exactly* like this. debootstrap
has had knowledge of things like fs layouts etc. that older releases
need (e.g. merged-/usr).

>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).

Breakages happen like this, and this has happened before in similar
circumstances. If you're installing an older system using brand-new
tools, you need to be aware of the potential for things to not
work. In this particular case, all you need to do is tweak the flags
on the ext4 filesystem when you create it. This isn't that hard...

>[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.

And I know of folks still working on Stretch and Jessie. How far back
do you want to tie things??

>> 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.

People using these tools need to be aware of the potential issue. What
would happen if you ran debootstrap with a filesystem that the target
distro doesn't know how to mount at all, for example?

>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?!

Grub upstream is already known to be problematic in terms of release
cycles. We now know about this particular issue (thanks Ted!) and
we've fixed it in unstable (and soon testing).

-- 
Steve McIntyre, Cambridge, UK.                                steve at einval.com
Who needs computer imagery when you've got Brian Blessed?