Bug 703852 - NFS mounts not getting mounted automatically during start-up
Summary: NFS mounts not getting mounted automatically during start-up
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd
Version: 15
Hardware: i686
OS: Linux
medium
medium
Target Milestone: ---
Assignee: systemd-maint
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-05-11 13:02 UTC by Jay Turner
Modified: 2015-01-08 00:17 UTC (History)
10 users (show)

Fixed In Version:
Clone Of:
: 710502 (view as bug list)
Environment:
Last Closed: 2012-01-24 18:52:05 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
boot.log for F15 system (8.10 KB, text/plain)
2011-05-11 13:02 UTC, Jay Turner
no flags Details
F15 messages (438.03 KB, text/plain)
2011-05-11 13:03 UTC, Jay Turner
no flags Details
dmesg output with systemd.log_level=debug (173.75 KB, text/plain)
2011-06-01 19:50 UTC, Dr. Tilmann Bubeck
no flags Details
/proc/self/mounts (2.24 KB, text/plain)
2011-06-01 19:51 UTC, Dr. Tilmann Bubeck
no flags Details
/etc/fstab (767 bytes, text/plain)
2011-06-01 19:51 UTC, Dr. Tilmann Bubeck
no flags Details
systemctl show home.mount output (1.83 KB, text/plain)
2011-06-01 19:56 UTC, Dr. Tilmann Bubeck
no flags Details
dmesg output with systemd.log_level=debug after disabling sandbox (172.42 KB, text/plain)
2011-06-03 16:38 UTC, Dr. Tilmann Bubeck
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 645805 0 low CLOSED NFS mounts in fstab not automatically mounted by systemd 2021-02-22 00:41:40 UTC
Red Hat Bugzilla 708784 0 unspecified CLOSED nfs directories not mounted after boot 2021-02-22 00:41:40 UTC

Internal Links: 645805 708784

Description Jay Turner 2011-05-11 13:02:57 UTC
Created attachment 498286 [details]
boot.log for F15 system

Description of problem:
I have a couple of nfs mounts listed in fstab as "auto" and yet both are failing to be mounted during F15 boot.  I tried the "systemctl enable NetworkManager-wait-online.service" trick, but that had no impact on the issue.

Version-Release number of selected component (if applicable):
# rpm -q systemd nfs-utils NetworkManager
systemd-26-1.fc15.x86_64
nfs-utils-1.2.3-11.fc15.x86_64
NetworkManager-0.8.999-2.git20110509.fc15.x86_64


How reproducible:
Every boot.

Steps to Reproduce:
1. Boot up a system with NetworkManager controlling networking and a few "auto" mounts listed in fstab.
  
Actual results:
"auto" mounts will not be automatically mounted;  they will mount successfully post-boot with "mount -a"

Expected results:
"auto" mounts should be mounted automatically

Additional info:

Comment 1 Jay Turner 2011-05-11 13:03:26 UTC
Created attachment 498288 [details]
F15 messages

Comment 2 Jay Turner 2011-05-11 13:04:01 UTC
Look for "/mnt/partners" and "/mnt/ginger" in the attached log files.

Comment 3 Michal Schmidt 2011-05-11 13:13:00 UTC
Hi Jay,
Could you please boot with "log_buf_len=1M systemd.log_target=kmsg systemd.log_level=debug" and attach the output of "dmesg"? Thanks.

Comment 4 Jay Turner 2011-05-11 15:06:28 UTC
Oddly enough, I have done a number of reboots today and am not seeing the mount problem.  I did have one boot where the nfslock service failed to start, but have been unable to reproduce that as well.  Closing this out.  Will reopen if the problem surfaces again.

Comment 5 Dr. Tilmann Bubeck 2011-06-01 19:48:42 UTC
I have the exact same issue. Please find all log files attached.

Additionally I found out, that logging into gnome (as root) and using nm-applet to turn ethernet off and on again results in /home from NFS being mounted.

Comment 6 Dr. Tilmann Bubeck 2011-06-01 19:50:06 UTC
Created attachment 502364 [details]
dmesg output with systemd.log_level=debug

Comment 7 Dr. Tilmann Bubeck 2011-06-01 19:51:13 UTC
Created attachment 502365 [details]
/proc/self/mounts

Comment 8 Dr. Tilmann Bubeck 2011-06-01 19:51:42 UTC
Created attachment 502366 [details]
/etc/fstab

Comment 9 Dr. Tilmann Bubeck 2011-06-01 19:56:20 UTC
I use 

NetworkManager-0.8.9997-1.git20110531.fc15.i686
systemd-26-2.fc15.i686
systemd-sysv-26-2.fc15.i686
systemd-units-26-2.fc15.i686

Here are some additional infos:

[root@sam ~]# systemctl status home.mount
home.mount - /home
	  Loaded: loaded
	  Active: active (mounted) since Wed, 01 Jun 2011 21:38:34 +0200; 16min ago
	   Where: /home
	    What: /dev/sda7
	  CGroup: name=systemd:/system/home.mount

Comment 10 Dr. Tilmann Bubeck 2011-06-01 19:56:55 UTC
Created attachment 502368 [details]
systemctl show home.mount output

Comment 11 Michal Schmidt 2011-06-03 15:04:03 UTC
(In reply to comment #6)
> dmesg output with systemd.log_level=debug

I see two problems:
1. Something gets mounted on /home even before the network is started. It must be the sandbox service. Try disabling it.

2. NetworkManager-wait-online.service is not working as expected. It quits
   immediately with a failure:

[   21.703189] systemd[1]: Job NetworkManager.service/start finished, result=done
[   21.706765] systemd[1]: About to execute: /usr/bin/nm-online -q -x --timeout=30
[   21.723075] systemd[1]: Forked /usr/bin/nm-online as 814
[   21.726549] systemd[1]: NetworkManager-wait-online.service changed dead -> start
[   21.865662] r8169 0000:02:00.0: em1: link down
[   21.868962] r8169 0000:02:00.0: em1: link down
[   21.872380] ADDRCONF(NETDEV_UP): em1: link is not ready
[   22.011777] systemd[1]: Got D-Bus request: org.freedesktop.DBus.NameOwnerChanged() on /org/freedesktop/DBus
[   22.016442] systemd[1]: Received SIGCHLD from PID 814 (nm-online).
[   22.019876] systemd[1]: Got SIGCHLD for process 814 (nm-online)
[   22.023156] systemd[1]: Child 814 died (code=exited, status=1/FAILURE)
[   22.026386] systemd[1]: Child 814 belongs to NetworkManager-wait-online.service
[   22.029609] systemd[1]: NetworkManager-wait-online.service: main process exited, code=exited, status=1


   The link is not ready yet, therefore NM is not connecting. "-x" was
   passed to nm-online, so it quits.
   That's why the original NM initscript did something similar to:
ExecStart=/bin/sh -c 'nm-online -q --timeout=10 || nm-online -q -x --timeout=30'
   (which is what I originally proposed for NetworkManager-wait-online.service)

Comment 12 Michal Schmidt 2011-06-03 15:07:36 UTC
> 2. NetworkManager-wait-online.service is not working as expected. It quits
>    immediately with a failure:

Filed as bug 710502

Comment 13 Dr. Tilmann Bubeck 2011-06-03 16:37:03 UTC
/home is now mounted after "systemctl disable sandbox.service" and a reboot.
Please find attached the systemd.log.

Comment 14 Dr. Tilmann Bubeck 2011-06-03 16:38:24 UTC
Created attachment 502858 [details]
dmesg output with systemd.log_level=debug after disabling sandbox

With a disabled sandbox service, /home is mounted sucessfully.

Comment 15 Fedora Admin XMLRPC Client 2011-10-20 16:29:53 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 16 Jóhann B. Guðmundsson 2012-01-24 13:12:13 UTC
Is this still a problem or can this bug be closed?

Comment 17 Dr. Tilmann Bubeck 2012-01-24 18:52:05 UTC
I checked it with a fresh install of F16 and everything runs smoothly. No problem mounting NFS shares in /etc/fstab. There is also no need to disable the sandbox service as written above.

Comment 18 Frank Ch. Eigler 2013-05-27 15:35:38 UTC
FWIW, I'm seeing what seems like a recurrence of this problem on rawhide;
systemctl status home.mount sez:

home.mount - /home
   Loaded: loaded (/etc/fstab)
   Active: active (mounted) (Result: exit-code) since Mon 2013-05-27 11:17:59 EDT; 16min ago
    Where: /home
     What: super:/home
  Process: 248 ExecMount=/bin/mount super:/home/ /home -t nfs -o ro,bg,hard,intr (code=exited, status=32)


(where 'super' is an ipv4 host listed in /etc/hosts).  A manual run of that command eventually mounts the filesystem, but complains of various rpc services being absent.  It's as though those various .want symlinks are not set right.


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