Bug 1765217

This bug does not concern rhel-system-roles at all, the problem occurs when using a module distributed with Ansible. From the description it sounds like the underlying problem is that xfs_growfs lost an ability it once had, reassigning to xfsprogs.

xfs_growfs in RHEL7 and in RHEL8 is clearly documented to accept a mount point, not a device:

> NAME
>       xfs_growfs - expand an XFS filesystem
> 
> SYNOPSIS
>       xfs_growfs [ -dilnrx ] [ -D size ] [ -e rtextsize ] [ -L size ] [ -m maxpct ] [ -t mtab ] [ -R size ] mount-point

In rhel7 it does seem to work with a device name, if and only if that device name is mounted.

If ansible is passing device names to xfs_growfs, that's incorrect usage which only worked by accident.  xfs can only be grown while mounted.

I'm not sure why this is considered an xfs_growfs bug, because it's never been documented to take a device node?

It's easy enough to make it accept a (mounted) block device again:

diff --git a/growfs/xfs_growfs.c b/growfs/xfs_growfs.c
index 20089d2b..4224c5a0 100644
--- a/growfs/xfs_growfs.c
+++ b/growfs/xfs_growfs.c
@@ -140,6 +140,9 @@ main(int argc, char **argv)
        }
 
        fs = fs_table_lookup_mount(rpath);
+       if (!fs)
+               fs = fs_table_lookup_blkdev(rpath);
+
        if (!fs) {
                fprintf(stderr, _("%s: %s is not a mounted XFS filesystem\n"),
                        progname, argv[optind]);

but this (using a device name) hasn't worked since may 2017, and it's never been documented to work, so I'm a little concerned about ansible's behavior here as well.

I've sent a patch upstream to formally document and accept a mounted device node as a parameter.

commit 7e8275f8939988f18f9a4a596381ca215fde2270
Author: Eric Sandeen <sandeen>
Date:   Mon Nov 4 15:35:49 2019 -0500

    xfs_growfs: allow mounted device node as argument
    
    Up until:
    
     b97815a0 xfs_growfs: ensure target path is an active xfs mountpoint
    
    xfs_growfs actually accepted a mounted block device name as the
    primary argument, because it could be found in the mount table.
    
    It turns out that Ansible was making use of this undocumented behavior,
    and it's trivial to allow it, so put it back in place and document
    it this time.
    
    Signed-off-by: Eric Sandeen <sandeen>
    Reviewed-by: Christoph Hellwig <hch>
    Signed-off-by: Eric Sandeen <sandeen>

Reproduced on xfsprogs-5.0.0-1.el8:
# rpm -q xfsprogs
xfsprogs-5.0.0-1.el8.x86_64
# ./check xfs/999
FSTYP         -- xfs (non-debug)
PLATFORM      -- Linux/x86_64 hp-dl380pg8-01 4.18.0-167.el8.x86_64+debug #1 SMP Sun Dec 15 01:09:13 UTC 2019
MKFS_OPTIONS  -- -f -bsize=4096 /dev/mapper/rhel_hp--dl380pg8--01-xfscratch
MOUNT_OPTIONS -- -o context=system_u:object_r:root_t:s0 /dev/mapper/rhel_hp--dl380pg8--01-xfscratch /mnt/scratch

xfs/999 - output mismatch (see /home/xfstests-dev/results//xfs/999.out.bad)
    --- tests/xfs/999.out       2019-12-23 00:05:42.766529796 -0500
    +++ /home/xfstests-dev/results//xfs/999.out.bad     2019-12-23 00:07:00.787473941 -0500
    @@ -9,8 +9,12 @@
     xfs_growfs: LOOPSYMLINK is not a mounted XFS filesystem
     === mount ===
     === xfs_growfs - check device node ===
    +xfs_growfs: /dev/loop1 is not a mounted XFS filesystem
     === xfs_growfs - check device symlink ===
    +xfs_growfs: /mnt/test/loop_symlink.36586 is not a mounted XFS filesystem
     === unmount ===
    ...
    (Run 'diff -u /home/xfstests-dev/tests/xfs/999.out /home/xfstests-dev/results//xfs/999.out.bad'  to see the entire diff)
Ran: xfs/999
Failures: xfs/999
Failed 1 of 1 tests

Test passed on xfsprogs 5.0.0-2.el8
# rpm -q xfsprogs
xfsprogs-5.0.0-2.el8.x86_64
# ./check xfs/999
FSTYP         -- xfs (non-debug)
PLATFORM      -- Linux/x86_64 hp-dl380pg8-01 4.18.0-167.el8.x86_64+debug #1 SMP Sun Dec 15 01:09:13 UTC 2019
MKFS_OPTIONS  -- -f -bsize=4096 /dev/mapper/rhel_hp--dl380pg8--01-xfscratch
MOUNT_OPTIONS -- -o context=system_u:object_r:root_t:s0 /dev/mapper/rhel_hp--dl380pg8--01-xfscratch /mnt/scratch

xfs/999  6s
Ran: xfs/999
Passed all 1 tests

# ./check xfs/999
FSTYP         -- xfs (non-debug)
PLATFORM      -- Linux/x86_64 hp-dl380pg8-01 4.18.0-167.el8.x86_64+debug #1 SMP Sun Dec 15 01:09:13 UTC 2019
MKFS_OPTIONS  -- -f -m reflink=1,rmapbt=0 -b size=1024 /dev/mapper/rhel_hp--dl380pg8--01-xfscratch
MOUNT_OPTIONS -- -o context=system_u:object_r:root_t:s0 /dev/mapper/rhel_hp--dl380pg8--01-xfscratch /mnt/scratch

xfs/999 6s ...  6s
Ran: xfs/999
Passed all 1 tests

I found a fix which is working for ansible. After this fix you need to restart the katello-services on RedHat Satellite.
The fix will find the mountpoint and changes the xfs_growfs command.

# diff fix.filesystem.py  /usr/lib/python2.7/site-packages/ansible/modules/system/filesystem.py

103a104,116
>     def get_mountpoint(self):
>         """Return (first) mountpoint of device, if not mounted return None"""
>         cmd_findmnt = self.module.get_bin_path("findmnt", required=True)
>         # find mountpoint
>         rc, mountpoint, _ = self.module.run_command([cmd_findmnt, "--mtab", "--noheadings", "--output",
>                                                     "TARGET", "--source", self.path], check_rc=False)
>         if rc != 0:
>             mountpoint = None
>         else:
>             mountpoint = mountpoint.split('\n')[0]
>
>         return mountpoint
>
195c208,209
<         _, size, _ = self.module.run_command([cmd, '-n', str(dev)], check_rc=True, environ_update=self.LANG_ENV)
---
>         mountpoint = dev.get_mountpoint()
>         _, size, _ = self.module.run_command([cmd, '-n', str(mountpoint)], check_rc=True, environ_update=self.LANG_ENV)
205a220,226
>
>     def grow_cmd(self, dev):
>         # xfs filesystem needs to be mounted
>         mountpoint = dev.get_mountpoint()
>         cmd = self.module.get_bin_path(self.GROW, required=True)
>
>         return [cmd, str(mountpoint)]

I did not write the fix. I just found it and want to share it.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2020:1909