Inhibit upgrades with unsupported XFS

[dkubek]

Kernel in RHEL 10 drops support of XFS v4 format file systems and such file systems will not be possible to mount there anymore. Also, RHEL 10 systems will be challenged by Y2K38 problem. XFS file system resolves that by bigtime feature, however, this feature could be manually disabled when creating the file system and mainly it's available since RHEL 9. So all XFS file systems created earlier will not have this enabled - unless users do it on RHEL 9 manually. Note that this will be problem for all systems with XFS which upgraded from previous RHEL versions.

For this reason, inhibit the upgrade if any mounted XFS file systems have old XFS v4 format (detect crc=0).

Instead of inhibiting upgrade when the bigtime feature is disabled (bigtime=0 or missing) a low severity report is created as there is still time until this issue will be present and other solutions are being worked on.

Introduces new model XFSInfoFacts which collects parsed information about all mounted XFS file systems. Note that as we use only a few values from xfs_info utility, models specify now just this limited amount of values as well to limit the burden of maintanance and risk of issues. However expected design of the model is already prepared and other expected fields are commented out in the code to make the further extension in future more simple for others. All values of XFS attributes are now represented as strings.

Introduce shortened-urls:

• https://red.ht/rhel-9-xfs-bigtime
• https://red.ht/rhel-9-xfs-backup
• https://red.ht/rhel-9-xfs-restore-from-backup

JIRA:
RHELMISC-8212 (spike)
RHEL-60034
RHEL-52309

[github-actions]

Thank you for contributing to the Leapp project!

Please note that every PR needs to comply with the Leapp Guidelines and must pass all tests in order to be mergeable.
If you want to request a review or rebuild a package in copr, you can use following commands as a comment:

• review please @oamg/developers to notify leapp developers of the review request
• /packit copr-build to submit a public copr build using packit

Packit will automatically schedule regression tests for this PR's build and latest upstream leapp build.
However, here are additional useful commands for packit:

• /packit test to re-run manually the default tests
• /packit retest-failed to re-run failed tests manually
• /packit test oamg/leapp#42 to run tests with leapp builds for the leapp PR#42 (default is latest upstream - main - build)

Note that first time contributors cannot run tests automatically - they need to be started by a reviewer.

It is possible to schedule specific on-demand tests as well. Currently 2 test sets are supported, beaker-minimal and kernel-rt, both can be used to be run on all upgrade paths or just a couple of specific ones.
To launch on-demand tests with packit:

• /packit test --labels kernel-rt to schedule kernel-rt tests set for all upgrade paths
• /packit test --labels beaker-minimal-8.10to9.4,kernel-rt-8.10to9.4 to schedule kernel-rt and beaker-minimal test sets for 8.10->9.4 upgrade path

See other labels for particular jobs defined in the .packit.yaml file.

Please open ticket in case you experience technical problem with the CI. (RH internal only)

Note: In case there are problems with tests not being triggered automatically on new PR/commit or pending for a long time, please contact leapp-infra.

[dkubek]

Note for reviewers. To test the code using different XFS configurations you can create the filesystem in a file:

# 1. Create a sparse file
fallocate -l 500M test_xfs.img

# 2. Format the file with an XFS filesystem (for example, with crc 0)
mkfs.xfs -f test_xfs.img  -m crc=0

# 3. Create a mount point
mkdir -p /mnt/test_xfs

# 4. Attach the file to a loop device
LOOP_DEVICE=$(losetup -f --show test_xfs.img)

# 5. Mount the loop device
mount $LOOP_DEVICE /mnt/test_xfs

[pirat89]

Seems that errors in tests are caused by tests or infrastructure.

[pirat89]

lgtm - great job! I am doing some manual testing yet, I will merge it when I finish it, but giving approval already as I expect it will be ok

[pirat89]

Initial setup (orig system is EXT4). Create and mount various XFS file systems

fallocate -l 500M test_xfs_nocrc.img
fallocate -l 500M test_xfs_crc_nobtime.img
fallocate -l 500M test_xfs_crc_btime.img

mkfs.xfs -f test_xfs_nocrc.img  -m crc=0
mkfs.xfs -f test_xfs_crc_nobtime.img  -m crc=1,bigtime=0
mkfs.xfs -f test_xfs_crc_btime.img  -m crc=1,bigtime=1

mkdir -p /mnt/test_xfs_{nocrc,crc_nobtime,crc_btime}
mount "$(losetup -f --show test_xfs_nocrc.img)" /mnt/test_xfs_nocrc
mount "$(losetup -f --show test_xfs_crc_nobtime.img)" /mnt/test_xfs_crc_nobtime/
mount "$(losetup -f --show test_xfs_crc_btime.img)" /mnt/test_xfs_crc_btime/

The report:

Risk Factor: high (inhibitor)
Title: Detected XFS filesystems incompatible with target kernel.
Summary: XFS v4 format has been deprecated and it has been removed from the target kernel. Such filesystems cannot be mounted by target system kernel and so the upgrade cannot proceed successfully. Following XFS filesystems have v4 format:
    - /mnt/test_xfs_nocrc
Related links:
    - Backing up an XFS file system: https://red.ht/rhel-9-xfs-backup
    - Restoring an XFS file system from backup: https://red.ht/rhel-9-xfs-restore-from-backup
Remediation: [hint] Migrate XFS v4 filesystems to new XFS v5 format. For filesystems hosting data, perform a back up, reformat, and restore procedure. Refer to official documentation for details. For filesystems hosting the system a clean installation is recommended instead.
Key: 32aa06fdac823fbaf1b7aee96956f869b402c9a9
----------------------------------------
Risk Factor: low
Title: Detected XFS filesystems without bigtime feature.
Summary: The XFS v5 filesystem format introduced the "bigtime" feature in RHEL 9, to support timestamps beyond the year 2038. XFS filesystems that do not have the "bigtime" feature enabled remain vulnerable to timestamp overflow issues. It is recommended to enable this feature on all XFS filesystems to ensure long-term compatibility and prevent potential failures. Following XFS file systems have not enabled the "bigtime" feature:
    - /mnt/test_xfs_crc_nobtime
    - /mnt/test_xfs_nocrc
Related links:
    - XFS supports bigtime feature: https://red.ht/rhel-9-xfs-bigtime
Remediation: [hint] Enable the "bigtime" feature on XFS v5 filesystems using the command:
        xfs_admin -O bigtime=1 <filesystem_device>

Note that for older XFS v5 filesystems this step can only be done offline right now (i.e. without the filesystem mounted).
Key: efdddcf24f48b61eabf1bac6592f6abba92182b1
----------------------------------------

[pirat89]

ah :D we forgot to drop it. nevermind. merging anyway. can be cleaned in furure.