Bug#1051543: grub2: Fails to load normal.mod from a XFS v5 parition.

[Jamie Heilman]

Funny, I had this problem (unbootable system, couldn't find net.mod
even though it was there ls on the grub_rescue prompt didn't see it)
with a XFS V4 partition, and rebuilding that as V5 and copying
everything over seemed to have fixed it... but maybe I just got lucky
on the first try.  Interestingly, once I've got grub actually able to
load normal.mod it doesn't seem to have problems finding any files on
the V4 partition.  For the sake of comparison here's are the full
details of the two (lvm) volumes in question:

The partition that initially broke w/2.12~rc1-9:

# xfs_db -r /dev/mapper/S-root
xfs_db> version
versionnum [0xb4b4+0xa] = V4,NLINK,DIRV2,ATTR,ALIGN,LOGV2,EXTFLG,MOREBITS,ATTR2,LAZYSBCOUNT

# xfs_info /dev/mapper/S-root
meta-data=/dev/mapper/S-root     isize=256    agcount=4, agsize=524288 blks
         =                       sectsz=512   attr=2, projid32bit=0
         =                       crc=0        finobt=0, sparse=0, rmapbt=0
         =                       reflink=0    bigtime=0 inobtcount=0 nrext64=0
data     =                       bsize=4096   blocks=2097152, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0, ftype=0
log      =internal log           bsize=4096   blocks=2560, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0


And the partition that seems to be working OK (but maybe it's just
luck?):

# xfs_db -r /dev/mapper/S-root23
xfs_db> version
versionnum [0xb4a5+0x18a] = V5,NLINK,DIRV2,ALIGN,LOGV2,EXTFLG,MOREBITS,ATTR2,LAZYSBCOUNT,PROJID32BIT,CRC,FTYPE,FINOBT,SPARSE_INODES,REFLINK,INOBTCNT,BIGTIME

# xfs_info /dev/mapper/S-root23
meta-data=/dev/mapper/S-root23   isize=512    agcount=4, agsize=524288 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=1        finobt=1, sparse=1, rmapbt=0
         =                       reflink=1    bigtime=1 inobtcount=1 nrext64=0
data     =                       bsize=4096   blocks=2097152, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0, ftype=1
log      =internal log           bsize=4096   blocks=16384, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0


Do we know if the breakage related to bigtime feature?


-- 
Jamie Heilman                     http://audible.transient.net/~jamie/