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

[Daniel Leidert]

Am Montag, dem 13.02.2023 um 21:35 -0500 schrieb Theodore Ts'o:
> On Tue, Feb 14, 2023 at 01:01:38AM +0100, Daniel Leidert wrote:
> > Hi Steve,
> > 
> > I believe that your fix to grub2 in Sid is not enough to handle
> > #1030939/#1030846.
> > 
> > This problem breaks e.g. vmdb2. I can no longer create a Bullseye
> > system image with vmdb2 on Sid, because the grub-install step in the
> > Bullseye chroot now fails, because the created filesystem (created with
> > e2fsprogs on Sid) cannot be recognized by grub.
> 
> I'm confused, why does using vmdb2 on *sid* involve running
> grub-install on a *bulleye* chroot?

My workstation is running Sid. I want to create an image for Bullseye
(in this case using vmdb2, but I could do it manually as well). First,
one creates the paritioning and the filesystems for the target system
with the tools provided by the host system. This involves running the
unfortunate version of e2fsprogs with the breaking change. Then, one
installs the base system with deboostrap (also from the host system)
into the created partitions/filesystem. Then one (bind-)mounts the
virtual filesystems into the target systems, does a chroot into it, and
then one finishes the installation inside the chroot, including running
grub-install.

This is standard and common behavior. I have never ever seen in my
whole life someone to use grub2 from Sid to make a grub-install for a
Bullseye target. I have not even seen anybody suggest that.

Consider another example: Server providers use GRML or Bookworm with
e2fsprogs 1.47.0 as their rescue system. Now people are no longer able
to create a Bullseye system using the deboostrap method [1]. If the
host system uses e2fsprogs 1.47.0 or above and the target system for
[1] uses a grub without a fix, then this no longer works.

[1] https://www.debian.org/releases/stable/amd64/apds03

> That seems to be extremely ill-advised.

I'm sorry? I think you are completely missing the point.

> If you are trying to install a bullseye system, why
> can't you using vmdb2 on bullseye?

Because I am using Sid and because I use features of vmdb2 which are
not available in the version in Bullseye. And this feature breaks vmdb2
and similar tools. It also breaks a standard way of installing Debian
systems.

> And if you are trying to install a sid or bookworm system using vmdb2,
> why can't you (or vmdb2) use a sid or bookworm chroot for doing the
> grub-install?

What are you talking about? You basically break the toolchains and then
you suggest to do non-standard stuff to handle this or even avoid doing
installations of affected systems?!

> > I guess that the fix applied to grub2 in Sid would have to be applied
> > to grub2 in Bullseye as well (and basically to any grub2 package in any
> > Debian or Ubuntu or Raspbian release supported by debootstrap).
> 
> I can understand why we need to keep things synchronized so that a
> debian installer for Bookworm be able to generate a bootable system
> using the version of grub and e2fsprogs in Bookworm.
> 
> 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.

Daniel