Description of problem:
During a boot from a boot CD, mount fails to remount my root fs rw
Changing the relevant line in /etc/fstab from
LABEL=/ / ext3 defaults
/dev/md0 / ext3 defaults
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):
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...
something like "can't find / in /etc/fstab"
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
raid5: raid level 5 set md0 active with 5 out of 5 devices, algorithm
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
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.