Ubuntu
network-manager package

Mountall fails to mount NFS partitions on boot with GigE network managed by NM

Bug #1226766 reported by Joseph Yasi on 2013-09-17

24

This bug affects 5 people

Affects		Status	Importance	Assigned to	Milestone
	network-manager (Ubuntu)	Confirmed	Undecided	Unassigned

Bug Description

NFS partitions fail to mount on boot, and mountall freezes without mounting them. If I revert this change to the init script:
     . /etc/default/rcS || true
     [ -f /forcefsck ] && force_fsck="--force-fsck"
     [ "$FSCKFIX" = "yes" ] && fsck_fix="--fsck-fix"

+ # Doesn't work so well if mountall is responsible for mounting /proc, heh.
+ if [ -e /proc/cmdline ]; then
+ for arg in $(cat /proc/cmdline); do
+ case $arg in
+ -q|--quiet|-v|--verbose|--debug)
+ debug_arg=$arg
+ ;;
+ esac
+ done
+ fi
     # set $LANG so that messages appearing in plymouth are translated
     if [ -r /etc/default/locale ]; then
         . /etc/default/locale || true
         export LANG LANGUAGE LC_MESSAGES LC_ALL
     fi

- exec mountall --daemon $force_fsck $fsck_fix
+ exec mountall --daemon $force_fsck $fsck_fix $debug_arg
end script

it works. It seems strange that this would stop NFS from mounting on boot. It appears that the NFS mounts are occurring before DNS is up. mountall.log contains:
mount.nfs: Failed to resolve server rt-ac66u: Name or service not known
mountall: mount /mnt/readyshare [815] terminated with status 32
Filesystem could not be mounted: /mnt/readyshare
mountall: Disconnected from Plymouth

ProblemType: Bug
DistroRelease: Ubuntu 13.10
Package: mountall 2.51
Uname: Linux 3.11.1-customatom x86_64
NonfreeKernelModules: nvidia
.run.mount.utab:

ApportVersion: 2.12.1-0ubuntu4
Architecture: amd64
Date: Tue Sep 17 14:49:53 2013
ExecutablePath: /sbin/mountall
InstallationDate: Installed on 2012-04-15 (520 days ago)
InstallationMedia: Mythbuntu 12.04 "Precise Pangolin" - Beta amd64 (20120328)
MarkForUpload: True
ProcEnviron:
TERM=linux
PATH=(custom, no user)
LANG=en_US.UTF-8
ProcKernelCmdline: BOOT_IMAGE=/boot/vmlinuz-3.11.1-customatom root=UUID=708b3ba8-c42a-4adf-a195-c0fb8d8f8dd3 ro --verbose
SourcePackage: mountall
UpgradeStatus: Upgraded to saucy on 2013-06-28 (81 days ago)

Tags:

Revision history for this message

Joseph Yasi (joe-yasi) wrote on 2013-09-17:

#1

.etc.fstab.txt Edit (1.1 KiB, text/plain; charset="utf-8")
.etc.mtab.txt Edit (879 bytes, text/plain; charset="utf-8")
.var.log.boot.log.txt Edit (3.6 KiB, text/plain; charset="utf-8")
.var.log.upstart.mountall.log.txt Edit (6.7 KiB, text/plain; charset="utf-8")
Dependencies.txt Edit (2.7 KiB, text/plain; charset="utf-8")
Mounts.txt Edit (981 bytes, text/plain; charset="utf-8")
ProcMaps.txt Edit (5.8 KiB, text/plain; charset="utf-8")
ProcMounts.txt Edit (1.1 KiB, text/plain; charset="utf-8")
ProcSelfMountinfo.txt Edit (1.3 KiB, text/plain; charset="utf-8")
ProcStatus.txt Edit (716 bytes, text/plain; charset="utf-8")

Revision history for this message

Joseph Yasi (joe-yasi) wrote on 2013-09-17:

#2

mountall.log with --verbose passed. Edit (4.7 KiB, text/plain)

Here is the mountall.log requested in bug #1217610

Revision history for this message

Joseph Yasi (joe-yasi) wrote on 2013-09-17:

#3

It's not just DNS. I changed the /etc/fstab entry to the IP address instead of the hostname, and it still fails to mount with: mount.nfs: mount system call failed
mountall: mount /mnt/readyshare [811] terminated with status 32
mountall: Disconnected from Plymouth

It must be racing the network stack to come up.

Revision history for this message

Steve Langasek (vorlon) wrote on 2013-09-17: Re: [Bug 1226766] Re: Mountall fails to mount NFS partitions on boot

#4

On Tue, Sep 17, 2013 at 06:59:37PM -0000, Joseph Yasi wrote:
> It's not just DNS. I changed the /etc/fstab entry to the IP address instead of the hostname, and it still fails to mount with: mount.nfs: mount system call failed
> mountall: mount /mnt/readyshare [811] terminated with status 32
> mountall: Disconnected from Plymouth

> It must be racing the network stack to come up.

Yes, that seems to be the case. Can you post the details of your network
configuration?

Also, can you reproduce this issue and then run 'killall -USR1 mountall'?
This should trigger mountall to retry all pending network mounts. I want to
rule out the possibility that the recent mountall changed introduced a
deeper problem with the mount handling. (The race-the-network problem has
been reported before, so while it's new for you, it's not a new bug.)

Revision history for this message

Joseph Yasi (joe-yasi) wrote on 2013-09-17: Re: Mountall fails to mount NFS partitions on boot

#5

Okay, sending SIGUSR1 after booting does bring up the NFS mounts.

The network configuration is just gigabit ethernet on eth0 configured via DHCP through NetworkManager as a system connection.

Revision history for this message

Steve Langasek (vorlon) wrote on 2013-09-17:

#6

Ok. Can you confirm that 'sudo status network-interface INTERFACE=eth0' shows the interface as 'running'?

If so, then I think this needs to be triaged over to NetworkManager as a bug with NM invoking the ifupdown hook scripts too early.

summary:

- Mountall fails to mount NFS partitions on boot
+ Mountall fails to mount NFS partitions on boot with GigE network managed
+ by NM

Revision history for this message

Joseph Yasi (joe-yasi) wrote on 2013-09-17:

#7

sudo status network-interface INTERFACE=eth0
network-interface (eth0) start/running

Yes. It shows as running.

Revision history for this message

Steve Langasek (vorlon) wrote on 2013-09-18:

#8

Thanks for confirming. Reassigning to network-manager.
network-manager needs to not call the ifupdown hooks before the interface is genuinely *up* and ready to start delivering packets.

affects:

mountall (Ubuntu) → network-manager (Ubuntu)

Revision history for this message

Launchpad Janitor (janitor) wrote on 2013-10-07:

#9

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in network-manager (Ubuntu):
status:	New → Confirmed

Revision history for this message

Ted Collins (collins-ted) wrote on 2013-12-28:

#10

Not to pile on here . . . but i have three servers 13.04 at Rackspace (admittedly, I cannot be certain that the actual hardware is anything like identical -- but I have configured them side-by-side, and their installation is identical). Two of the three servers can handle two (2) NFS mounts in the /etc/fstab during boot. The third one can only handle one (1). It appears that which one is unimportant, since I can swap the mounts around, reconfigure them, etc. But if there are two in the /etc/fstab for the one server, it sticks at "disconnected from Plymouth."

My solution was to put the "most important" nfs mount in the /etc/fstab, and to put others in /etc/rc2.d. But that's me. This certainly *seems* to be a race condition, but I cannot offer anything more than my opinion on that. Perhaps this extra observation helps, or perhaps you can ignore it.

Revision history for this message

Joseph Yasi (joe-yasi) wrote on 2014-01-11:

#11

I've just started seeing this again after upgrading to trusty. This time sending SIGUSR1 does not work. The mount.nfs process appears hung on boot. Killing this process, and then sending SIGUSR1 to mountall results in the partition mounting.

Revision history for this message

Joseph Yasi (joe-yasi) wrote on 2014-09-19:

#12

mountall.log Edit (4.1 KiB, text/plain)

I upgraded to Utopic and this problem got worse on that machine. I've attached the new mountall.log.

The fstab line for the mount is now:
rt-ac66u:/tmp/mnt/yasimedia /mnt/readyshare nfs _netdev,hard,intr,exec,nodev,nosuid,async,nobootwait 0 0

It looks like it's not detecting the mount as a remote share. The log says /mnt/readyshare is nowait. My workaround for this was sending a SIGUSR1 to mountall in rc.local, but that's not working anymore. It does not mount the NFS mount. A manual /mnt/readyshare works.

Report a bug

This report contains Public information

Everyone can see this information.

You are

Subscribing...

Edit bug mail

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.