Bug#1031325: e2fsprogs 1.47.0 introduces a breaking change into Bookworm, breaking grub and making installations of Ubuntu and Debian releases via debootstrap impossible
Am Donnerstag, dem 16.02.2023 um 20:10 +0200 schrieb Adrian Bunk:
[..]
> I am currently spending time trying to summarize the situation and open
> questions, and I am a bit underwhelmed by the inaccuracies and lack of
> technical detail in your emails.
Well, I didn't have weeks to prepare. I had <24 hours and gave you
already enough information so you did not have to start from scratch.
I will summarize my points at the bottom.
> The instructions you cite in [1] are for installing bullseye from
> non-Debian systems.
That is simply not true. Those are general instructions, they are not
limited to non-Debian systems. Most server providers have exctly *one*
rescue system from where I can do a clean installation with deboostrap
(and that even usually is a Debian). I cannot choose to use one that
hasn't an e2fsprogs that has this breaking change enabled. Say for
example, grml, used by multiple providers I know as rescue system and
based on Debian, picks up Bookworm with e2fsprogs with that change. Now
users trying to install anything other than a Debian Bookworm using the
deboostrap method will run into the situation that "grub-install" will
fail, and it won't even indicate that they will have to tune the just
created ext4 filesystem or even change /etc/mke2fs.conf. I spent a few
hours until I tracked it down. And the situation right now is, that I
can simply install any system with the deboostrap method. I'm not aware
that there are any breakages or incompatibilities.
> What bookworm ships does not matter much there,
> these instructions will be wrong as soon as some *other* distribution
> like Fedora changes the default.
Fedora isn't used much as a rescue system, don't you think? Have you
ever encountered that? I do custom server setups with deboostrap for
almost two decades now. I haven't seen any distribution so far that
changed the created filesystem to be incomatible with grub-install from
the systems that might be installed. Most of the rescue systems were
Debian based, JFTR.
> I am wondering how exactly your often repeated "there is no grub
> upstream release with support for it" would be relevant in practice.
> Whether it's 2.06-8 or 2.07-1 in bookworm shouldn't make a difference.
You completely miss the point here. It would lead to exactly the same
situation if 2.07 would be the *first* to support it and could be
shipped with Bookworm as long as e2fsprogs makes this breaking change
now. But it makes a huge difference if 2.07 with a fix is released in
around the same time as Bookworm and can spread until Trixie is
prepared and the breaking change is postponed to Trixie. Ubuntu 24
would have picked up that fix by then. 22 and maybe even 20 would
probably have picked it up either. Even bullseye could get a patch to
deal with that. The breakage would have less impact than it has now,
while nothing is prepared.
And it is completely illusional to say that people should first create
a Bullseye chroot to then do a deboostrap setup of a target system from
that chroot, as Theodore suggested. Well, I'm more than underwhlemed by
suggestions like this.
> Sebastian has now created #1031364 for your original vmdb2 problem,
> everyone discussing in #1030939 seems to have missed that tools in
> bookworm creating images for < bookworm must handle such changes.
> That's not different from debootstrap having code to handle
> apt-transport-https being required in some older releases.
I agree. So don't you think introducing this now is a really bad
timing?
I checked a search engine to find out what this feature even does.
Turns out, there were less than 500 hits. It is a feature available
since kernel 4.4 and not widely used nor default. So what is the gain
here? I also tried to understand why our users would need to be able to
change the UUID of the filesystem. In 20 years with Debian, I haven't
encountered a situation where this has been necessary (I didn't even
know that one could). My gut feeling is, that this feature is only
useful to a handful of people. I haven't heard any explanation so far
why this needs to be turned on by default just now. The whole
discussion so far has been Theodore argueing why he doesn't care about
his actions and why he doesn't have to.
If this feature should be turned on, then I still think that doing this
for Trixie is the better choice. The tools affected can be fixed to
work around the issue. The other distributions can pick up the grub-
install fix.
And JFTR: The attitude I preceived since I got into the discussion with
the simple sentence that fixing grub in Bookworm might not be enough,
can be summarized as "I/we don't care". So, sorry, I care, even if my
less excellent mails might be underwhelming for you.
Daniel
Reply to: