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: Always Steps to Reproduce: 1.install system with XFS partitions on various drives 2. 3. 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?
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.