On Fri, 24 Feb 2023 at 16:56:23 +0100, Cyril Brulebois wrote: > Cyril Brulebois <k...@debian.org> (2023-02-19): > > Simon McVittie <s...@debian.org> (2023-02-19): > > > Are d-i alphas and weekly builds built differently? Is it perhaps the > > > case that alphas are built from testing udebs, while weeklies are built > > > from unstable udebs?
In conclusion: yes, that guess was correct. > Tentative fix in: > > https://salsa.debian.org/webmaster-team/webwml/-/commit/a22870164df5007ae4f4e356dfe54983be0f1e9e Thanks for fixing that! If I understand the situation correctly, that means the regression here is indeed caused by the mke2fs in e2fsprogs/unstable defaulting to creating a filesystem that cannot be fsck'd by the e2fsck in e2fsprogs/testing, because orphan_file is a "compat" feature which can be ignored without error by older kernels and other filesystem consumers like grub, but due to the nature of a fsck tool, e2fsck is unwilling to tolerate "compat" features that it doesn't understand? (This is orthogonal to the handling of "incompat" features as discussed (at some length) in #1030939.) If that's the case, then I think because of the way our d-i/debian-cd daily and weekly builds are done, filesystem maintainers need to make sure that their filesystem-creation tools don't enable a new feature by default until that feature is (at least minimally) supported by the corresponding fsck tool *in testing*, and immediately enabling a new feature as soon as the fsck tool in unstable supports it is too soon. In that case this report should probably be reassigned to e2fsprogs, as a request to stop enabling orphan_file by default until at least the time that e2fsprogs (>= 1.47.0) has reached testing (but perhaps lower risk to delay enabling it by default until post-bookworm). Cyril, sorry if I've been saying "d-i" too often here: I don't know which bits of this are a d-i responsibility and which are a debian-cd responsibility. I reported this to installation-reports because I didn't know which component was causing this, only that an installation that I thought was intended to be a supported use-case had failed. smcv