Bug 122043 - mounting by label breaks XFS
Summary: mounting by label breaks XFS
Alias: None
Product: Fedora
Classification: Fedora
Component: xfsprogs
Version: rawhide
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Jeremy Katz
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2004-04-29 21:34 UTC by Florin Andrei
Modified: 2007-11-30 22:10 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2006-04-24 18:49:06 UTC
Type: ---

Attachments (Terms of Use)
strace mount -L /home /home 2> strace.txt (6.62 KB, text/plain)
2004-04-30 21:48 UTC, Florin Andrei
no flags Details
fix for xfs mkfs to obliterate md superblocks on device (1.80 KB, patch)
2004-05-03 22:32 UTC, Eric Sandeen
no flags Details | Diff

Description Florin Andrei 2004-04-29 21:34:14 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040116

Description of problem:
I booted up the FC2 test 3 installer with "linux xfs" then formated
partitions with XFS instead of Ext3.
/dev/sda1    /boot    Ext3
/dev/sda2    /        XFS
/dev/sdb1    swap
/dev/sdc1    /home    XFS
/dev/sdd1    /var     XFS
When booting up for the first time, the system got mangled, it stopped
booting up, saying it cannot find LABEL=/var and stuff like that.
Obviously, it couldn't mount /home and /var.
Curiously enough, it was able to mount / just fine. But no XFS
partition on disks other than sda got mounted.

I rebooted in single mode, hacked /etc/fstab to use the /dev/sd**
symbolism instead of labels, and now it's fine.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.install system with XFS partitions on various drives

Actual Results:  XFS partitions on drives other than first one cannot
be mounted.

Expected Results:  Partitions should be mounted regardless of filesystem.

Additional info:

I think i've heard that XFS has issues with disk labels. Perhaps it's
better not to use labels with XFS.
Please modify the installer so that it creates /etc/fstab to use
proper device names instead of labels for XFS partitions. Perhaps it's
safer to create /boot/grub/grub.conf the same way?

Comment 1 Eric Sandeen 2004-04-30 04:16:03 UTC
Florin - xfs mounts by label just fine.... not aware of any issues.

how about outside the boot process, can you make a new fs, label it,
and mount by label?

Comment 2 Eric Sandeen 2004-04-30 04:22:50 UTC
ok i can do the test can't I :)

[root@lite root]# xfs_admin -L test /dev/sda1
writing all SBs
new label = "test"
[root@lite root]# mount -L test /mnt/sda1
[root@lite root]# mount -l | grep sda1
/dev/sda1 on /mnt/sda1 type xfs (rw) [test]
[root@lite root]# uname -a
Linux lite.americas.sgi.com 2.6.5-1.327smp #1 SMP Sun Apr 18 05:15:53
EDT 2004 i686 i686 i386 GNU/Linux
[root@lite root]# 

works fine here, manually.

Comment 3 Eric Sandeen 2004-04-30 04:24:54 UTC
florin, also try xfs_admin -l /dev/device on the devices in question,
to see if the labels were written properly.

Comment 4 Florin Andrei 2004-04-30 18:10:49 UTC
The system is a SGI1200, L440GX+, 4 SCSI drives, 2xPIII/800

I'll describe only my non-default actions during install.

Boot up the installer with "linux acpi=force xfs text"
CD Found - select Skip
Warning - select Install Anyway
Monitor Configuration - select SGI 21-inch GDM-5411
System To Upgrade - select Reinstall System
Installation Type - select Custom
Disk Partitioning Setup - select Autopartition
Automatic Partitioning - select Remove All Partitions...
Partitioning: It autocreates these partitions:
/dev/sda1	/boot	Ext3
/dev/sda2	/	Ext3
/dev/sdb1		swap
I modify /dev/sda2 to XFS.
I create the following:
/dev/sdc1	/home	XFS	Fill All Available Space
/dev/sdd1	/var	XFS	Fill All Available Space
Boot Loader Configuration - it has "acpi=force" as parameter,
i modify it to "acpi=force vga=773"
Firewall - select No Firewall
Time Zone Selection - select America/Los_Angeles
Package Group Selection - un-select everything; Total Install Size is
reported as 564M

Finish up install... Reboot...

A bunch of errors are popping out at Mounting Local Filesystems:
mount: special device LABEL=/home does not exist
mount: special device LABEL=/var does not exist

Then a bunch of errors related to stuff in /var
syslog gets stuck at startup for a VERY long time
I'm out of patience, hit CTRL-ALT-DEL

Boot in single mode
Create backup copy of fstab.
Edit /etc/fstab and replace LABEL with actual devices everywhere.

Reboot in multiuser mode... No errors whatsoever.

I create /dev/sdb2

# mkfs.xfs /dev/sdb2
# xfs_admin -L blah /dev/sdb2
# mount -L blah /mnt/cdrom

It works!

# mount -l
/dev/sda2 on / type xfs (rw) [/]
none on /proc type proc (rw)
none on /sys type sysfs (rw)
none on /dev/pts type devpts (rw,gid=5,mode=620)
usbdevfs on /proc/bus/usb type usbdevfs (rw)
/dev/sda1 on /boot type ext3 (rw) [/boot]
none on /dev/shm type tmpfs (rw)
/dev/sdc1 on /home type xfs (rw)
/dev/sdd1 on /var type xfs (rw)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
/dev/sdb2 on /mnt/cdrom type xfs (rw) [blah]

# xfs_admin -l /dev/sdc1
label = "/home"
# xfs_admin -l /dev/sdd1
label = "/var"
# xfs_admin -l /dev/sda2
label = "/"

But get this:

# umount /home
# mount -L /home /home
mount: no such partition found
# mount -L home /home
mount: no such partition found
# xfs_admin -L home /dev/sdc1
writing all SBs
new label = "home"
# mount -L home /home
mount: no such partition found

It works for my custom partition /dev/sdb2, but it does not
for partitions created by the installer.

Comment 5 Eric Sandeen 2004-04-30 19:24:05 UTC
florin - next I might try an strace of the failing mount command
(i.e. mount -L home /home)

See what devices it's actually looking at.

Comment 6 Florin Andrei 2004-04-30 21:48:40 UTC
Created attachment 99849 [details]
strace mount -L /home /home 2> strace.txt

Here's your strace, Eric.
The label is supposed to be correct, yet mount fails.
# xfs_admin -l /dev/sdc1
label = "/home"

Comment 7 Eric Sandeen 2004-05-01 02:39:04 UTC
hm, thought I sent this from work, apologies if it gets in 2x.

mount by label is getting as far as get_label_uuid, but
then bails out on:

        /* If there is a RAID partition, or an error, ignore this
partition */
        if (is_raid_partition(fd)) {
                return rv;

(for the device we want to mount, sdc1, you just see an open, ioctl,
seek to the end of the device, and read - if it had gotten past
the above test next you'd see a seek to 1024 and another read,
as with some of your other devices)

so it reads the last few blocks of the device, and does:

return (mdsb.md_magic == MD_SB_MAGIC); /* If this device has a
                                                  RAID superblock at
                                                  the end, it must be
                                                  part of a RAID
                                                  array. */

MD_SB_MAGIC is 0xa92b4efc...   strace showed us 
read(4, "\374N+\251", 4)                = 4

374 oct is fc, 251 oct is a9... looks like we found a raid sb at
the end of this device and didn't look any further.

mkfs.xfs is supposed to zero this out.... florin, can I re-mkfs the
device for /home to watch what mkfs.xfs is doing?

Comment 8 Eric Sandeen 2004-05-01 12:57:59 UTC
ok, last add :)  mkfs.xfs was literally zeroing the last 64k bytes
on the device, but md calculates the location a little differently,
so we missed in this case.  I have a mod in for review, will post
here when it gets checked in.

Comment 9 Eric Sandeen 2004-05-03 22:32:49 UTC
Created attachment 99933 [details]
fix for xfs mkfs to obliterate md superblocks on device

This will fix florin's problem.

should apply fine to the version of xfsprogs in fc2test3, but perhaps you
guys can just pick up 2.6.13 from ftp://oss.sgi.com/projects/xfs/ - the
you have is plenty old.  (the new rpm will be up in just a bit)



Comment 10 Florin Andrei 2004-05-05 16:40:08 UTC
Following Eric's suggestion, i'm moving the bug from anaconda to xfsprogs.
There's no point in me testing the patch provided by Eric, he has root
access to my test system anyway and... well... he can test things a
lot better than me. ;-)

Comment 11 Jeremy Katz 2004-05-05 20:46:34 UTC
Building xfsprogs-2.6.13 now.  Thanks Eric.

Comment 12 Theo Van Dinter 2005-06-14 22:41:18 UTC
FYI: This is still happening with FC4 and xfsprogs 2.6.13-4.

I've been testing out FC4 kickstarts and have found that any of my filesystems which are xfs are not 
mountable via label upon reboot.

At first, I wanted everything to be xfs, so I used:

zerombr yes
clearpart --initlabel --all
part /boot --size 128 --asprimary --fstype xfs
part swap --size 4096
part / --size 4096 --fstype xfs
part /apps --size 1 --grow --fstype xfs

Everything installed correctly, but upon reboot the kernel paniced unable to find root device.  So I 
rekickstarted with only /apps as xfs:

zerombr yes
clearpart --initlabel --all
part /boot --size 128 --asprimary
part swap --size 4096
part / --size 4096
part /apps --size 1 --grow --fstype xfs

and now the system can come up, but /apps will not mount:

[root@dhcp-qa-212 ~]# grep /apps /etc/fstab
LABEL=/apps             /apps                   xfs     defaults        1 2
[root@dhcp-qa-212 ~]# mount /apps
mount: special device LABEL=/apps does not exist
[root@dhcp-qa-212 ~]# xfs_admin -l /dev/sda5
warning: AG 1 label differs
warning: AG 2 label differs
warning: AG 3 label differs
warning: AG 4 label differs
warning: AG 5 label differs
warning: AG 6 label differs
warning: AG 7 label differs
warning: AG 8 label differs
warning: AG 9 label differs
warning: AG 10 label differs
warning: AG 11 label differs
warning: AG 12 label differs
warning: AG 13 label differs
warning: AG 14 label differs
warning: AG 15 label differs
label = "/apps"

If I have xfs_admin "change" the label to be /apps, it works fine:

[root@dhcp-qa-212 ~]# xfs_admin -L /apps /dev/sda5
writing all SBs
new label = "/apps"
[root@dhcp-qa-212 ~]# xfs_admin -l /dev/sda5
label = "/apps"
[root@dhcp-qa-212 ~]# mount /apps
[root@dhcp-qa-212 ~]# 

Comment 13 Eric Sandeen 2005-06-14 23:01:50 UTC
This looks like a different issue from the original one, which was a case of
finding MD superblock markers.  What does anaconda
do to put an xfs fs label on-disk now?  It looks like xfsprogs is not happy
with what's been done; hence the "warning: AG X label differs" messages.

perhaps that's what's causing the problem...

Comment 14 Orion Poplawski 2005-06-21 17:35:55 UTC
New issue is being tracked in bug 160444

Comment 15 Jeremy Katz 2006-04-24 18:49:06 UTC
Mass-closing lots of old bugs which are in MODIFIED (and thus presumed to be
fixed).  If any of these are still a problem, please reopen or file a new bug
against the release which they're occurring in so they can be properly tracked.

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