Bug 199114 - umount of partitions without any reason and log
umount of partitions without any reason and log
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: gnome-mount (Show other bugs)
5
All Linux
medium Severity high
: ---
: ---
Assigned To: David Zeuthen
bzcl34nup
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-07-17 06:42 EDT by Klaus Munsteiner
Modified: 2013-03-05 22:46 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-05-06 12:07:43 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
/etc/fstab (532 bytes, application/text)
2006-07-17 06:42 EDT, Klaus Munsteiner
no flags Details

  None (edit)
Description Klaus Munsteiner 2006-07-17 06:42:17 EDT
Description of problem:
Partitions which are NOT / will be unmounted without any reason and message. 
This happens on a i386 with a patition /backup and /boot and on a i386_64 with
the partitions /backup and /home. 

Sometimes if I logoff as root on the i386_64 (test machine) and wanted to login
as normal user, I got the message, that the /home directory isn't available. The
/backup directory was unmounted, too. Root could mount the partitions.

At the i368 (productive machine) I made a new installation, as I had separate
partitions for /boot and /backup. Both were unmounted without any reason and log.
Now the machine has only / and /backup partitions. This is a workarount as
unmounting /backup isn't important for the operating.

This errors happen, if the machines are running in runlevel 3 and 5. I prefer
KDE, but I think it happened with gnome in runlevel 5, too.


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


How reproducible:


Steps to Reproduce:
1. Let the machine run, wait and check sometimes
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 Klaus Munsteiner 2006-07-17 06:42:17 EDT
Created attachment 132541 [details]
/etc/fstab
Comment 2 Klaus Munsteiner 2006-07-17 06:57:58 EDT
File /etc/fstab:


LABEL=/1                /                       ext3    defaults        1 1
LABEL=/backup           /backup                 ext3    defaults        1 2
devpts                  /dev/pts                devpts  gid=5,mode=620  0 0
tmpfs                   /dev/shm                tmpfs   defaults        0 0
proc                    /proc                   proc    defaults        0 0
sysfs                   /sys                    sysfs   defaults        0 0
LABEL=SWAP-hda5         swap                    swap    defaults        0 0
Comment 3 Klaus Munsteiner 2006-07-17 07:00:11 EDT
File /etc/mtab with /backup umounted:


/dev/hda6 / ext3 rw 0 0
proc /proc proc rw 0 0
sysfs /sys sysfs rw 0 0
devpts /dev/pts devpts rw,gid=5,mode=620 0 0
tmpfs /dev/shm tmpfs rw 0 0
none /proc/sys/fs/binfmt_misc binfmt_misc rw 0 0
sunrpc /var/lib/nfs/rpc_pipefs rpc_pipefs rw 0 0
automount(pid1627) /net autofs rw,fd=4,pgrp=1627,minproto=2,maxproto=4 0 0
Comment 4 Klaus Munsteiner 2006-07-17 07:04:07 EDT
File /etc/mtab after /backup mounted manualy:

/dev/hda6 / ext3 rw 0 0
proc /proc proc rw 0 0
sysfs /sys sysfs rw 0 0
devpts /dev/pts devpts rw,gid=5,mode=620 0 0
tmpfs /dev/shm tmpfs rw 0 0
none /proc/sys/fs/binfmt_misc binfmt_misc rw 0 0
sunrpc /var/lib/nfs/rpc_pipefs rpc_pipefs rw 0 0
automount(pid1627) /net autofs rw,fd=4,pgrp=1627,minproto=2,maxproto=4 0 0
/dev/hda7 /backup ext3 rw 0 0
Comment 5 Klaus Munsteiner 2006-07-17 07:12:46 EDT
Part of file /var/log/messages, 
here you can see the manul mount, too:

Jul 17 12:19:28 scuxentw automount[22391]: >> /usr/sbin/showmount: can't get
address for .directory
Jul 17 12:19:28 scuxentw automount[22391]: lookup(program): lookup for
.directory failed
Jul 17 12:19:28 scuxentw automount[22391]: failed to mount /net/.directory
Jul 17 13:10:38 scuxentw kernel: kjournald starting.  Commit interval 5 seconds
Jul 17 13:10:38 scuxentw kernel: EXT3 FS on hda7, internal journal
Jul 17 13:10:38 scuxentw kernel: EXT3-fs: mounted filesystem with ordered data mode.
Jul 17 13:14:27 scuxentw automount[22775]: >> /usr/sbin/showmount: can't get
address for .directory
Jul 17 13:14:27 scuxentw automount[22775]: lookup(program): lookup for
.directory failed
Jul 17 13:14:27 scuxentw automount[22775]: failed to mount /net/.directory

*************************************************************************

Where comes this message from? There are a lot of them in the logs of both machines:
Jul 17 13:14:27 scuxentw automount[22775]: >> /usr/sbin/showmount: can't get
address for .directory
Comment 6 Nicholas Redgrave 2006-11-16 06:58:42 EST
I thought I was going crazy - this has been happening to me too.
I'm running a KDE desktop on a slightly custom 2.6.16 on an i686 (Athlon) and
have been since April 1 2006.  Everything else is kept up to date with yum.  The
machine runs constantly which is probably why I have noticed this unmounting
effect.  I can't say exactly how long it's been happening but I would say
perhaps no more than a month.

Here is my fstab:

LABEL=/                 /                       ext3    defaults        1 1
LABEL=capture           /capture                ext3    defaults        1 2
none                    /dev/pts                devpts  gid=5,mode=620  0 0
none                    /dev/shm                tmpfs   defaults        0 0
LABEL=/home             /home                   ext3    defaults        1 2
none                    /proc                   proc    defaults        0 0
none                    /sys                    sysfs   defaults        0 0
LABEL=/work             /work                   ext3    defaults        1 2
/dev/hda3               swap                    swap    defaults        0 0

/dev/hda1               /mnt/w98c               vfat    defaults        0 0
/dev/hda5               /mnt/w98e               vfat    defaults        0 0
/dev/hda6               /mnt/w98f               vfat    defaults        0 0
/dev/hdb1               /mnt/w98d               vfat    defaults        0 0

/dev/fd0                /mnt/floppy             auto    noauto,owner    0 0
/dev/hdc                /mnt/dvd-dl             auto   
noauto,owner,exec,pamconsole    0 0
/dev/hdd                /mnt/dvd                auto   
noauto,owner,exec,pamconsole    0 0

/dev/DC2302             /mnt/DC2302             vfat    noauto,user,exec  0 0
/dev/flashdrive         /mnt/flashdrive         vfat    noauto,user,exec  0 0
/dev/UCR-MS             /mnt/UCR-MS             vfat    noauto,user,exec  0 0
/dev/UCR-CF             /mnt/UCR-CF             vfat    noauto,user,exec  0 0
/dev/UCR-SD             /mnt/UCR-SD             vfat    noauto,user,exec  0 0
/dev/UCR-SM             /mnt/UCR-SM             vfat    noauto,user,exec  0 0
/dev/PowerMusicFlash    /mnt/PowerMusic         vfat    noauto,user,exec  0 0
/dev/PowerMusicSD       /mnt/PowerMusicSD       vfat    noauto,user,exec  0 0


mjr800:/home/mjr                                /mnt/mjr800             nfs    
noauto,user,rsize=8192,wsize=8192,timeo=14,intr
fireserver:/home/projects/shared                /mnt/shared             nfs    
user,rsize=8192,wsize=8192,timeo=14,intr
fireserver:/var/www/upload                      /home/njr/irc/upload    nfs    
user,rsize=8192,wsize=8192,timeo=14,int

At irregular intervals and without any log messages, "/capture", "/work",
"/mnt/w98c", "/mnt/win98d", "/mnt/win98e" and "/mnt/w98f" get unmounted and
their entries disappear from "/etc/mtab".  These partitions are spread over two
physical disks so it's probably not a disk fault - I have run SMARTD diagnostics
on both disks and both are reported as being healthy.  The "/" and "/home"
partitions have not so far suffered from this problem.  As you can see, the
vanishing mounts are using a mixture of ext3 and vfat so it's not confined to
one partition type.
The NFS mounts do not suffer from this automatic unmounting.
I don't know if it affects the USB connected partitions either since they are
only attached briefly.
After the partitions have unmounted, I can remount them as root without any
trouble and the system continues to operate as normal - until it happens again.

Please let me know if there are any tests you'd like conducted.

Best regards,

Nicholas Redgrave
Comment 7 Bug Zapper 2008-04-03 23:19:13 EDT
Fedora apologizes that these issues have not been resolved yet. We're
sorry it's taken so long for your bug to be properly triaged and acted
on. We appreciate the time you took to report this issue and want to
make sure no important bugs slip through the cracks.

If you're currently running a version of Fedora Core between 1 and 6,
please note that Fedora no longer maintains these releases. We strongly
encourage you to upgrade to a current Fedora release. In order to
refocus our efforts as a project we are flagging all of the open bugs
for releases which are no longer maintained and closing them.
http://fedoraproject.org/wiki/LifeCycle/EOL

If this bug is still open against Fedora Core 1 through 6, thirty days
from now, it will be closed 'WONTFIX'. If you can reporduce this bug in
the latest Fedora version, please change to the respective version. If
you are unable to do this, please add a comment to this bug requesting
the change.

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we are following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.

And if you'd like to join the bug triage team to help make things
better, check out http://fedoraproject.org/wiki/BugZappers
Comment 8 Bug Zapper 2008-05-06 12:07:42 EDT
This bug is open for a Fedora version that is no longer maintained and
will not be fixed by Fedora. Therefore we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen thus bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

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