After updating to nfs-utils-1.1.1 I found that NFS shares in fstab would no longer mount at boot time. In order to get them to mount I had to first start /etc/init.d/rpc.statd first. So I added rpc.statd to the default run-level but found that it started after the NFS mount script. (And so I still have to manually mount the shares when I login). Reproducible: Always Steps to Reproduce: (Assuming one has NFS shares which are mounted a boot-up) 1. Upgrade to the new version of nfs-utils. 2. Reboot. Actual Results: The shares fail to mount due to a new dependency on rpc.statd, however adding that to the default run-level does not help alleviate the issue as it starts too late in the boot process. Expected Results: The NFS shares should be mounted.
Created attachment 139785 [details] emerge --info
works fine for me ... nfsmount needs rpc.statd
(In reply to comment #2) > works fine for me ... nfsmount needs rpc.statd Indeed, however it is not explicitly start the service or depend on it. So rpc.statd ends up starting *after* nfsmount has already tried (and failed) to mount my shares. (And so I need to wait until I have logged in to mount them).
read the init.d script, there clearly is a line that states "need rpc.statd"
I'm having the same problem here, and yes - nfsmount has a need rpc.statd in it. However, I don't run nfsmount via the default boot level, I run netmount. Which has a need nfsmount in it... but, it is still complaining about rpc.statd missing when it is run. I'll keep looking at the problem.
Sorry for the comment/reply spam - but, netmount does *not* have a need nfsmount in it, it has a use nfsmount. Manually doing /etc/init.d/nfsmount start does startup rpc.statd and mounts my nfs filesystems.
netmount does not belong in the "boot" runlevel, it goes in the "default" runlevel
Wow... I can tell it is going to be one of those days. :( I *really* apologize for the confusion. I do not run netmount in the boot level, but in the default level. I have never added or deleted anything to or from the boot level, leaving it entirely up to portage and the ebuilds to manage. I only add/delete in the default level, which is where I run netmount. The default level does not have nfs, nfsmount, or rpc.statd in it either. Nor are nfs, nfsmount, or rpc.statd in the boot level. Here's a modified output of rc-status -a from my system that did not mount the nfs fs's on the last reboot: # rc-status -a Runlevel: boot alsasound [ started ] bootmisc [ started ] checkfs [ started ] checkroot [ started ] clock [ started ] consolefont [ started ] hostname [ started ] keymaps [ started ] localmount [ started ] modules [ started ] net.lo [ started ] rmnologin [ started ] urandom [ started ] Runlevel: default acpid [ started ] apache2 [ started ] bluetooth [ started ] dbus [ started ] hald [ started ] hdparm [ started ] lm_sensors [ started ] local [ started ] mdadm [ started ] mysql [ started ] net.eth0 [ started ] netmount [ started ] ntp-client [ started ] ntpd [ started ] portmap [ started ] smartd [ started ] sshd [ started ] syslog-ng [ started ] vixie-cron [ started ] xdm [ started ] Runlevel: nonetwork local [ started ] Runlevel: single Runlevel: UNASSIGNED atieventsd [ stopped ] consolekit [ stopped ] crypto-loop [ stopped ] device-mapper [ stopped ] dmeventd [ stopped ] dnsextd [ stopped ] fancontrol [ stopped ] gpm [ stopped ] irexec [ stopped ] lcdproc [ stopped ] lircd [ stopped ] lircmd [ stopped ] lisa [ stopped ] mDNSResponderPosix [ stopped ] mdnsd [ stopped ] mdraid [ stopped ] mysqlmanager [ stopped ] nfs [ stopped ] nfsmount [ stopped ] nscd [ stopped ] numlock [ stopped ] pwcheck [ stopped ] reslisa [ stopped ] rpc.idmapd [ stopped ] rpc.statd [ started ] rsyncd [ stopped ] saslauthd [ stopped ] udev-postmount [ started ] # You can see that I manually started rpc.statd as it is in the UNASSIGNED level, but started. Again, I'm sorry for the confusing information. I rebooted this particular system last night, and this morning I finally realized that it had not mounted it's /mnt/nfs_portage directory from my file server. (/etc/make.profile points into there, and an 'emerge -pDuv world' then led me on to looking at the problem).
so you arent using nfsmount ... this isnt a bug in nfs-utils, but netmount not pulling in rpc.statd properly the fact that newer nfs-utils checks for rpc.statd running before attempting a mount is a bug fix ... which made us find a bug in baselayout's netmount you're using baselayout-1 here so can you pop open /etc/init.d/netmount, find the line that looks like: if [[ -n ${nfs_mounts} ]] ; then myneed="${myneed} portmap" and add "rpc.statd" to that list ? so it looks like: myneed="${myneed} portmap rpc.statd" then run: /etc/init.d/netmount ineed the output should include rpc.statd as well as portmap if things look good, please reboot and make sure things startup properly again
(In reply to comment #9) > so you arent using nfsmount ... this isnt a bug in nfs-utils, but netmount not > pulling in rpc.statd properly Exactly correct. ... > then run: > /etc/init.d/netmount ineed My first go with this, I got: # /etc/init.d/netmount ineed * Caching service dependencies ... /var/lib/init.d/depcache: line 2300: config: command not found /var/lib/init.d/depcache: line 2351: config: command not found [ ok ] net portmap rpc.statd # /etc/init.d/netmount ineed net portmap rpc.statd The second time through, it worked without complaint. > > the output should include rpc.statd as well as portmap > > if things look good, please reboot and make sure things startup properly again > I rebooted, and the nfs mounted filesystems are present, just as they should be. Thanks for fixing this. Good work!
the config warning is harmless, you can simply ignore it ive added the rpc.statd fix to svn for next baselayout ... thanks for testing
