Hi Sven, Am 26.06.2015 um 19:28 schrieb Sven Joachim: > On 2015-06-26 18:38 +0200, Jonas Meurer wrote: >>> # grep nfs /etc/fstab >>> nfs-server:/vmail /var/vmail nfs4 _netdev,sec=krb5i,bg 0 0 >> >> results in unmounted NFS shares after reboot and: >> >>> >>> Jun 26 16:29:02 clt mount[352]: mount.nfs4: an incorrect mount >>> option was specified > > mount.nfs4 prints this not very enlightening message if the mount > syscall fails with EINVAL.
Very helpful ;) Thanks for the hint. At least it's good to know that my fstab options are not the problem here. >> Maybe systemd uses an own impementation of mount.nfs4 and that doesn't >> support the 'sec=krb5i' option? > > No, it uses the tools from nfs-common. Ah, thanks for clarifying. But at least the post if-up.d hook from /etc/network/if-up.d/mountnfs exits without any action in case of a running systemd: # Skip the mountnfs hook when being triggered by the networking SysV init # script and instead use the systemd built-in mechanisms to mount remote # file systems. # This avoids a deadlock caused by the rpcbind SysV init script depending # on $network and the $network LSB facility being provided by the networking # SysV init script. if [ -d /run/systemd/system ]; then systemctl list-jobs | grep -q network.target && exit 0 fi >> Executing the exact ExecMount command >> line from above manually after the boot process works as expected. > > Maybe rpcbind was started too late, see bug #763315[1] on that topic. > What is the output of "systemctl status rpcbind.service"? Mh, my first impression is that the bugreport is unrelated. I don't find any systemd messages regarding ordering cycles in my dmesg. Also, rpcbind is running at least after the boot process: # systemctl status rpcbind.service ● rpcbind.service - LSB: RPC portmapper replacement Loaded: loaded (/etc/init.d/rpcbind) Drop-In: /run/systemd/generator/rpcbind.service.d └─50-rpcbind-$portmap.conf Active: active (running) since Sat 2015-06-27 10:21:10 UTC; 9min ago CGroup: /system.slice/rpcbind.service └─368 /sbin/rpcbind -w Jun 27 10:21:10 clt rpcbind[350]: Starting rpcbind daemon.... My impression is, that systemd tries to mount the NFS shares directly after the root fs is mounted. At this time it fails because the network is not setup yet. Afterwards, nothing picks up the missing NFS mounts and as a result the boot process ends without NFS shares being mounted. I don't know much about systemd and its changes to the boot process, but I suspect that (some part of) systemd is meant to mount the NFS shares once the network connection is established. Seems like that doesn't happen. /etc/init.d/mountnfs.sh doesn't do anything on systemd systems as it merely invokes /etc/network/if-up.d/mountnfs - which in turn doesn't do anything on systemd systems (see above). Cheers, jonas -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/558e7c63.4080...@freesources.org