Bug 115799

Summary: mount has trouble with disklabels during CD boot
Product: [Fedora] Fedora Reporter: Ellen Shull <ellenshull>
Component: util-linuxAssignee: Elliot Lee <sopwith>
Status: CLOSED RAWHIDE QA Contact: Ben Levenson <benl>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: katzj, wtogami
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-03-12 20:21:21 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 114961    

Description Ellen Shull 2004-02-16 03:33:06 EST
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  
/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):  
How reproducible:  
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 /...
Comment 1 Elliot Lee 2004-02-24 09:53:45 EST
May not be the util-linux mount. I'm not sure yet.
Comment 2 Warren Togami 2004-03-05 23:59:47 EST
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.
Comment 3 Ellen Shull 2004-03-12 01:14:32 EST
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 
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... 
Comment 4 Ellen Shull 2004-03-12 01:39:19 EST
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. 
Comment 5 Ellen Shull 2004-03-12 01:40:44 EST
Darnit, wrong bug, sorry... 
Comment 6 Ellen Shull 2004-03-12 20:21:21 EST
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.