Re: Bug#1031622: d-i regression in weekly builds: FEATURE_C12 unsupported by the installed e2fsck
On Fri, 24 Feb 2023 at 16:56:23 +0100, Cyril Brulebois wrote:
> Cyril Brulebois <kibi@debian.org> (2023-02-19):
> > Simon McVittie <smcv@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
Reply to: