Fedora Account System
Red Hat Associate
Red Hat Customer
Releases retrieved: 7.0.1 Upstream release that is considered latest: 7.0.1 Current version/release in rawhide: 7.0.0-1.fc45 URL: https://git.kernel.org/pub/scm/fs/xfs/xfsprogs-dev.git Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://docs.fedoraproject.org/en-US/package-maintainers/Upstream_Release_Monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from Anitya: https://release-monitoring.org/project/5188/ To change the monitoring settings for the project, please visit: https://src.fedoraproject.org/rpms/xfsprogs
Created attachment 2142071 [details] Update to 7.0.1 (#2480133)
the-new-hotness/release-monitoring.org's scratch build of xfsprogs-7.0.1-1.fc43.src.rpm for rawhide completed http://koji.fedoraproject.org/koji/taskinfo?taskID=145677530
Lets move: /usr/lib/systemd/system/system-xfs_healer.slice /usr/lib/systemd/system/xfs_healer@.service /usr/lib/systemd/system/xfs_healer_start.service from the xfsprogs-xfs_scrub package to the xfsprogs package. Currently people have to install the scrub package to get the healer systemd unit file.
Created attachment 2142087 [details] xfsprogs.spec for 7.0.1 Here's a patch to update the xfs_healer packaging and fix a warning about a .build-id being included twice
Here's COPR build of xfsprogs 7.0.1 https://copr.fedorainfracloud.org/coprs/allenhewes/xfsprogs/build/10488570/ Could xfsprogs 7.0.1 make it to Fedora 43+, please?
(In reply to rallenh from comment #4) > Created attachment 2142087 [details] > xfsprogs.spec for 7.0.1 > Thank you. Can you create a pull request here: https://src.fedoraproject.org/rpms/xfsprogs please? If you decide to send a PR, can you explain or drop these lines: + Obsoletes: xfsprogs-xfs_healer < %{version}-%{release} + Provides: xfsprogs-xfs_healer = %{version}-%{release} As far as I know, xfsprogs-xfs_healer was never an official package, so this should not be in the official spec file. Please add the relevant BZ in the correct format to both the changelog and the commit message. Please add the Signed-off-by tag to the commit message. > Here's a patch to update the xfs_healer packaging and fix a warning about a > .build-id being included twice
Yes, Thanks for the feedback. In my haste, I didn't clean up the various ways of packaging I was testing. I didn't know my FAS account had access to src. I will work on this today. kernel 7.0.9 (XFS options enabled) landed in Fedora 43/44 updates yesterday, hence why I am trying to get xfsprogs 7+ into Fedora 43 onwards.
https://src.fedoraproject.org/rpms/xfsprogs/pull-request/24 ...and a COPR build (I removed the prior 7.0.1-1 build) of the srpm from the p/r: https://copr.fedorainfracloud.org/coprs/allenhewes/xfsprogs/build/10489227/
https://bodhi.fedoraproject.org/updates/FEDORA-2026-fbc21358cb
(In reply to rallenh from comment #5) > Here's COPR build of xfsprogs 7.0.1 > https://copr.fedorainfracloud.org/coprs/allenhewes/xfsprogs/build/10488570/ > > Could xfsprogs 7.0.1 make it to Fedora 43+, please? I am looking into it :-) I can see that in Fedora 43 the xfsprogs version is 6.15.0-3.fc43 and in Fedora 44 it is 6.18.0-2.fc44. Are you aware of whether updating to 7.0.1 would satisfy the *Updates policy* conditions of not introducing incompatible changes or impacting other packages in a stable Fedora release?
I am not aware of the updates policy, only from an end-user perspective for the major components: e.g. GNOME/GCC/KDE/libc/OpenSSL/etc. Maybe it's as simple as me sending you a p/r for the branch? The lookaside cache has the files now...
I know how to implement it technically, but I'm questioning if this update qualifies. At a minimum, it must not introduce breaking changes or affect other packages. I don't want to rush this, so I'll check the changelog between the versions on Monday to make sure I feel confident. I really don't want to break xfsprogs across stable Fedora releases
Hi Pavel, I took your concern and wrote a shell script that reports on forward and backward package dependencies. I used this script on VMs of Fedora 43 and 44. I used the Fedora repos and my (cleaned up) COPR repo for xfsprogs (rebuild of your 7.0.1 rawhide build). And it looks to me, from the reports, that an upgrade of xfsprogs to 7.0.1 in both Fedora 43 and Fedora 44 will be low real-world risk. Of course, I'm a nobody and I'm not assuming the risk, but check out the reports: libhandle.so.1 SONAME wasn't bumped (an xfsdump dep) and the other dependencies are commands or NOT NEVRAs. Xfsprogs looks a leaf package.
Created attachment 2142853 [details] package script dep check with Fedora 43 and xfsprogs 6.15.0
Created attachment 2142854 [details] package script dep check with Fedora 43 and xfsprogs-devel 6.15.0
Created attachment 2142855 [details] package script dep check with Fedora 43 and xfsprogs 7.0.1
Created attachment 2142856 [details] package script dep check with Fedora 43 and xfsprogs-devel 7.0.1
Created attachment 2142857 [details] package script dep check with Fedora 44 and xfsprogs 6.18.0
Created attachment 2142858 [details] package script dep check with Fedora 44 and xfsprogs-devel 6.18.0
Created attachment 2142859 [details] package script dep check with Fedora 44 and xfsprogs 7.0.1
Created attachment 2142866 [details] package script dep check with Fedora 44 and xfsprogs-devel 7.0.1
(In reply to rallenh from comment #13) > Hi Pavel, > > I took your concern and wrote a shell script that reports on forward and > backward package dependencies. I used this script on VMs of Fedora 43 and > 44. I used the Fedora repos and my (cleaned up) COPR repo for xfsprogs > (rebuild of your 7.0.1 rawhide build). And it looks to me, from the reports, > that an upgrade of xfsprogs to 7.0.1 in both Fedora 43 and Fedora 44 will be > low real-world risk. Of course, I'm a nobody and I'm not assuming the risk, > but check out the reports: libhandle.so.1 SONAME wasn't bumped (an xfsdump > dep) and the other dependencies are commands or NOT NEVRAs. Xfsprogs looks a > leaf package. Thank you very much for spending time on this. Builds are WIP, fingers crossed it goes well.
@rallenh Well, it did not go too well, at least for fedora 43. https://bodhi.fedoraproject.org/updates/FEDORA-2026-033dd35ca7
Ok. Thanks for pointing this out to me. Grrr. This is from the XFS metadata defaults changing in 2024. Oye. I would probably feel that at least for Fedora 43, it's not worth fiddling with grub2-install. That patch should have landed in Fedora 43 grub2 (it's old enough, circa 02/2025, kernel 6.12/6.13 time frame) but it didn't: grub2 2.12-52+. Oye. Xfsprogs 7.0.1 should be OK for Fedora 44 at least: it has had grub2 2.12.52+ since Jan of 2026. I can use my xfsprog 7.0.1 COPR until I upgrade to Fedora 44. I have to re-format and rsync anyways. I don't have to fiddle with grub2-install for me to be able to use XFS online scrubbing. Man Pavel, so much for "low real-world risk". I didn't test the Fedora Server fresh install path, my apologies. I'll crawl back under my rock now...
I grabbed a Fedora 44 Server netinst ISO and installed it a VirtualBox VM. After reboot, it was already up-to-date. I then rpm -Uvh https://kojipkgs.fedoraproject.org//packages/xfsprogs/7.0.1/2.fc44/x86_64/xfsprogs-7.0.1-2.fc44.x86_64.rpm. OK. I then wget https://kojipkgs.fedoraproject.org//packages/xfsprogs/7.0.1/2.fc44/x86_64/xfsprogs-7.0.1-2.fc44.x86_64.rpm. I then dnf downloaded: grub2-common-2.12-58.fc44.noarch.rpm grub2-tools-2.12-58.fc44.x86_64.rpm grub2-tools-minimal-2.12-58.fc44.x86_64.rpm grub2-efi-x64-2.12-58.fc44.x86_64.rpm grub2-tools-extra-2.12-58.fc44.x86_64.rpm I then did a dnf reinstall *.rpm of them. OK. I checked the /var/log/dnf.log file and found: 2026-06-03T22:03:31+0000 [1068] DEBUG Implicitly added element grub2-common-1:2.12-58.fc44.noarch type remove package (caused by grub2-common-1:2.12-58.fc44.noarch) 2026-06-03T22:03:31+0000 [1068] INFO RPM callback open file "grub2-common-2.12-58.fc44.noarch.rpm" 2026-06-03T22:03:31+0000 [1068] INFO RPM callback open file "grub2-common-2.12-58.fc44.noarch.rpm" 2026-06-03T22:03:31+0000 [1068] INFO RPM callback open file "grub2-common-2.12-58.fc44.noarch.rpm" 2026-06-03T22:03:31+0000 [1068] INFO RPM callback open file "grub2-common-2.12-58.fc44.noarch.rpm" 2026-06-03T22:03:31+0000 [1068] INFO RPM callback install start "grub2-common-1:2.12-58.fc44.noarch" total 6470936 2026-06-03T22:03:31+0000 [1068] INFO RPM callback install stop "grub2-common-1:2.12-58.fc44.noarch" amount 6470936 total 6470936 2026-06-03T22:03:31+0000 [1068] INFO RPM callback uninstall start "grub2-common-1:2.12-58.fc44.noarch" total 57 2026-06-03T22:03:31+0000 [1068] INFO RPM callback uninstall stop "grub2-common-1:2.12-58.fc44.noarch" amount 57 total 57 2026-06-03T22:03:31+0000 [1068] INFO RPM callback start %posttrans scriptlet "grub2-common-1:2.12-58.fc44.noarch" 2026-06-03T22:03:31+0000 [1068] INFO RPM callback stop %posttrans scriptlet "grub2-common-1:2.12-58.fc44.noarch" return code 0 The %posttrans scriptlet was what failed on the Fedora 43 bodhi check by Adam. I then checked grub2-probe (source of error from Adam's bodhi check for the Fedora 43 update): allen@localhost:~$ sudo /usr/bin/grub2-probe --device /dev/mapper/fedora-root xfs allen@localhost:~$ rpm -q xfsprogs xfsprogs-7.0.1-2.fc44.x86_64 I wanted to give some +1 Karma at https://bodhi.fedoraproject.org/updates/FEDORA-2026-ce44c82f57, but I can't figure out how Adam did his testing. Maybe I'm not testing this xfsprogs update correctly?
(In reply to rallenh from comment #25) > I grabbed a Fedora 44 Server netinst ISO and installed it a VirtualBox VM. > After reboot, it was already up-to-date. > > I then rpm -Uvh > https://kojipkgs.fedoraproject.org//packages/xfsprogs/7.0.1/2.fc44/x86_64/ > xfsprogs-7.0.1-2.fc44.x86_64.rpm. OK. > > I then wget > https://kojipkgs.fedoraproject.org//packages/xfsprogs/7.0.1/2.fc44/x86_64/ > xfsprogs-7.0.1-2.fc44.x86_64.rpm. > > I then dnf downloaded: > grub2-common-2.12-58.fc44.noarch.rpm grub2-tools-2.12-58.fc44.x86_64.rpm > grub2-tools-minimal-2.12-58.fc44.x86_64.rpm > grub2-efi-x64-2.12-58.fc44.x86_64.rpm > grub2-tools-extra-2.12-58.fc44.x86_64.rpm > > I then did a dnf reinstall *.rpm of them. OK. > > I checked the /var/log/dnf.log file and found: > 2026-06-03T22:03:31+0000 [1068] DEBUG Implicitly added element > grub2-common-1:2.12-58.fc44.noarch type remove package (caused by > grub2-common-1:2.12-58.fc44.noarch) > 2026-06-03T22:03:31+0000 [1068] INFO RPM callback open file > "grub2-common-2.12-58.fc44.noarch.rpm" > 2026-06-03T22:03:31+0000 [1068] INFO RPM callback open file > "grub2-common-2.12-58.fc44.noarch.rpm" > 2026-06-03T22:03:31+0000 [1068] INFO RPM callback open file > "grub2-common-2.12-58.fc44.noarch.rpm" > 2026-06-03T22:03:31+0000 [1068] INFO RPM callback open file > "grub2-common-2.12-58.fc44.noarch.rpm" > 2026-06-03T22:03:31+0000 [1068] INFO RPM callback install start > "grub2-common-1:2.12-58.fc44.noarch" total 6470936 > 2026-06-03T22:03:31+0000 [1068] INFO RPM callback install stop > "grub2-common-1:2.12-58.fc44.noarch" amount 6470936 total 6470936 > 2026-06-03T22:03:31+0000 [1068] INFO RPM callback uninstall start > "grub2-common-1:2.12-58.fc44.noarch" total 57 > 2026-06-03T22:03:31+0000 [1068] INFO RPM callback uninstall stop > "grub2-common-1:2.12-58.fc44.noarch" amount 57 total 57 > 2026-06-03T22:03:31+0000 [1068] INFO RPM callback start %posttrans scriptlet > "grub2-common-1:2.12-58.fc44.noarch" > 2026-06-03T22:03:31+0000 [1068] INFO RPM callback stop %posttrans scriptlet > "grub2-common-1:2.12-58.fc44.noarch" return code 0 > > The %posttrans scriptlet was what failed on the Fedora 43 bodhi check by > Adam. > > I then checked grub2-probe (source of error from Adam's bodhi check for the > Fedora 43 update): > allen@localhost:~$ sudo /usr/bin/grub2-probe --device > /dev/mapper/fedora-root > xfs > allen@localhost:~$ rpm -q xfsprogs > xfsprogs-7.0.1-2.fc44.x86_64 > > I wanted to give some +1 Karma at > https://bodhi.fedoraproject.org/updates/FEDORA-2026-ce44c82f57, but I can't > figure out how Adam did his testing. Maybe I'm not testing this xfsprogs > update correctly? I'm not sure I understand the concern. Are you expecting to reproduce the failure Adam reported on Fedora 43 while testing on Fedora 44? If so, that may not happen, since the grub2 issue appears to have been fixed in grub2-2.12-52.fc44 (see https://bugzilla.redhat.com/show_bug.cgi?id=2429501).
Sorry for being a little dense, but now I'm really curious... I was trying to perform/understand the same tests/process Adam used with Fedora 43 and the xfsprogs update with Fedora 44. To see if there is still an issue or not (my hypothesis) with Fedora 44. Yes, I saw the Fedora changes and upstream changes. But now I am confused even more. Because in Fedora 43, mkfs.xfs would be from xfsprogs 6.15.0 at the time of install from the ISO. Therefore, it would have used the XFS metadata defaults of 6.15.0: rmapbt=1 , exchange=0, and parent=0. And those do work with 2.12-43.fc43.x86_64: How did Adam get formatted XFS paritions that used newer default metadata such that grub2-install breaks in Fedora 43? Using Fedora-Server-netinst-x86_64-43-1.6.iso, I get XFS metadata that works with grub2 and xfsprogs 7.0.1. Did he create a new ISO to test with so that then, mkfs.xfs would be from the xfsprogs 7.0.1 update and not 6.15.0: they should have different defaults for the metadata. He didn't show the XFS metadata of the paritions. I'm really trying to understand what/how Adam showed as broken... I understand the back porting point he made, but that would only come into picture on XFS paritions that had been formatted with a version of mkfs.xfs with newer metadata defaults, right? Maybe this can be summed up into a simple question: are new ISOs/install media cut for Fedoras after the initial releases? I get the exact same error if I format using mkfs.xfs from 7.0.1: $ sudo mkfs.xfs -f /dev/sdb3 meta-data=/dev/sdb3 isize=512 agcount=4, agsize=233558 blks = sectsz=512 attr=2, projid32bit=1 = crc=1 finobt=1, sparse=1, rmapbt=1 = reflink=1 bigtime=1 inobtcount=1 nrext64=1 = exchange=1 metadir=0 data = bsize=4096 blocks=934230, imaxpct=25 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0, ftype=1, parent=1 log =internal log bsize=4096 blocks=16384, version=2 = sectsz=512 sunit=0 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0 = rgcount=0 rgsize=0 extents = zoned=0 start=0 reserved=0 $ sudo /usr/bin/grub2-probe --device /dev/sdb3 /usr/bin/grub2-probe: error: ../grub-core/kern/fs.c:123:unknown filesystem. $ cat /etc/os-release | grep ^VERSION= VERSION="43 (Workstation Edition)"
(In reply to rallenh from comment #27) > Sorry for being a little dense, but now I'm really curious... > > I was trying to perform/understand the same tests/process Adam used with > Fedora 43 and the xfsprogs update with Fedora 44. To see if there is still > an issue or not (my hypothesis) with Fedora 44. > > Yes, I saw the Fedora changes and upstream changes. > > But now I am confused even more. Because in Fedora 43, mkfs.xfs would be > from xfsprogs 6.15.0 at the time of install from the ISO. Therefore, it > would have used the XFS metadata defaults of 6.15.0: rmapbt=1 > , exchange=0, and parent=0. And those do work with 2.12-43.fc43.x86_64: > > How did Adam get formatted XFS paritions that used newer default metadata > such that grub2-install breaks in Fedora 43? Using > Fedora-Server-netinst-x86_64-43-1.6.iso, I get XFS metadata that works with > grub2 and xfsprogs 7.0.1. Did he create a new ISO to test with so that then, > mkfs.xfs would be from the xfsprogs 7.0.1 update and not 6.15.0: they should > have different defaults for the metadata. He didn't show the XFS metadata of > the paritions. > > I'm really trying to understand what/how Adam showed as broken... I > understand the back porting point he made, but that would only come into > picture on XFS paritions that had been formatted with a version of mkfs.xfs > with newer metadata defaults, right? > > Maybe this can be summed up into a simple question: are new ISOs/install > media cut for Fedoras after the initial releases? > > I get the exact same error if I format using mkfs.xfs from 7.0.1: > $ sudo mkfs.xfs -f /dev/sdb3 > meta-data=/dev/sdb3 isize=512 agcount=4, agsize=233558 blks > = sectsz=512 attr=2, projid32bit=1 > = crc=1 finobt=1, sparse=1, rmapbt=1 > = reflink=1 bigtime=1 inobtcount=1 > nrext64=1 > = exchange=1 metadir=0 > data = bsize=4096 blocks=934230, imaxpct=25 > = sunit=0 swidth=0 blks > naming =version 2 bsize=4096 ascii-ci=0, ftype=1, parent=1 > log =internal log bsize=4096 blocks=16384, version=2 > = sectsz=512 sunit=0 blks, lazy-count=1 > realtime =none extsz=4096 blocks=0, rtextents=0 > = rgcount=0 rgsize=0 extents > = zoned=0 start=0 reserved=0 > $ sudo /usr/bin/grub2-probe --device /dev/sdb3 > /usr/bin/grub2-probe: error: ../grub-core/kern/fs.c:123:unknown filesystem. > $ cat /etc/os-release | grep ^VERSION= > VERSION="43 (Workstation Edition)" I raelly don't know, don't hesitate to reach him. He is a nice guy :-)
Hi Pavel, Meh, not much for getting into any politics or policies over this. Your help with Fedora 44 is a win in my book. I will maintain my own Fedora 43 overrides in COPR (https://copr.fedorainfracloud.org/coprs/allenhewes/f43-override/builds/) until I upgrade to Fedora 44. I have confirmed the two XFS patches to grub2 that aren't in Fedora 43's grub2 would solve Adam's test issue: > cat /etc/os-release | grep ^VERSION= VERSION="43 (Workstation Edition)" > rpm -q --queryformat "%{NAME}-%{VERSION}.%{RELEASE}\n" grub2-common grub2-common-2.12.43.2.fc43 > lsblk -o NAME,SIZE,MODEL,TRAN | grep -E 'sd|NAME' NAME SIZE MODEL TRAN sdb 1.9G U3 Cruzer Micro usb └─sdb1 1.9G > mkfs.xfs -V mkfs.xfs version 7.0.1 > sudo wipefs -a /dev/sdb /dev/sdb: 2 bytes were erased at offset 0x000001fe (dos): 55 aa /dev/sdb: calling ioctl to re-read partition table: Success > sudo parted -s /dev/sdb mklabel gpt mkpart primary xfs 1MiB 100% > sudo mkfs.xfs /dev/sdb1 meta-data=/dev/sdb1 isize=512 agcount=4, agsize=121984 blks = sectsz=512 attr=2, projid32bit=1 = crc=1 finobt=1, sparse=1, rmapbt=1 = reflink=1 bigtime=1 inobtcount=1 nrext64=1 = exchange=1 metadir=0 data = bsize=4096 blocks=487936, imaxpct=25 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0, ftype=1, parent=1 log =internal log bsize=4096 blocks=16384, version=2 = sectsz=512 sunit=0 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0 = rgcount=0 rgsize=0 extents = zoned=0 start=0 reserved=0 # here's the point at which Adam's test case failed in Fedora 43 without the XFS patches to grub2 > sudo /usr/bin/grub2-probe --device /dev/sdb1 xfs > sudo mount /dev/sdb1 /mnt # and the whole reason for this long winded ticket: online XFS scrubbing! > sudo xfs_scrub -v /mnt Phase 1: Find filesystem geometry. /mnt: using 2 threads to scrub. Phase 2: Check internal metadata. Phase 3: Scan all inodes. Phase 4: Repair filesystem. Info: AG 1 superblock: Attempting optimization. Info: AG 2 superblock: Attempting optimization. Optimized: AG 1 superblock: Optimization successful. Info: AG 3 superblock: Attempting optimization. Optimized: AG 2 superblock: Optimization successful. Optimized: AG 3 superblock: Optimization successful. Phase 5: Check directory tree. Phase 7: Check summary counters. 195.7MiB data used; 3 inodes used. 64.2MiB data found; 3 inodes found. 3 inodes counted; 3 inodes checked. Phase 8: Trim filesystem storage. /mnt: optimizations made: 3. Bingo! Thanks again for your help re: Fedora 44. Take it easy! :-)