Red Hat Bugzilla – Bug 198063
rescue mode fails to mount non-root filesystems
Last modified: 2007-11-30 17:11:36 EST
Description of problem:
After the user specifies which filesystem has the root of the system to be
rescued, then mounting the root succeeds but mounting other filesystems (as
specified in /etc/fstab) fails.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. "boot: linux rescue", language, keyboard, no network.
2. Choose a root filesystem that has other filesystems mounted per /etc/fstab.
VT1 presents a dialog "Some error occurred while mounting ...". VT3 shows:
INFO : trying to mount hda7 on /home1
ERROR : could not create directory /mnt/sysimage//home1: File exists
where the double slash "//" appears thusly, and of course /mnt/sysimage/home1
exists, because that's where it is mounted on every succesful boot.
Successful mount of filesystems named in /etc/fstab.
Additional info: The line from /etc/fstab is
LABEL=/home /home1 ext3 defaults,nodiratime 1 2
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.