Description of problem: During a boot from a boot CD, mount fails to remount my root fs rw in rc.sysinit. Changing the relevant line in /etc/fstab from LABEL=/ / ext3 defaults 1 1 to /dev/md0 / ext3 defaults 1 1 makes it work. The label on /dev/md0 is still "/" (I double-checked), and there are no other volumes with that label to be confusing it... Version-Release number of selected component (if applicable): util-linux-2.12pre-3 How reproducible: always Steps to Reproduce: 0. Set label on your / fs to "/" and edit fstab to use LABEL=/ instead of the /dev/whatever 1. Make boot CD image with mkbootdisk --iso and burn (you can check out the exact image I'm using): http://kuoi.asui.uidaho.edu/~wes/boot-2.6.1-1.65.iso , 2.17 MB) 2. Boot off the CD 3. Watch it fail to remount rw... Actual results: something like "can't find / in /etc/fstab" Expected results: clean rw remount of /...
May not be the util-linux mount. I'm not sure yet.
If you run e2label directly on the devices that comprise /dev/md0, do both report "/"? In RH9 and FC1, mount gets confused and fails if multiple partitions have the same label.
Have finally done some more testing trying to pin this down, with mixed results... from dmesg: raid5: raid level 5 set md0 active with 5 out of 5 devices, algorithm 0 RAID5 conf printout: --- rd:5 wd:5 fd:0 disk 0, o:1, dev:hdi1 disk 1, o:1, dev:hde1 disk 2, o:1, dev:hdk1 disk 3, o:1, dev:hda1 disk 4, o:1, dev:hdg1 # e2label /dev/md0 / # e2label /dev/hdi1 / on the other four partitions e2label complains, such as: e2label: Bad magic number in super-block while trying to open /dev/hde1 Couldn't find valid filesystem superblock. Being unclear as to how hdi1 got a label, I did # e2label /dev/hdi1 "" that didn't seem to stick... when I next checked (before I got around to rebooting), its label had been automagically restored to "/". Plus, I experienced a journaling failure about then and had to e2fsck and fish a fair portion of my home directory out of lost+found. Related? Stupid move on my part? A few days later (lots of rawhide to update!) I did a # e2label /dev/md0 foo as expected, /dev/hdi1 is now "foo" as well. I modified my fstab changing /dev/md0 to "LABEL=foo", rebooted (into 2.6.3-2.1.253), and this time it didn't have a problem, so it's not a collision between md0 and hdi1... I've check my boot CD images, and they have no disklabels. # mount LABEL=/ /mnt/loop mount: no such partition found so there's nothing else there... I haven't yet done the final test of "e2label /dev/md0 /", mod the fstab, and reboot, but from what I can see the problem is probably gone, whatever it was...
Forgot to mention that wxPython did successfully build against an earlier rawhide gtk2, don't remember exactly but probably the gtk2-2.3.2-2.i386.rpm that was in the FC2T1 release.
Darnit, wrong bug, sorry...
Ok, I just changed everything back to LABEL=/ and rebooted; it seems to work fine now. Since I can no longer reproduce the bug and nobody else seems to be reporting it, I'm closing it.