aims team mailing list archive

[Launchpad Bug Tracker <537133@xxxxxxxxxxxxxxxxxx>]

You have been subscribed to a public bug by Jan Groenewald (jan-aims):

Binary package hint: mountall

I think I've found two bugs in mountall-2.7 related to nfsroots. This
report describes both, since working around one exposes the other.

The first bug is a dependency issue, circular and otherwise. Unless the
nfsroot is mounted with "nolock", NFS locking depends on rpc.statd,
which depends on portmap, which depends on the "local-filesystems" event
(in /etc/init/portmap.conf).  mountall will never provide this event
because it treats the rootfs as "local" even if it's networked, for the
sake of daemons that need to wait for the rootfs to be remounted rw.

The problem is that portmap.conf needs access to /etc (ro), /var/run
(rw) and /lib/init/rw (rw). A dependency on "local-filesystems"
essentially means / and /tmp. Changing the dependency to "virtual-
filesystems" would be more correct, but I'm not entirely certain that
remounting / should depend on any general *-filesystems events.

It gets messier in statd.conf, which doesn't call out any filesystem
dependencies, yet requires portmap to be running. It tries to directly
"start portmap" which fails because the mentioned filesystems aren't
writable yet. Portmap and statd will start successfully later, but not
in time to satisfy the rootfs dependency.

The second bug is when one tries to work around the above problems by
specifying "nolock" in /etc/fstab for the nfsroot. In this case we land
in mountall.c at the bottom of run_mount() where the is_remote() test
causes spawn() to be called with wait=FALSE.  spawn() then calls
nih_child_add_watch() which is supposed to eventually call back to
spawn_child_handler(), but it appears to fail to connect:

 spawn: mount -n -a -t nfs -o remount,nolock 16.1.1.2:/export/romano /
 spawn: mount / [272]
 spawn: calling nih_child_add_watch for /
 init: job_process_handler: Ignored event 1 (0) for process 272

The third line is debugging I added. If spawn_child_handler() had been
called, we would have seen an additional line:

 mount / [272] exited normally

I didn't dig into libnih to figure out why this isn't working. Rather I
changed the test on which wait=FALSE depends, since it seems like
mountall should be waiting for the rootfs. This works, see attached
patch, though it only fixes the non-ideal "nolock" case.

ProblemType: Bug
Architecture: amd64
Date: Thu Mar 11 01:18:06 2010
DistroRelease: Ubuntu 10.04
Package: mountall 2.7
ProcEnviron:
 LC_COLLATE=C
 PATH=(custom, user)
 LANG=en_US.utf8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.32-15.22-generic
SourcePackage: mountall
Uname: Linux 2.6.32-15-generic x86_64

** Affects: mountall (Ubuntu)
     Importance: Medium
         Status: Incomplete

** Affects: portmap (Ubuntu)
     Importance: Medium
     Assignee: Steve Langasek (vorlon)
         Status: Fix Released

** Affects: mountall (Ubuntu Lucid)
     Importance: Medium
         Status: Confirmed

** Affects: portmap (Ubuntu Lucid)
     Importance: Medium
     Assignee: Steve Langasek (vorlon)
         Status: Fix Released

** Affects: mountall (Ubuntu Maverick)
     Importance: Medium
         Status: Won't Fix

** Affects: portmap (Ubuntu Maverick)
     Importance: Medium
         Status: Fix Released

** Affects: mountall (Ubuntu Precise)
     Importance: Undecided
         Status: Incomplete

** Affects: portmap (Ubuntu Precise)
     Importance: Undecided
         Status: Fix Released

** Affects: mountall (Ubuntu Quantal)
     Importance: Undecided
         Status: Incomplete

** Affects: portmap (Ubuntu Quantal)
     Importance: Undecided
         Status: Fix Released

** Affects: mountall (Ubuntu Raring)
     Importance: Medium
         Status: Incomplete

** Affects: portmap (Ubuntu Raring)
     Importance: Medium
     Assignee: Steve Langasek (vorlon)
         Status: Fix Released


** Tags: amd64 apport-bug lucid patch
-- 
mountall issues with NFS root filesystem
https://bugs.launchpad.net/bugs/537133
You received this bug notification because you are a member of AIMS, which is subscribed to the bug report.