I just upgraded Suse using zypper dup and have run into problems during boot. While the system will boot properly the boot process now takes about 15 minutes to complete. The issue is that during boot its trying to load the nfs mounts but these fail showing connection timeout (which appears to be 3 minutes each mount).
948 <notice -- Aug 23 21:50:28.454938000> service boot.apparmor donedone
949 done
950 System Boot Control: The system has been set up
951 Skipped features: boot.open-iscsi boot.cycle
952 System Boot Control: Running /etc/init.d/boot.local
953 mount.nfs: Connection timed out
954 mount.nfs: Connection timed out
955 mount.nfs: Connection timed out
956 mount.nfs: Connection timed out
957 mount.nfs: Connection timed out
958 failed
959 <notice -- Aug 23 22:05:28.760584000> killproc: kill(447,3)
This did not occur in the boot sequence before I upgraded 11.2 to 11.3. Also, interestingly the mounts are there and usable once the system boots into KDE. Is there a timing issue in the boot process now that causes this? What can I modify to avoid this hang in the boot process in the future?
Sample entry in fstab for one of these mounts is the following
baalnfs:/storage2/apps /nfs/apps nfs defaults 0 0
All the nfs mounts come from the same server (which was up and running when boot occured). My nfs server is running as a headless 11.2 command line system (will upgrade it in a week or two to 11.3 when I get my new drives for it).
Looks like you have the same problem in this thread:
openSUSE 11.3 NFS problem (hang) during boot process
There’s a reply at the end which solved this matter for my friend flark.
Thanks switching to version 3 resolved the problem of it taking 3 minutes to timeout for each share, but doesnt really fix the underlying issue in that the drives are mounted right before the network is enabled.
Also I now get other failure messages on nfs at boot, but once again doesnt impact me being able to use the drives once the system is completely loaded.
New Errors
928 mount.nfs: rpc.statd is not running but is required for remote locking.
929 mount.nfs: Either use '-o nolock' to keep locks local, or start statd.
930 mount.nfs: an incorrect mount option was specified
931 mount.nfs: rpc.statd is not running but is required for remote locking.
932 mount.nfs: Either use '-o nolock' to keep locks local, or start statd.
933 mount.nfs: an incorrect mount option was specified
934 mount.nfs: rpc.statd is not running but is required for remote locking.
935 mount.nfs: Either use '-o nolock' to keep locks local, or start statd.
936 mount.nfs: an incorrect mount option was specified
937 mount.nfs: rpc.statd is not running but is required for remote locking.
938 mount.nfs: Either use '-o nolock' to keep locks local, or start statd.
939 mount.nfs: an incorrect mount option was specified
940 mount.nfs: rpc.statd is not running but is required for remote locking.
941 mount.nfs: Either use '-o nolock' to keep locks local, or start statd.
942 mount.nfs: an incorrect mount option was specified
On 08/24/2010 04:36 PM, baaldemon wrote:
> Thanks switching to version 3 resolved the problem of it taking 3
> minutes to timeout for each share, but doesnt really fix the underlying
> issue in that the drives are mounted right before the network is
> enabled.
>
> Also I now get other failure messages on nfs at boot, but once again
> doesnt impact me being able to use the drives once the system is
> completely loaded.
Find the mount statements in /etc/init.d/nfs and have them run in the
background. On my systems, adding the & at the end of the lines below fixed the
problem:
mount -o nolock $where &
and
mount -at nfs,nfs4 > /dev/null 2>&1 &