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): anaconda-11.1.0.54-1 How reproducible: always Steps to Reproduce: 1. "boot: linux rescue", language, keyboard, no network. 2. Choose a root filesystem that has other filesystems mounted per /etc/fstab. 3. Actual results: 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. Expected results: 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.