nfs mounts in fstab block boot at "S or M" prompt

[bwalex]

Binary package hint: mountall

I have the following two lines in fstab:
nasi.local:/secure/alex /home/alex/secure nfs defaults,rw,exec,user,nobootwait 0 0
nasi.local:/data /home/alex/data nfs defaults,rw,exec,user,nobootwait 0 0

On every boot I get prompted with the famous "S or M" prompt to manually mount or skip the mounting. The shares themselves ARE always available. Skipping doesn't work for other reasons (see [1]), nobootwait doesn't work for even other reasons ([2]). The only way to get the system to boot is to manually fix the issue by pressing "M" and then starting dhclient manually:
# dhclient -v eth1
After that the boot can continue by simply exiting the emergency shell. This is clearly an issue with nfs mounts being tried before setting up the network, or at least running dynamic network configuration (i.e. DHCP).

Also note that this happens reliably on every boot, so a race is unlikely. I also don't have /var as a separate mountpoint.

Just for completeness sake, my complete fstab:
% cat /etc/fstab | grep -v ^#
proc /proc proc nodev,noexec,nosuid 0 0
UUID=e278f6aa-8fba-47be-880b-53bbce04a9d8 / ext4 errors=remount-ro 0 1
UUID=c842351a-aa7c-478a-a58f-f671ca6e6858 /extra ext4 defaults 0 2
UUID=79f60f9a-a507-41d7-b00b-c831bd3ba892 /opt ext4 defaults 0 2
UUID=373f64a7-04d0-4d21-94dc-8b08c3fef2b9 none swap sw 0 0

nasi.local:/secure/alex /home/alex/secure nfs defaults,rw,exec,user,nobootwait 0 0
nasi.local:/data /home/alex/data nfs defaults,rw,exec,user,nobootwait 0 0
UUID=3a094e37-2689-435d-8a00-447274664320 /home ext4 defaults,user_xattr 0 2

And for even more completeness, the /etc/exports on the server (debian squeeze):
/data 192.168.0.0/24(rw,no_subtree_check,async,no_root_squash) 192.168.2.0/24(rw,no_subtree_check,async,no_root_squash) 10.0.1.0/24(rw,no_subtree_check,async,no_root_squash)
/secure/alex 192.168.0.0/24(rw,no_subtree_check,no_root_squash) 192.168.2.0/24(rw,no_subtree_check,no_root_squash) 10.0.1.0/24(rw,no_subtree_check,no_root_squash)

Kind Regards,
Alex

[1]: https://bugs.launchpad.net/ubuntu/+source/mountall/+bug/655616
[2]: https://bugs.launchpad.net/ubuntu/+source/mountall/+bug/759450

ProblemType: Bug
DistroRelease: Ubuntu 11.04
Package: mountall 2.25
ProcVersionSignature: Ubuntu 2.6.38-8.42-generic 2.6.38.2
Uname: Linux 2.6.38-8-generic x86_64
NonfreeKernelModules: nvidia
Architecture: amd64
Date: Tue Apr 19 06:58:49 2011
ProcEnviron:
 LANGUAGE=en_GB:en
 PATH=(custom, user)
 LANG=en_GB.UTF-8
 SHELL=/bin/zsh
SourcePackage: mountall
UpgradeStatus: No upgrade log present (probably fresh install)

[Clint Byrum (clint-fewbar)]

bwalex, thanks for opening the new report per our discussion.

The title is *exactly* the same as the other, implying that this is the same bug.

It seems to me that your bug involves NFS mounts that *block* the boot, whereas Barry was just reporting the failure messages, but his boot was not blocked.

As such I've changed the title to more accurately reflect what is going on.

[Clint Byrum (clint-fewbar)]

On testing this in a Natty VM, I was able to reproduce with this fstab:

proc /proc proc nodev,noexec,nosuid 0 0
# / was on /dev/vda1 during installation
UUID=9d2fb77a-7e3f-42f5-94ec-d8d37c46c56d / ext3 errors=remount-ro 0 1
# swap was on /dev/vda5 during installation
UUID=f35bf0c3-5263-4225-9a33-f8ffdf0fc0ce none swap sw 0 0
clint-MacBookPro:/home/clint /mnt/test/clint nfs defaults,rw,exec,user,nobootwait 0 0
/test.fs /mnt/test ext4 defaults,user_xattr,loop 0 2

The issue seems to be in the name resolution. If I replace 'clint-MacBookPro' (the name of my vm host) with an IP, or something in /etc/hosts, I get no waiting at the S or M prompt.

Marking Confirmed, setting importance to High since this interrupts remote server rebooting.

[bwalex (ahornung)]

Clint, thanks for showing interest in this, much appreciated. It is really annoying when the system doesn't boot without user intervention :)

It wasn't my intention to use the same title, actually; was more of a coincidence/happy accident. New title sounds just fine.

Thanks,
Alex

[bwalex (ahornung)]

Actually, turns out that I still have the same problem using IPs instead of hostnames. I'm using these entries now:
192.168.0.70:/secure/alex /home/alex/secure nfs defaults,rw,exec,user,nobootwait 0 0
192.168.0.70:/data /home/alex/data nfs defaults,rw,exec,user,nobootwait 0 0

and the boot just prompted me again for the usual "S or M" input. Just for reference:
% nslookup nasi.local
Server: 192.168.0.1
Address: 192.168.0.1#53

Name: nasi.local
Address: 192.168.0.70

[bwalex (ahornung)]

Turns out this last issue is because Ubuntu doesn't set the interface to auto and dhcp in /etc/network/interfaces anymore. It must have been the case in the past, because all of this originally worked without modifying the aforementioned file. In any case, adding
auto eth0
iface eth0 inet dhcp

fixes the IP issue at least.

Regards,
Alex

[Steve Langasek (vorlon)]

bwalex, is this issue still reproducible in 12.04 if using hostnames in /etc/fstab? I've been using hostnames forever for my nfs mounts, and have never seen these problems at boot.

[Launchpad Janitor (janitor)]

[Expired for mountall (Ubuntu) because there has been no activity for 60 days.]