Bug 247996 - Filesystem not mounted properly at boot time
Filesystem not mounted properly at boot time
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
x86_64 Linux
low Severity medium
: ---
: ---
Assigned To: Anaconda Maintenance Team
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2007-07-12 12:16 EDT by Ian Collier
Modified: 2007-11-30 17:12 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-07-25 10:40:52 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
The /etc/fstab file (1.01 KB, text/plain)
2007-07-12 12:16 EDT, Ian Collier
no flags Details

  None (edit)
Description Ian Collier 2007-07-12 12:16:21 EDT
Description of problem:
An HP dc5750 mini-tower has eight ext3 partitions on /dev/sda (together with a
swap partition, a FAT32 partition and several NTFS partitions).  These are
listed in /etc/fstab in the normal way, using LABEL= in the first column (though
I don't think that matters).  However, the /usr/local partition (/dev/sda7)
doesn't get mounted properly at boot time.

Everything seems to be OK...
Syslog has the following lines:

EXT3 FS on sda7, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting.  Commit interval 5 seconds

And these commands all say it's mounted:
$ egrep local /proc/mounts
/dev/sda7 /usr/local ext3 rw,data=ordered 0 0

# mount -l | grep local
/dev/sda7 on /usr/local type ext3 (rw) [/usr/local]

$ df -h /usr/local
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda7             7.8G  5.9G  1.6G  80% /usr/local

But wait... those numbers look suspiciously familiar:
$ df -h /usr
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda6             7.8G  5.9G  1.6G  80% /usr

So now, try this:
# umount /usr/local
umount: /dev/sda7: not mounted
umount: /dev/sda7: not mounted
# fsck -f -n /dev/sda7
fsck 1.39 (29-May-2006)
e2fsck 1.39 (29-May-2006)
fsck.ext3: Device or resource busy while trying to open /dev/sda7
Filesystem mounted or opened exclusively by another program?

But this works:
# mount /usr/local
$ df -h /usr/local
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda7             3.9G   33M  3.7G   1% /usr/local
$ ls -A /usr/local
# umount /usr/local
$ df -h /usr/local
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda6             7.8G  5.9G  1.6G  80% /usr

What this means is that /usr/local wasn't even mounted properly when Fedora was
installed, because the filesystem rpm contains directories that have been
installed in the /local directory on the /usr filesystem rather than on the
/usr/local filesystem where they belong.  This system was installed by my
colleague from a Fedora 7 DVD on a clean disk and is being cloned (using, I
think, Norton Ghost); every clone exhibits the same behaviour.  I don't think
anything unusual happened during the install, though he may have partitioned the
disk using Partition Magic rather than using the dialogue that comes up during
the install process (though he'll have had to type in the mount point of each
partition at that point).

I don't know how to debug this, but I can supply more information on request. 
What could be going wrong?  For now I've had to resort to putting "mount
/usr/local" in /etc/rc.local...

Version-Release number of selected component (if applicable):

How reproducible:
Always (on this particular installation)

Steps to Reproduce:
See above.
Comment 1 Ian Collier 2007-07-12 12:16:22 EDT
Created attachment 159068 [details]
The /etc/fstab file
Comment 2 Ian Collier 2007-07-24 12:21:52 EDT
Having been presented with another system with a similar problem (this time an
HP nw9440 laptop which wouldn't mount /var/tmp) I had a brain wave.

Examination of the fstab from comment 1 reveals that /usr/local is listed before
/usr (quite a long way before, in fact).  Switching the order seems to have
fixed the problem.

So we have two potential bugs:
(a) that the installer wrote the fstab in this order in the first place (and
I've no idea in what order the partitions were typed in during the install, but
to a large extent that shouldn't matter); and
(b) that the system gets into this inconsistent state when it's in that order. 
(This may not be a bug, since it seems /usr/local is successfully mounted and
then the mount of /usr shadows it.  Only question is why the /usr/local mount
point existed in the root partition...)
Comment 3 Karel Zak 2007-07-25 08:15:13 EDT
That's wrong, the order of entries in the /etc/fstab is really important. 

Reassigning to anaconda...
Comment 4 Chris Lumens 2007-07-25 10:40:52 EDT
This is fixed in the development tree.

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