Bug 198063
Summary: | rescue mode fails to mount non-root filesystems | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | John Reiser <jreiser> |
Component: | anaconda | Assignee: | Chris Lumens <clumens> |
Status: | CLOSED NOTABUG | QA Contact: | Mike McLean <mikem> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 6 | ||
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2006-07-11 17:42:13 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: |
Description
John Reiser
2006-07-08 23:37:52 UTC
What is the exact error message you're seeing? Error messages about not being able to create the directory should be ignored as long as it says "File exists", because that just means we're trying to create a mount point that already exists. That message should probably be cleaned up a little bit. I cannot recall the exact wording of the dialog box on VT1, and I cannot reproduce the error today. But today /dev/hda has a valid grub installation in MBR (Master Boot Record). When I saw the problem on Saturday about rescue mode not mounting all filesystems, then the first sector on /dev/hda had only a good partition table in bytes 446 to 510. The rest of the first sector was garbage, perhaps all zeroes, including bytes 510 and 511, the signature pair that often is expected to contain 0xa55a. I was replacing a drive whose service life was expiring with a newer drive, had copied all data, and was trying to use rescue mode to install the boot loader. (grub-install must be run from an active system with /boot already mounted [if necessary]. In the end I used KNOPPIX to run grub-install.) So if reading the partition chain to look for the correct LABEL to mount is not as lenient about unexpected signatures in the partition chain as finding the root in the first place, then that would explain what I saw. We use parted to find all the partitions on the disk, which would have to check the partition table. The filesystem labels themselves are then detected later in the superblocks of each filesystem, so shouldn't have anything to do with partition tables. Perhaps parted got confused from a corrupted partition table and was presenting anaconda an incorrect picture of what's on the disk? Feel free to reopen if you can reproduce this problem, and we'll see if we can't pin down which component isn't working right. |