Bug 198063 - rescue mode fails to mount non-root filesystems
Summary: rescue mode fails to mount non-root filesystems
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 6
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Chris Lumens
QA Contact: Mike McLean
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-07-08 23:37 UTC by John Reiser
Modified: 2007-11-30 22:11 UTC (History)
0 users

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2006-07-11 17:42:13 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description John Reiser 2006-07-08 23:37:52 UTC
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 14:44:35 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.

Comment 2 John Reiser 2006-07-11 17:29:19 UTC
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 17:42:13 UTC
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.