Bug 2343538
| Summary: | xfsdump fails to dump root filesystem (via block device) on hosts with bind-chroot | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora EPEL | Reporter: | Dan Astoorian <djast> | ||||
| Component: | amanda | Assignee: | Jason Tibbitts <j> | ||||
| Status: | NEW --- | QA Contact: | |||||
| Severity: | unspecified | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | epel9 | CC: | jridky, j, orion, pcahyna, phracek, sidsbrmnn | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | --- | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | Type: | Bug | |||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
Created attachment 2075030 [details]
Patch lifted from RHEL issue
I've had this problem as well; I worked with Eric Sandeen years ago and he had agreed that the regression in xfsdump behavior was a bug. It did get fixed for a while but then broke again in the update from xfsdump 3.1.9 to 3.1.12 in the F36 days. Having bind-chroot installed isn't the only way to trigger this; bind mounts from automounting home directories also causes issues.
It's all a big mess; it certainly worked well for a couple of decades and I'd argue that it really is a regression in xfsdump. But after this time it doesn't appear to be changing. Personally I just switched to tar, but since upstream is pretty much dead, everyone should probably switch away from amanda.
Anyway, I lifted this tiny patch from the RHEL issue; I wish I had known that it existed but information doesn't always flow out to Fedora very well. I can reproduce this issue so if I can ever get amanda to compile properly with gcc 15 then I'll see if it helps.
|
Description of problem: Amanda cannot use xfsdump to back up XFS filesystems that has bind-mounts (e.g., systems where named-chroot.service is active). Version-Release number of selected component (if applicable): amanda-3.5.3-1.el9.x86_64 amanda-3.5.1-13.el8.x86_64 on RHEL8 (if xfsdump >= 3.1.8-4.el8) How reproducible: Always Steps to Reproduce: 1. Create a bind mount to an XFS filesystem (e.g,. "mount -o defaults,bind /var/log /mnt" where /var/log is an XFS filesystem); or "systemctl start named-chroot.service" (if /var/named is on an XFS filesystem) 2. Add /var/log to Amanda as a DLE with a dumptype that uses xfsdump 3. Attempt to back up the filesystem via amdump. Actual results: The dump fails with a message of the form: hostname /var/log lev 0 FAILED [no size line match in /usr/lib64/amanda/rundump (xfsdump) output] Expected results: The filesystem should be backed up successfully. Additional info: Amanda always presents a block device to rundump, but xfsdump (unlike other dump programs) expects its argument to be a filesystem path, not a block device. If the filesystem is mounted in exactly one place, xfsdump will map the block device back to the mount point. Older versions of xfsdump would also map the block device to a mount point (it's not clear whether it necessarily selects the right one), but between xfsdump-3.1.8-2.el8.x86_64 and xfsdump-3.1.8-4.el8.x86_64 on RHEL8 this behaviour was changed to make xfsdump exit with a message of the form "ERROR: /mnt is not the root of the filesystem (bind mount?) - use primary mountpoint". See https://issues.redhat.com/browse/RHEL-7877 for further details, but since the crux of the issue is that xfsdump expects a pathname rather than a block device, this should be regarded as a deficiency in Amanda, not xfsdump.