Bug 122043
Summary: | mounting by label breaks XFS | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Florin Andrei <florin> | ||||||
Component: | xfsprogs | Assignee: | Jeremy Katz <katzj> | ||||||
Status: | CLOSED RAWHIDE | QA Contact: | |||||||
Severity: | medium | Docs Contact: | |||||||
Priority: | medium | ||||||||
Version: | rawhide | CC: | sandeen | ||||||
Target Milestone: | --- | ||||||||
Target Release: | --- | ||||||||
Hardware: | i686 | ||||||||
OS: | Linux | ||||||||
Whiteboard: | |||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||
Doc Text: | Story Points: | --- | |||||||
Clone Of: | Environment: | ||||||||
Last Closed: | 2006-04-24 18:49:06 UTC | Type: | --- | ||||||
Regression: | --- | Mount Type: | --- | ||||||
Documentation: | --- | CRM: | |||||||
Verified Versions: | Category: | --- | |||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||
Embargoed: | |||||||||
Attachments: |
|
Description
Florin Andrei
2004-04-29 21:34:14 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? 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. florin, also try xfs_admin -l /dev/device on the devices in question, to see if the labels were written properly. 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. 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. 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"
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)) { close(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? 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. 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 xfsprogs you have is plenty old. (the new rpm will be up in just a bit) thanks, -eric 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. ;-) Building xfsprogs-2.6.13 now. Thanks Eric. 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 ~]# 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... New issue is being tracked in bug 160444 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. |