Reluctant to upgrade from Fedora 40 to 41 because e2fsprog package changes in 2023 broke fsarchiver

Ask Fedora
1

Balancing “features” vs “quality” has always been difficult when dealing with technology. The last version of Fedora that could be archived and later restored using fsarchiver was Fedora 38.

E2fsprogs 1.47.0 (February 5, 2023) had some side effects:

  1. Fedora 39 and 40 ext4 filesystems cannot be fsck’d using Fedora 38 or earlier. This minor annoyance can be overcome using a bootable USB with Fedora 40 installed.

  2. Fsarchiver v8.5 available via Fedora 38, Fedora 39 and Fedora 40 cannot create an archive of a Fedora 39 or Fedora 40 ext4 partition.

  3. Fsarchiver v8.7 available via SystemRescue can create an archive of a Fedora 39 or Fedora 40 ext4 partion, but filesystem attributes of the restored partition are not the same as the original. This is not problematic when archiving a data partition but it causes grub2 to error when attempting to boot the restored partition.

Red Hat Bugzilla – Bug 2323389 was reported 2024-11-02 19:26 and has yet to be triaged.
During the chaos between beta and final release, such a delay should be expected.

My beef concerns POOR QA which failed to require useability testing of fsarchiver v8.5 in Fedora 39, Fedora 40 and Fedora 41 environments.

This bug that I have experienced coupled with a large number of bugs in Fedora 41 beta
suggest that much more time will be required to get a good release. Thus I will wait for Fedora 42 or Fedora 43.

2

You can simply build the latest fsarchiver in Fedora Copr:

sudo dnf install copr-cli

COPR_NAME="fsarchiver"
COPR_PKG="${COPR_NAME}"
COPR_DESCR="Filesystem archiver for Linux"
COPR_INSTR="sudo dnf install ${COPR_PKG}"
tee /tmp/${COPR_PKG}.sh << EOF > /dev/null
curl -L https://src.fedoraproject.org/rpms/${COPR_PKG}\
/raw/f$(rpm -E %{fedora})/f/${COPR_PKG}.spec \
| sed -r -e '/^Version:/s/\S+$/0.8.7/
/^Release:/s/\S+$/%{autorelease}/' > ${COPR_PKG}.spec
EOF

copr create ${COPR_NAME} \
--chroot fedora-$(rpm -E %{fedora})-$(arch) \
--description "${COPR_DESCR}" \
--instructions $'```\n'"${COPR_INSTR}"$'\n```' \
--enable-net on

copr add-package-custom ${COPR_NAME} \
--name ${COPR_PKG} \
--script /tmp/${COPR_PKG}.sh

copr build-package ${COPR_NAME} \
--name ${COPR_PKG}
3

Thank you for your suggestion. Neither fsarchiver v8.5 nor fsarchiver v8.7 deal with ext4 attributes that were added when the e2fsprogs package went live early in 2023.

There were very good reasons for the changes, so I am not unhappy that they occurred. Perhaps the reason that fsarchiver was not upgraded was controversy of whether the changes would survive or be reverted. More than 18 months later the e2fsprogs has been enhanced slightly but the added ext4 attributes remain.

I would be SHOCKED if fsarchiver v8.5 is not the version available with Fedora 41.

A version of fsarchiver newer than 8.7 is required. If/when the bug that I reported gets acted upon, a newer version will become available.

4

Note, fsarchiver-0.8.7 is currently the latest upstream release, so reporting to the Fedora maintainers may not help you much, as the problem is software related and not related to packaging, that’s why it is best to contact the author/developer directly by opening an issue upstream:

5

With any luck, this problem will be resolved before release of Fedora 42. Otherwise, I might get the almost normal “Fedora xx has reached EOL. If the bug persists in a current version please resubmit” message.

In the meantime, those curious about Fedora 41 will be alerted concerning this issue.

6

Only if someone, you for example, opens an issue with the maintainer.

7

@ernie-07 if possible could you change the topic title to something that reflects the actual issue you are looking to solve?

It will help inform people better about the contents of the thread. It would also be preferable to avoid the use of hyperbolic language and all-caps text.