grub-probe failing after UUID change on XFS volume

=== System Setup

Description: Ubuntu 17.04
Release: 17.04

df Output:
Filesystem 1K-blocks Used Available Use% Mounted on
udev 4002320 0 4002320 0% /dev
tmpfs 805604 9908 795696 2% /run
/dev/sda6 48803552 9565340 39238212 20% /
tmpfs 4028016 131784 3896232 4% /dev/shm
tmpfs 5120 4 5116 1% /run/lock
tmpfs 4028016 0 4028016 0% /sys/fs/cgroup
/dev/sda7 90970728 2877580 88093148 4% /home
tmpfs 805600 24 805576 1% /run/user/1000

=== Action Producing Error

After clean install as above, boot into LiveCD, open terminal and issue following commands:

xfm_admin -U generate /dev/sda6
# outputs new UUID for /dev/sda6
xfm_admin -U generate /dev/sda7
# outputs new UUID for /dev/sda7

mount /dev/sda6 /mnt
mount --bind /dev /mnt/dev
mount --bind /dev/pts /mnt/dev/pts
mount --bind /proc /mnt/proc
mount --bind /sys /mnt/sys
chroot /mnt
update-grub
Error: unkown filesystem

=== Rationale & Further Details

I cloned the current setup into a live backup drive, but the system would mount the backup's /dev/sdb6 on / instead of using /dev/sda6, which is apparently due to UUID replication. To get around this, I attempted to change the UUIDs of the source volumes as above, but any command grub-related would fail with this same error, and Grub itself failed with this exact error when attempting to boot.

Troubleshooting the issue, I tried the following:
1. Booted back into LiveCD, mounted the directory and updated fstab with the new UUIDs (just in case this was the issue).
2. Attempted to use Repair-Boot, which failed withe the same error (of course, because it is using the same tools.)
3. Dumped and inspected the MBR on /dev/sda. There were no issues.
4. Booted the installation with Super Grub2 Disk (For some reason, it was able to boot it in EFI mode, though the boot loader was installed in BIOS mode.) When running SG2D in BIOS mode, it would not detect the installation. (I assume due to the same error.)
5. Once booted into the system, I attempted to do the grub dance, but still same errors.
6. Noticed grub-install had --verbose option, enabled and searched for XFS.
7. Narrowed the error down to grub-probe (which is used by pretty much everything.)
8. Even running grub-install --skip-fs-probe would fail, so I assume there is some same check (see below) internally.

When running grub-probe with --verbose, when it got to the target partition and ran the xfs check, the followed message was outputted:

grub/kern/fs.c: Detecting xfs...
grub/fs/xfs.c: Validating superblock
grub/fs/xfs.c: XFS v5 superblock detected
grub/kern/fs.c: detection failed.

=== Summary

The xfs filesystem with CRC enabled, when changing the UUID, will set the flag XFS_SB_FEAT_INCOMPAT_SUPPORTED, grub checks for this and fails, but it is not clear why grub cannot handle this, as the FS has no issues and requires no extra management or logic of grub to function properly.

Why I consider this a bug? Because anyone who runs into the same scenario that I did, which is very logical, would be essentially killing their install. Grub should function without issue with the XFS_SB_FEAT_INCOMPAT_SUPPORTED flag set, so b0rking a boot for this purpose is really problematic, IMO.

For posterity (and the sanity of anyone else running into this issue), I was able to recover the system by the following:

Boot into LiveCD and open Term:

---
# restore the UUIDs and create new swap (to avoid it having same UUID as backup)
sudo su
xfs_admin -U restore /dev/sda6
xfs_admin -U restore /dev/sda7
swapoff /dev/sda5
mkswap /dev/sda5

# change the backup UUIDs to avoid the mounting backup on / issue.
xfs_admin -U generate /dev/sdb6
xfs_admin -U generate /dev/sdb7
mount /dev/sda6 /mnt
mount --bind /dev /mnt/dev &&
mount --bind /dev/pts /mnt/dev/pts &&
mount --bind /proc /mnt/proc &&
mount --bind /sys /mnt/sys
chroot /mnt
update-grub
grub-install /dev/sda
grub-install --recheck /dev/sda

#update fstab with the old UUIDs, given above.
vim /etc/fstab

#clean up for good measure
exit
umount /mnt/sys
umount /mnt/proc
umount /mnt/dev/pts
umount /mnt/dev