fsck "FEATURE_C12"?

torquebar · 2024-03-15 16:08:21

I have a data partition on the same ssd as the bootable systems. If I do this in Suser Slowroll for example

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

aluma · 2024-03-15 16:40:22

Similar problem and solution
https://askubuntu.com/questions/1497523 … -of-e2fsck

torquebar · 2024-03-15 17:14:44

didn't work for my problem, I tried from another booted system. I think the ultimate fix is an update of fsck, like the error message says..

aluma · 2024-03-15 17:38:18

Latest version of E2fsprogs
https://e2fsprogs.sourceforge.net/
If possible, it is better to use a live gparted session for such work
https://distrowatch.com/table.php?distribution=gparted

rolfie · 2024-03-15 17:57:15

I have something back in my mind that this problem maybe due to generating the file system with a brandnew kernel, and then trying to use it on an older distribution.

torquebar · 2024-03-15 18:02:57

it was probably formatted with bleeding-edge tumbleweed but it serves as a data partition for six or seven different systems

rolfie · 2024-03-15 18:24:37

Well, a fix could be to reformat it with the oldest distro that needs to access that partition.

torquebar · 2024-04-24 23:22:00

The

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

ralph.ronnquist · 2024-04-24 23:50:12

Is 1.46.6-1~bpo11+1 from chimaera-backports sufficient?

torquebar · 2024-04-25 02:15:20

Can't say, I know that 1-47.0 is C12 aware and that 1.46.2 (last in my updated Devuan) is not. A C12 aware version will not show the error AFAIK (I'm on Tumbleweed right now, doing an update).

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

boughtonp · 2024-04-25 14:35:31

The authoritative answer on what version Debian is running, is found by consulting Debian, (not a random comment on Reddit).

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

https://tracker.debian.org/pkg/e2fsprogs wrote:

o-o-stable: 1.44.5-1+deb10u3
o-o-sec: 1.44.5-1+deb10u2
oldstable: 1.46.2-2
old-bpo: 1.46.6-1~bpo11+1
stable: 1.47.0-2
testing: 1.47.0-2
unstable: 1.47.0-2.4

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/

Last edited by boughtonp (2024-04-25 14:37:41)

torquebar · 2024-04-25 15:05:03

Hold your horses.

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.

boughtonp · 2024-04-25 15:53:32

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

... is contrary to...

it was probably formatted with bleeding-edge tumbleweed

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.

chris2be8 · 2024-04-25 16:20:05

Try e2fsck -V to find out what version is *really* on each system. (You may need /sbin/e2fsck -V if you're not running as root.)

torquebar · 2024-04-25 23:32:29

There are actually 2 data partitions involved on my desktop that are also mounted in Devuan-Chimaera fstab (for a minute I thought it was a booted Devuan partition). These are data partitions that may have been formatted under any of the OS'es I use and all are marked "nofail" in every /etc.fstab including the Devuan one so issues with them should not halt the boot in the first place. If it weren't for this I might not even have noticed anything.

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.

The officially official Devuan Forum!

#1 2024-03-15 16:08:21

fsck "FEATURE_C12"?

#2 2024-03-15 16:40:22

Re: fsck "FEATURE_C12"?

#3 2024-03-15 17:14:44

Re: fsck "FEATURE_C12"?

#4 2024-03-15 17:38:18

Re: fsck "FEATURE_C12"?

#5 2024-03-15 17:57:15

Re: fsck "FEATURE_C12"?

#6 2024-03-15 18:02:57

Re: fsck "FEATURE_C12"?

#7 2024-03-15 18:24:37

Re: fsck "FEATURE_C12"?

#8 2024-04-24 23:22:00

Re: fsck "FEATURE_C12"?

#9 2024-04-24 23:50:12

Re: fsck "FEATURE_C12"?

#10 2024-04-25 02:15:20

Re: fsck "FEATURE_C12"?

#11 2024-04-25 14:35:31

Re: fsck "FEATURE_C12"?

#12 2024-04-25 15:05:03

Re: fsck "FEATURE_C12"?

#13 2024-04-25 15:53:32

Re: fsck "FEATURE_C12"?

#14 2024-04-25 16:20:05

Re: fsck "FEATURE_C12"?

#15 2024-04-25 23:32:29

Re: fsck "FEATURE_C12"?

Board footer