Bug 198063 - rescue mode fails to mount non-root filesystems
rescue mode fails to mount non-root filesystems
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
6
All Linux
medium Severity medium
: ---
: ---
Assigned To: Chris Lumens
Mike McLean
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-07-08 19:37 EDT by John Reiser
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-07-11 13:42:13 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description John Reiser 2006-07-08 19:37:52 EDT
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
-----
Comment 1 Chris Lumens 2006-07-11 10:44:35 EDT
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.
Comment 2 John Reiser 2006-07-11 13:29:19 EDT
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.
Comment 3 Chris Lumens 2006-07-11 13:42:13 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.