On Sun, 19 Feb 2023 at 17:56:04 -0500, Theodore Ts'o wrote:
> On Sun, Feb 19, 2023 at 01:23:19PM +0000, Simon McVittie wrote:
> > I think this could be caused by debian-installer having udebs from
> > e2fsprogs 1.47.0-1 in the installation environment
>
> I thought the Debian-Installer would only be using udebs from Testing?
> I'm confused how it would be picking up e2fsprogs 1.47.0-1 from
> unstable, if it is going to be installing [testing]. Currently e2fsprogs is
> blocked from migrating to testing precisely because we didn't want d-i
> to be picking up e2fsprogs 1.47.0.
I'm surprised too, but I've just confirmed by looking at
/var/lib/dpkg/status from the d-i busybox shell that d-i alpha 2 has
e2fsprogs-udeb 1.46.6-1 from testing, but the weekly build where I saw
this regression has e2fsprogs-udeb 1.47.0-1 from unstable, which I can
only assume means that the weekly builds are (at least sometimes) built
out of unstable udebs even though by default they install testing.
The fourth type of d-i/debian-cd builds, other than official releases,
prerelease milestones (alpha/beta/rc) and weekly builds, are the daily
builds. I haven't checked whether those are built from testing or
unstable udebs.
> That being said FEATURE_C12 is the orphan_file feature which is only
> going to be enabled by default in e2fsprogs 1.47.0.
If e2fsck before the latest version is unable to fsck filesystems with
that feature, and our initramfs wants to fsck those filesystems (at least
minimally) before allowing them to be mounted, then it seems quite early
to be enabling that feature by default: a small amount of version skew
between installer and installed system will make the installed system
unbootable.
I could also see this being pretty bad for recovery systems where
people want to be able to mount the "real" system's rootfs and chroot
into it. All my non-virtual computers tend to have a small secondary
Debian install at the beginning or end of the disk to be used to fix
any particularly serious problems with their "real" installation, and
it's often not a matching release (so I can use an old-stable recovery
partition to fix problems with a new-stable production install), relying
on the fact that we tend to keep -1/+1 release compatibility.
I'd prefer it if you'd reconsider these new features being enabled by
default at filesystem creation time, particularly at this late stage in
the release cycle.
smcv
