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
On Thu, Feb 16, 2023 at 11:45:23AM -0800, Russ Allbery wrote:
>
> Yes, I'm probably understating the difficulty of making this change in
> practice inside image building software as it's currently constructed.
>
> My concern about changing mkfs options is that I worry that this would be
> a constantly-changing target that has to be synchronized across multiple
> pieces of software that are not currently well-aligned with file system
> development. One thing that would make this much easier would be for mkfs
> to support some sort of compatibility level flag that sets all of the
> options, whatever they may be, to their defaults as of some point in the
> past. Image building software could then pick a conservative default set
> point when building images for older distributions. That change still has
> to be added to all of the image building software, but it might be easier
> than building a local chroot of the target distribution before using it to
> build the file system the actual installation is going into.
As a long-term solution, one could image changing the various image
creation tools to do something like "mfks.ext4 -T grub2_dumbdown
/dev/XXX", and then have something like the following in
/etc/mke2fs.conf:
[fs_types]
grub2_dumbdown = {
features = ^metadata_csum_seed,^casefold
}
If you care about being able to run fsck.ext4 on really old
distributions, one could even add things like
[fs_types]
jessie_dumbdown = {
features = ^metadata_csum_seed,^metadata_csum
}
etc.
Maintaining this would be a nightmare, and I'd want to ask for help,
since this would be change if we also want to add dumbdown file system
usage types for Ubuntu, and potentially, other Debian derivitives.
Even if we stick with grub2_dumbdown, again, how far back do we go?
Some people have said, "just one release", but I bet there will be
people wanting to create Stretch installer images using a sid
userspace. So I'd want to have some kind of formal understanding
about what it is that we feel obliged to support.
Given the number of users of the iamge building tools, it's a pretty
specialized use case with not a lot of users, and they can also just
edit /etc/mke2fs.conf to have their favored default. From my
e2fsprogs maintainers hat on, that's my position --- I interpret
"users" in the Debian Social Contract for the general users, and not
necessarily something that needs to work for every single exotic use
case, especially if they tend to be more of the power users.
If we're not allowed to inconvenience *any* users, then it's hard to
make forward progress. Certainly some people (including myself) were
inconvenienced for things like /usr-unification and the transition to
systemd. We went ahead with the transition even though some users
were inconvenienced. And quite honestly, if a few power users need to
edit /etc/mke2fs.conf to remove metadata_csum_seed because they want
to do something which is *REALLY* not a good idea (using Debian M to
build a file system meant for use on Debian M-X) --- for *ALL* file
systems, not just ext4. It may be that some users have gotten lucky,
and it mostly works. But it's a bad idea, and encouraging this bad
practice is eventually going to lead to tears.
But, if the Debian Release team would like to override my position, my
suggestion would be to just change the default for /etc/mke2fs.conf
for *everyone* running Debian bookworm, and with the understanding
that this will be reverted in Debian testing after the next stable
release, and that moving forward, we make it the image building tools
problem if they want to support this highly dubious practice of using
Debian N+X's mkfs to build images for Debian N. I would strongly
suggest that they figure out which file system features they need to
explicitly turn off for ext4, xfs, btrfs, etc., if they want to build
old distro versions using whatever random software they have installed
on their desktop.
Best release engineering practice is that you use a known, controlled
build environment, and not whatever random package versions might be
on your desktop. While that might be "inconvenient" when building
packages, we've learned to live with it. I use sbuild; others might
use pbuild, or their own custom schroot setup. But I dare say all
responsible people doing release engineering use a known build
environment. Why should this be any different if you are building
images --- especially images that you expect *your* users or customers
to be depending on? What are your responsibilities to them? (Whether
or not the Debian Social contract applies to them or not.)
- Ted
Reply to: