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
