Bug 115799
Summary: | mount has trouble with disklabels during CD boot | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Ellen Shull <ellenshull> |
Component: | util-linux | Assignee: | Elliot Lee <sopwith> |
Status: | CLOSED RAWHIDE | QA Contact: | Ben Levenson <benl> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | rawhide | CC: | katzj, wtogami |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i386 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2004-03-13 01:21:21 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: | |||
Bug Depends On: | |||
Bug Blocks: | 114961 |
Description
Ellen Shull
2004-02-16 08:33:06 UTC
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. |