Re: Bug#1031622: d-i regression in weekly builds: FEATURE_C12 unsupported by the installed e2fsck

Cyril Brulebois <[email protected]> Fri, 24 Feb 2023 18:43:05 +0100
Newsgroups	gmane.linux.debian.devel.cd
Organization	Debian
Message-ID	<[email protected]>
Simon McVittie <[email protected]> (2023-02-24):
> 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?

Just to be clear: mke2fs from e2fsprogs-udeb/unstable (the “installer is
based on Debian unstable” part) creating a file system that fsck from
e2fsprogs/testing (the “install Debian testing” part) doesn't understand.

(e2fsprogs/unstable as a binary package wasn't involved in your scenario.)

> 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.

That would seem sensible to me.

> 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).

The immediate issue should go away for Bookworm anyway:
  https://bugs.debian.org/1031325#202

And once the feature is turned off, the package might migrate, and
everything should be all set for when the feature is turned on again.
But feel free to reassign this bug report to keep track of it, there's
nothing to be done on the debian-boot/debian-cd side.

> 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.

That's fine, debian-cd has been Steve mostly, even if I've been getting
more involved over the last two release cycles; bugs reports generate the
same “bug ownership” feeling when they pop up in either side. Both
debian-installer and debian-cd (as in debian-cd.git and setup.git) are
inherently intertwined anyway.

(Except when I'm utterly confused by a longstanding documentation vs.
reality mismatch) I tend to have a vague idea of what's going on in both
areas to figure things out…

> 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.

Everything you did was very fine. I just didn't realize we were actually
publishing images where we ship known bugs… :(


Cheers,
-- 
Cyril Brulebois ([email protected])            <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant
signature.asc (application/pgp-signature, 833 B)