[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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



Control: retitle -1 d-i regression in weekly builds: FEATURE_C12 unsupported by the installed e2fsck

On Sun, 19 Feb 2023 at 14:39:12 +0100, Cyril Brulebois wrote:
> Simon McVittie <smcv@debian.org> (2023-02-19):
> > Graphical installation proceeded normally (in particular #1031620 is
> > fixed in this weekly build). However, on booting the installed system
> > for the first time, I got this error:
> > 
> > > /dev/vda1 has unsupported feature(s): FEATURE_C12
> > > e2fsck: Get a newer version of e2fsck!
> > > 
> > > /dev/vda1: ***** WARNING: Filesystem still has errors *****
> > > 
> > > fsck exited with status code 12
> > > The root filesystem on /dev/vda1 requires a manual fsck
> 
> Yes, e2fsprogs was kept out of testing, until grub2 was able to deal
> with the filesystems it generates, see #1030846, #1030939, #1031325.
> 
> D-I Bookworm Alpha 2 isn't affected, and this shouldn't be an issue
> whenever e2fsprogs is allowed into testing. But yeah, the testing you're
> conducting cannot work currently.

I confirm that alpha 2 does not exhibit this problem.

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?

I don't know how to list the versions of the installed udebs and
mke2fs doesn't seem to have a --version option, but in d-i alpha 2,
the /etc/mke2fs.conf visible in the d-i busybox shell has ext4 features:

has_journal,extent-huge_file,flex_bg,metadata_csum,64bit,dir_nlink,extra_isize

whereas the /etc/mke2fs.conf on my sid system adds two more features:
metadata_csum_seed and orphan_file.

I had expected that weekly builds are expected to be able to install
testing. If that expectation is correct, then that means weekly builds
need to be built from udebs that will create a filesystem that is
considered acceptable by testing user-space (and bootloaders and kernels,
but this bug report is about user-space).

> Closing this bug report as it's not a practical issue with the version
> just released, and since it shouldn't be an issue with later releases
> given grub2 in testing should cope just fine.

Note that my bug report is not about whether grub2 in testing copes
with the filesystem created by d-i: when I installed from the 2023-02-09
weekly build, grub successfully loaded my kernel and initramfs, so that
part at least seems fine. The issue I was having is that the *initramfs*
from the testing system I installed did not cope.

If I'm right about weeklies being built from unstable udebs, then I
think this will continue to be a problem *for weekly builds* until either:
a version of e2fsprogs that can fsck filesystems with metadata_csum_seed
and orphan_file migrates to testing; or e2fsprogs stops enabling those
features on at least the filesystems created in d-i (optionally all new
filesystems, but this particular bug report is about d-i only).

    smcv


Reply to: