Bug 101421 - XFS root filesystem (with non-separate /boot) on USB flash (or fixed disk) drive not GRUB bootable
Summary: XFS root filesystem (with non-separate /boot) on USB flash (or fixed disk) dr...
Status: RESOLVED INVALID
Alias: None
Product: File System
Classification: Unclassified
Component: XFS (show other bugs)
Hardware: x86-64 Linux
: P1 normal
Assignee: XFS Guru
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-07-13 00:40 UTC by jpsinthemix
Modified: 2015-07-14 09:23 UTC (History)
0 users

See Also:
Kernel Version: 4.1.2
Tree: Mainline
Regression: No


Attachments

Description jpsinthemix 2015-07-13 00:40:59 UTC
Hi,
I am encountering GRUB boot problems on USB flash drive installations with an XFS root filesystem and /boot not on a separate partition.

system:
        x86_64-pc-linux-gnu

environment:
        linux-headers-4.1.2_x86_64_smp, gcc-5.1.0, glibc-2.21, binutils-2.25,
        xfsprogs-3.2.3, grub-2.02.beta2, systemd-221


I have been installing recovery/installer console linux OS's on 16GB USB flash drives for some time on i686-pc-linux-gnu systems. I generally create several MBR/MSDOS or GPT partitions using fdisk, say,

        /dev/sdd1 8300 xfs /
        /dev/sdd2 8300 xfs /home

or, using gdisk, say,

        /dev/sdd1 EF02 
        /dev/sdd2 8300 xfs /
        /dev/sdd3 8300 xfs /home

With grub, I boot with

        root=PARTUUID=XXXXXXXX-0X,                          for MBR/MSDOS partitions
        root=PARTUUID=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX, for GPT partitions

In the problematic cases, /boot is under /, not a separate partition.

When creating the bootable USB flash drives from the 32bit i686-pc-linux-gnu systems, I have had no problems with linux.3.19.3, gcc-4.9.2, systemd-219 (other packages, as noted above).

Hovever, when creating the bootable USB flash drives from the 64bit x86_64-pc-linux-gnu systems, the flash drives are unbootable, giving a large number of the following errors:

        "attempt to read or write outside of partition"
        "not a correct XFS inode"
        "file `/boot/grub/i386-pc/normal.mod' not found."

and grub drops to rescue mode. From the rescue prompt, all partitions are found, directories under /home are seen, but nothing under root is accessible.

Note that none of the systems are [U]EFI enabled.

Note also, that if I use an ext2 root rather than XFS (/boot not separate), then all is well.

Furthermore, on the x86_64-pc-linux-gnu system, I have no boot problems (same software environment); the only differences between the USB flash installation and the build system installation are:

        * the build system use fixed sata drives
        * the (XFS) filesystems on the build system were created under linux-headers.3.18.3_x86_64_smp
          using xfsprogs-3.2.2


This issues appears to be very similar an old (2013; linux-3.5.0) bug report

        https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1103187

with resolution:

        http://oss.sgi.com/archives/xfs/2013-01/msg00117.html

The fs/xfs code has changed appreciably since this bug report, so it will take me quite some time to relate the two linux versions (3.5.0 -> 4.1.2). Could this be a regression involving the journal commits specifically related to XFS filesystem creation on USB flash drives?

thanks much,
John
Comment 1 jpsinthemix 2015-07-13 09:20:45 UTC
I have just tried an in installation onto a Thinkpad T60 from a working usb installer stick (with an ext2 root) and I see the same problem, the new XFS root on fixed disk is non-bootable with the same errors as noted above.

So, the problem is not specific to installation onto a USB flash disk.

Also, if, after installation onto the T60, I re-mount the root partition, then un-mount, then sync, then the new system still fails to boot, but this time only with a few error messages, rather than several screen-fulls of errors-- the errors are the same though.
Comment 2 jpsinthemix 2015-07-14 09:22:26 UTC
Oops, never mind.. this is a grub issue (mkfs.xfs now has crc=1 by default which confuses grub)
Closing..

Note You need to log in before you can comment on or make changes to this bug.