Rebasing a Fedora IoT installation from 39 -> 38 fails to boot and drops to dracut with the error: /dev/mapper/fedora--iot-root has unsupported feature(s): FEATURE_C12 e2fsck: Get a newer version of e2fsck! Reproducible: Always Steps to Reproduce: 1. Boot Fedora 39 and rebase to Fedora 38 2. Boot fails and drops to an emergency shell 3. run 'systemctl status systemd-fsck-root' Actual Results: /dev/mapper/fedora--iot-root has unsupported feature(s): FEATURE_C12 e2fsck: Get a newer version of e2fsck! Expected Results: Booted system Booting with "fsck.mode=skip" works as expected.
What does "Boot Fedora 39 and rebase to Fedora 38" mean - downgrade? I did not know that was possible, but if you did, it's not a bug that older package cannot process newer disk formats. Can you please explain what the "rebase" action is? Based on Ted's reply in a Debian bug report, "FEATURE_C12 is the orphan_file feature which is only going to be enabled by default in e2fsprogs 1.47.0" If you create a filesystem with a newer e2fsprogs, and it creates new on-disk features that older e2fsprogs cannot handle, that would not be considered a bug.
(In reply to Eric Sandeen from comment #1) > What does "Boot Fedora 39 and rebase to Fedora 38" mean - downgrade? I did > not know that was possible, but if you did, it's not a bug that older > package cannot process newer disk formats. > > Can you please explain what the "rebase" action is? A downgrade on ostree based systems, apologies for not being clear. This is a test run in OpenQA in Fedora. > > Based on Ted's reply in a Debian bug report, "FEATURE_C12 is the orphan_file > feature which is only going to be enabled by default in e2fsprogs 1.47.0" > > If you create a filesystem with a newer e2fsprogs, and it creates new > on-disk features that older e2fsprogs cannot handle, that would not be > considered a bug. Understood, closing.