man e2fsck will show at the bottom the E2fsprogs parent package version # and as I noted in my Tumbleweed it's 1.47.0 , probably the same in Artix, in Devuan (Chimaera) it's 1.46.2 and I don't know the others off hand.

As far as I'm concerned the issue is moot as I will soon upgrade from Chimaera to Daedalus on the desktop as well.

I doubt very much that I would have installed Chimaera on a partition formatted by tumbleweed

... is contrary to...

In any case, if running e2fsck on Tumbleweed is changing the filesystems options to enable an otherwise disabled feature, that is either a Tumbleweed issue and/or operator error. (If running the command regularly is actually necessary, try doing it from a system that preserves compatibility, i.e. Daedalus.)

Devuan does not modify Debian packages unless they are systemd-entangled; since e2fs is unrelated to systemd, Devuan uses Debian's packages directly, as can be seen at pkginfo.devuan.org/e2fsprogs and the lack of "-devuan" in any of the versions.

Devuan team members have repeatedly pointed out that the Devuan devs have enough work keeping up with in-scope changes, so increasing their workload with out-of-scope tasks is simply not going to happen.

Not being a developer isn't relevant. Security issues aside, the potential way for getting a new version of a package into Chimaera/Bullseye repos is via Backports. If one doesn't have the ability/time/whatever to do that oneself, they must find someone who does.

Of course, given there is already a backported version for Bullseye/Chimaera, asking on the debian-backports mailing list about getting that updated would seem to be appropriate.

I doubt very much that I would have installed Chimaera on a partition formatted by tumbleweed :-)

What  I do, and that regularly, is something like

 # e2fsck -f /dev/sda19 

with fixes on a data drive from Tumbleweed for the simple reason that tumbleweed is my go-to system although the same data-drive is accessed from all other distro systems as well. Then when I next boot Chimaera I get the control-D alert.

I suggested the update as a fix merely as opposed to a workaround which is NEVER a fix. On my laptop 1.47 is in use by the Devuan system (that one being Daedalus I think) where the issue does not exist.

Finally not all Devuan (or any Linux) users are necessarily developers, last I heard.

At time of writing, //tracker.debian.org/pkg/e2fsprogs contains

So is it "C12 aware", and what does that even mean?

That same page links to the changelog, which usually would be enough to identify what is relevant, but "FEATURE_C12" is generated, so one must search the source for the error message: //sources.debian.org/src/e2fsprogs/1.47.0-2/e2fsck/unix.c/?hl=1832#L1832
Then search again for the definition of e2p_feature2string: //sources.debian.org/src/e2fsprogs/1.47.0-2/lib/e2p/feature.c/#L144

And one can then see that "FEATURE_C12" relates to the 12th Compat feature - i.e. EXT4_FEATURE_COMPAT_ORPHAN_FILE in versions that know what it is - but because earlier versions doesn't know of orphan_file feature, it gets the generated name. (If a similar issue was to re-occur in future, the error message would probably reference "FEATURE_C13" or "FEATURE_C14".)

Consulting the changelog one can see orphan_file is new in 1.47 (not in earlier versions), One can also see that Debian specifically patched it to turn the feature off by default, prior to Bookworm release, to avoid this exact backwards compatibility issue, so the issue only affects people who create filesystems on non-Debian-based systems.

The suggestion that the "fix" is to have Devuan devs spending their time to upgrade a package because a filesystem was formatted with a bleeding-edge Tumbleweed is absurd. It also demonstrates a lack of understanding of what Devuan is.

If you want 1.47 in Devuan Chimaera, you can work with Debian Backports team to determine if that can happen: //backports.debian.org/Contribute/

check this out:
==================================================
https://forums.linuxmint.com/viewtopic.php?t=409988
Failure Details:
* Many/most distros based on Ubuntu v22.04 will have e2fsprogs v1.46.5-2ubuntu1.1
* Many/most of the Arch-based distros will have e2fsprogs v1.47.0-1 (or newer)
* Debian is likely to have the same version as Ubuntu above or an older version

Update: According to u/Schwarzer-Kater, Debian 12 Bookworm (stable) has e2fsprogs version 1.47.0-2. Comment link ( https://www.reddit.com/r/DistroHopping/ ... &context=3 ).
==========================================

tune2fs -O ^orphan_file /dev/mydevice 

ritual is a workaround, the FIX would be to update E2fsprogs from 1.46.2  (2021) to 1.47.0 (2023), so I'm asking the 'nice' devs to plese do it. It's a non-lethal PITA but enough to make you wonder sometimes on boot if your system had been totally borked.

Hit Cntrl-D to continue 

is not what you wanna see on every boot :-)

# fsck /dev/sda10
fsck from util-linux 2.39.3
e2fsck 1.47.0 (5-Feb-2023)
/dev/sda10: clean, 16610/18022400 files, 63630170/72089600 blocks

This partition is normally automounted in fstab with a "nofail" switch

# /etc/fstab: static file system information Devuan on p12.
UUID=f203d9ec-a53c-4f33-ad2a-222cf8f8dbcd     /        ext4    errors=remount-ro 0  1
UUID=7de3fe4d-f350-4661-adf4-0159abacf3ff     swap     swap    sw,nofail         0  0
UUID=95cb7a9a-d7f2-4fb8-bf49-56828acf931c     /0/adat  ext4    defaults,nofail   0  2
UUID=2b43042f-761c-40ec-b207-5af655a51b93     /0/local ext4    defaults,nofail   0  2

So I would have presumed that inability to mount it would never fail the boot.

BUT...  when I try to boot Devuan the boot does at least stumble with a boot halt and the advisory to continue with a Cntrl-D. Subsequent check gives this:

# fsck -f /dev/sda10
fsck from util-linux 2.36.1
e2fsck 1.46.2 (28-Feb-2021)
/dev/sda10 has unsupported feature(s): FEATURE_C12
e2fsck: Get a newer version of e2fsck!

This Devuan partition is up to date (I think). It's not a federal case, I can live with it, just thought I'd mention it for the devs. As it is the data partition is unmounted while booted into Devuan (I have not tried manually mounting it).