[Bug 1689286] [NEW] grub-probe failing after UUID change on XFS volume
Dallas
1689286 at bugs.launchpad.net
Mon May 8 11:30:37 UTC 2017
Public bug reported:
=== 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
** Affects: grub2 (Ubuntu)
Importance: Undecided
Status: New
** Tags: grub xfs
--
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to grub2 in Ubuntu.
https://bugs.launchpad.net/bugs/1689286
Title:
grub-probe failing after UUID change on XFS volume
Status in grub2 package in Ubuntu:
New
Bug description:
=== 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
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1689286/+subscriptions
More information about the foundations-bugs
mailing list