Linux Mint Forums

I have a nfs client machine that I upgraded to UP5 last night. After the upgrade I did a reboot. The reboot bogged down when it got to the point of loading nfs related things. The boot process would simply hang for a couple of minutes, give a nfs timeout message and the continue loading. Uniquely, my share does get mounted even though mount.nfs timed out after 2 minutes.

I edited /etc/fstab and commented out a nfs share that mounted at bootup. After that my bootups have been successful, and without a 2 minute lag but it leaves me without my nfs share mounted. I can mount the share manually.

I am just wondering if anyone else has had this problem relating to a nfs client machine and nfs-common when upgrading to UP5. ????

I upgraded my nfs server machine previously and that happened without any difficulty.

I got back to the box I am having problems with. I completely removed both nfs-common and rpcbind and reinstalled them but I still get the same hangup behavior.

I simply can not figure out the cause of this hangup during bootup where I end up with a mount.nfs timeout message. My fstab entry is the same it's been for several years. Actually, everything is the same .... except I am getting this several minute lag in bootup now since updating to UP5.

I am just looking at this now as I have exactly the same problem here, the NFS mounts is fstab aren't working and you have to wait for them to timeout before it continues, so I have commented them out in fstab for now, if I try sudo mount.nfs from terminal it works, so I think maybe some syntax or options have changed this is my current fstab nfs stuff which I have been using for years

192.168.1.1:/net/backups /net/backups nfs rsize=8192,wsize=8192,timeo=14,intr,noatime 0 0
192.168.1.1:/net/public /net/public nfs rsize=8192,wsize=8192,timeo=14,intr,noatime 0 0
192.168.1.1:/net/support /net/support nfs rsize=8192,wsize=8192,timeo=14,intr,noatime 0 0

(this is still working fine on my Mint 13 PC)

I will report back if I discover anything

GB

not getting very far, found a couple of articles seemingly reporting it as a bug in Debian but I can't believe they haven't fixed it, there was also a mention of Virtualbox doing something and I have it installed so I updated it to the latest version and disabled all the interfaces on the VMs but still the same, I think the only way to find out is to reinstall LMDE-2012-04 and put UP5 on with no extra packages installed to see if that works, so may try that on my test PC first.

Meanwhile I have got it working as a bodge by commenting them out in fstab and adding the following 3 lines to /etc/rc.local

mount.nfs 192.168.1.1:/net/backups /net/backups
mount.nfs 192.168.1.1:/net/public /net/public
mount.nfs 192.168.1.1:/net/support /net/support

will report back on the reinstall when I get around to it

GB

ginjabunny I am starting to wonder if mount.nfs is happening prior to network connection being established. I've tried just about everything I can think of with both nfsv3 and nfsv4. I always get the timeout problem but I always end up with the share being mounted anyhow. Like you, it's only a problem with LMDE and only with LMDE that's been updated to UP5. I am using MATE DE.

I just did a fresh install and put on UP5, does the same thing and yes it does actually mount them but I can't wait 6 minutes at every boot

I'm going to have a dig around in the script to see if I can spot anything..

Hi,

I'm having the exact same bug on my LMDE desktop, so I filed a bug on Launchpad:
https://bugs.launchpad.net/linuxmint/+bug/1054761

Feel free to add details to it !

is this relevant here http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=673936

zerozero wrote:is this relevant here http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=673936

Yup, that at least describes the timeout behavior of nfs.

As soon as the machine with this problem comes open I am going to attempt what was offered as a temporary fix:

So as we've found out, the problem is caused by mountnfs script not
expecting --all. This can be temporarily fixed by adding this:

{{{{ SUGGESTED TEMPORARY FIX REMOVED FROM THIS POST. IT DOESN'T WORK PROPERLY ]]]]

Thanks for the clue in zerozero.

I tried the
code hack mentioned in the post above. While it DOES eliminate the false timeout problem it also IS NOT mounting my share from /etc/fstab. When I comment the line back out in /etc/network/if-up.d/mountnfs and reboot I DO get the timeout problem again but my share DOES mount.

If I can get a couple of members to verify this behavior I will probably just eliminate the code hack in the post above.

I can verify that, the timeout issue goes away but they do not get mounted, so it's not a fix.

I may have a look in Debian unstable, see what's going on over there, if I get time..

ginjabunny wrote:I can verify that, the timeout issue goes away but they do not get mounted, so it's not a fix.

I may have a look in Debian unstable, see what's going on over there, if I get time..

Okay and thanks for verifying the fix not being a fix. I am also continuing to investigate. I also went to nabnut's launchpad link that's listed in a prior post and put in a blurp about experiencing the same problems he's having so they'll know it's not an isolated situation.

got bored, UP5 screwed up a few things, have put Mint 13 on instead

ginjabunny wrote:got bored, UP5 screwed up a few things, have put Mint 13 on instead

Same problem here, timeout during boot but NFS shares all mounted once it was up and running.

The fix for me was to look at the output of 'mount' in a terminal and then compare the settings to what I had in /etc/fstab.

The old options were:
Which I replaced with the options below:
I still see a message during bootup saying 'Network cannot be reached' or so, but it boots fast and all my NFS shares get mounted.

I can live with that small issue for now

Pigsy wrote:Same problem here, timeout during boot but NFS shares all mounted once it was up and running.

The fix for me was to look at the output of 'mount' in a terminal and then compare the settings to what I had in /etc/fstab.
<<<----snipped---->>>

Which I replaced with the options below:

Code: Select all

192.168.0.155:/homes/pigsy /mnt/pigsy nfs rw,relatime,vers=3,rsize=32768,wsize=32768,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.0.155,mountvers=3,mountport=50241,mountproto=udp,local_lock=none,addr=192.168.0.155

Thanks Pigsy.

My problem machine is a production machine and I won't have access to it until later on to test this. I am itching to test to see exactly what portion of all the "mount info' is actually needed in the fstab entry to make it work as you indicate it is. I am mostly wondering if it's mountaddr=192.168.0.155 or addr=192.168.0.155, both, a combination of them and other things or if all you've mentioned is required.

Fortunately, we do have the option of what you've just provided, the rc.local mounting routine and manual mounting to access our shares. We'd be in the hurts if we couldn't do that.

It would be nice though to expose the actual culprit that's creating the problem so we can fix that. I still consider ifupdown.

Actually I'm pretty sure too that ifup is the culprit. I tried booting in single user mode where I thought the problem would not happen, or it did happen too...
so I had a look in the boot scripts directory and saw the following line in /etc/rcS.d/S15networking :
So after that I tried to study the ifup -a command behavior, which for me should bring up all the configured network interfaces. I was surprised to see that:
1/ it does not bring my main network interface eth0 up (ifconfig shows me only the loopback interface),
2/ it also triggers the mount.nfs commands... which times out because there is no network !

In fact the nfs mount is part of the ifup configuration...
Another thing that bugs me is the contents of the /etc/network/interfaces file :
Assuming that it's NetworkManager's role to bring eth0 up, what is the goal of the ifup boot script ? maybe I'm on the wrong track here...

[quote="nabnut"
Assuming that it's NetworkManager's role to bring eth0 up, what is the goal of the ifup boot script ? maybe I'm on the wrong track here...[/quote]

At the moment I am not sure what's the right or wrong track. Unfortunately, I may have another little addition to this problem. We took down the machine with the NSF server for a while last night. At the time we took it offline the UP5 machine with the NSF problem was online and connected to the share. Later, the machine was powered down prior to the NSF server being brought back online. Well ... power down did not happen for a very long time because mountnfs could not find the nfs server and after a long while I got a message saying that and that it was trying again. After a long while of this I got tired of it and hit the power switch. I guess the share should have been unmounted in the client prior to server shutdown but for the client to take a millennium to shut down because it didn't happen that way is baffling.

I think I am maybe to the point where I am just going to let NFS go until 'whatever' is fixed so it works properly. We should not have to be doing workarounds to get NFS working correctly. Also, this is not an isolated problem. Everyone that has UP5 and is running NFS seems to have it. That makes it a critical problem and should have been resolved with an update of whatever's haywire by now. I am kind of irked with all this at the moment.

Meanwhile, this just sits: https://bugs.launchpad.net/linuxmint/+bug/1054761

All I have is one box that shares one distinct folder with several other boxes. Anyone know of something's that simple and clean to set up, will do the task properly and is debian/mint supported?

Hi Trapper, sorry for the late answer, been busy with a few things...

I already encountered this "shutdown hangup" phenomenon several times on RHEL5 servers at work, so I'm not sure it's only Debian or Mint related.
Usually I get bored waiting so I end up physically powering off the machine.

For me, NFS (whether it's v3 or v4) has two major defaults, first it's hard to find the right configuration options : you have to tweak the server's configuration, the exports options AND the mount options on client side too. Then, once it's finally working, you have to cross your fingers and hope that nothing will go wrong on the server or network side... else it's often a mess to get things back up on the clients. Just to be sure, do you use soft or hard NFS mounting option ?

Regarding an NFS replacement solution, have you considered a samba server, using mount.cifs on the clients ?
Or you may have a look at SSHFS (which I just discovered while searching for info on CIFS )

I can't take credit for this but I found a post that indicated Network Manager having some effect on this problem. I made this change and NFS mounts perfectly. I started having the problem when ifupdown and netbase was upgraded. I downgraded these packages until I found a solution.

Edit /etc/network/if-up.d/mountnfs


Edit this line
[ "$ADDRFAM" = "inet" ] || [ "$ADDRFAM" = "inet6" ] || exit 0

To this
[ "$ADDRFAM" = "inet" ] || [ "$ADDRFAM" = "inet6" ] || [ "$ADDRFAM" = "NetworkManager" ] || exit 0