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 Fri, Feb 17, 2023 at 10:34:29PM +0200, Adrian Bunk wrote:
>
> The same general problem applies in various "building non-Debian
> embedded Linux filesystem on Debian" situations where the target
> chroot does not contain mkfs.ext4.
In practice, if the root file system is using ext4, the target chroot
has to have e2fsprogs installed so that fsck.ext4 exists. So I'm not
sure it's all that unreasonable?
> Or if it is present, it would be a chroot for the target architecture
> where you might have to run mkfs.ext4 under qemu.
Sure, but that's not that difficult; I have a script[1] that will
setup chroots for foreign architectures which use binfmt_misc to run
(for example) arm32 or arm64 binaries using qemu on an x86 machine,
without needing to boot an arm32/arm64 kernel. For a more detailed
explanation see slide #8 of this slide deck[2]. The setup-buildchroot
script is turn-key; my experience is that several new college grads
and interns hired at $WORK have had no problems setting it up.
[1] https://github.com/tytso/xfstests-bld/blob/master/setup-buildchroot#L364
[2] https://thunk.org/android-xfstests
Also, in practice, if you are building an image for a foreign system,
you'll need to have a qemu setup to run the second stage of the
debootstrap in any case. I've just found it simpler to run the mkfs
and debootstrap in a chroot using qemu-user-static compared to messing
around with debootstrap --second-stage, which requires running a
chroot and qemu in any case.
> All image building tools that support bookworm (including all image
> building tools we ship in bookworm) have to ensure that what they
> produce works on the intended target. There is no general solution
> *how* to do that that could be applied in all cases.
Well, the general solution we can give them is instructions to adjust
/etc/mke2fs.conf on those systems needing to run those image building
systems. It's a one-line change. This can be documented in the
release notes, or in an e2fsprogs NEWS entry.
If the RT really insists, we can edit /etc/mkefs.conf for Bookworm to
not enable metadata_csum_seed by default. This will make it more
difficult for root file systems cloud VM's to be able adjust the file
system UUID on the fly, while the file system is mounted, so that's
the tradeoff. Quite frankly, the distro that I really care about for
$WORK is Arch, since Google's Cloud Optimized OS is based off of Arch
userspace packages. So if the Debian Release Team would like to
disable metadata_csum_seed by default in e2fsprogs, I will make that
change and upload a new version of e2fsprogs 1.47.0.
I don't think that's the right way to go, since I don't consider image
building to be a super-common use case, and those who do that can edit
/etc/mke2fs.conf on their own. However, I accept that this is the
Release Team's call.
If we do make this change to mke2fs.conf for Bookworm, my intention is
to upload a version of e2fsprogs which reverts this change as soon as
Bookworm ships as stable, so that Debian 13 will enable
metadata-csum-seed by default. At that point, people using Sid or
Debian Testing will have problems if they want to build images for
Bullseye, and I'll note that Daniel, who originally registered this
objection, was building images using Debian Unstable. So this will
will only give him a reprieve for a few months before he will need to
push changes to vmdb2 or make that one-line change to
/etc/mke2fs.conf.
If the Debian release team could let me know which path they would
prefer, I would appreciate it. At this point, the grub2 package
version (2.06-8) which supports metadata-csum-seed has migrated to
testing. So the only thing the e2fsprogs migration is now blocked on
is the RT's decision on this bug.
Best regards,
- Ted
Reply to: