Bug#433119: nfs-common: NFS volume no longer mounted on boot
Frans Pop
> On Sat, Jul 14, 2007 at 04:53:54PM +0200, Frans Pop wrote:
> > Since the upgrade from 1:1.1.0-6, my system no longer mounts an NFS
> > volume listed in my /etc/fstab during system boot (I did no other
> > relevant upgrades that day). It mounts without any problems if I just
> > give the mount command manually after the boot has completed.
>
> Duplicate of #432511 and #432750, merging. FWIW, the issue is that the
> new mount requires statd to be running, and initscripts doesn't do that
> yet.
Shouldn't the relevant change be delayed until initscripts _does_ support
this then? And after that nfs-common should be given a proper versioned
dependency before activating the change?
Please revert this breakage! just Passing it off to initscripts does not
seem like the right solution here.
Steinar H. Gunderson
> I'm not all that interested in what the right long-term fix is, I'm
> concerned about a change in nfs-common breaking something semi essential
> that has worked for ages, accidentally or not.
I'm a bit unsure why this suddenly started going to debian-devel; I'm Cc-ing
the bug again, at least.
> If something like that is reported, IMHO the only correct course of action
> is first to make sure that the breakage is fixed, and then to start
> talking with maintainers of other involved packages about the correct
> structural fix and migration path, and only implementing your own change
> again _after_ other packages have made the necessary modifications.
The question here is: When initscripts is broken, and a new version of
nfs-common exposes that breakage, what is the right course of action? I'd say
it is to fix initscripts. Note that this is not a simple code change in
nfs-utils; it is a major move of functionality from one code base
(util-linux) to a different one (nfs-utils).
Try this patch:
diff -u sysvinit-2.86.ds1/debian/initscripts/etc/network/if-up.d/mountnfs sysvinit-2.86.ds1/debian/initscripts/etc/network/if-up.d/mountnfs
--- sysvinit-2.86.ds1/debian/initscripts/etc/network/if-up.d/mountnfs
+++ sysvinit-2.86.ds1/debian/initscripts/etc/network/if-up.d/mountnfs
@@ -27,10 +27,9 @@
exec 9<&0 </etc/fstab
- portmap=no
+ start_nfs=no
NETFS=""
NETDEV=""
- gss_or_idmap=no
while read DEV MTPT FSTYPE OPTS REST
do
case "$DEV" in
@@ -48,18 +47,7 @@
esac
case "$FSTYPE" in
nfs|nfs4)
- case "$OPTS" in
- nolock|*,nolock|nolock,*|*,nolock,*)
- ;;
- *)
- portmap=yes
- ;;
- esac
- case "$OPTS" in
- sec=krb5|*,sec=krb5|sec=krb5,*|*,sec=krb5i,*|sec=krb5i|*,sec=krb5i|sec=krb5i,*|*,sec=krb5i,*|sec=krb5p|*,sec=krb5p|sec=krb5p,*|*,sec=krb5p,*)
- gss_or_idmap=yes
- ;;
- esac
+ start_nfs=yes
;;
smbfs|cifs|coda|ncp|ncpfs|ocfs2|gfs)
;;
@@ -77,39 +65,16 @@
;;
esac
fi
- if [ "$FSTYPE" = "nfs4" ]
- then
- gss_or_idmap=yes
- fi
done
exec 0<&9 9<&-
#
- # With contemporary portmap packages it is no longer necessary
- # to start portmap here because the package has its own initscript.
- # This code will disappear after etch.
- #
- if [ "$portmap" = yes ]
- then
- if [ -x /sbin/portmap ] && ! pidof portmap >/dev/null 2>&1
- then
- if [ -x /etc/init.d/portmap ]
- then
- /etc/init.d/portmap start
- else
- start-stop-daemon --start --quiet --oknodo --exec /sbin/portmap
- sleep 1 # FIXME: Actually synchronize with the process?
- fi
- fi
- fi
-
- #
- # Initialize nfs-common (which starts rpc.gssd and/or
- # rpc.idmapd, and loads the right kernel modules if
+ # Initialize nfs-common (which starts rpc.statd, rpc.gssd
+ # and/or rpc.idmapd, and loads the right kernel modules if
# applicable) if we use Kerberos and/or NFSv4 mounts.
#
- if [ "$gss_or_idmap" = yes ] && [ -x /etc/init.d/nfs-common ]
+ if [ "$start_nfs" = yes ] && [ -x /etc/init.d/nfs-common ]
then
/etc/init.d/nfs-common start
fi
/* Steinar */
--
Homepage: http://www.sesse.net/
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Frans Pop
> I'm a bit unsure why this suddenly started going to debian-devel; I'm
> Cc-ing the bug again, at least.
Because I CCed it there, but you only replied to d-devel :-)
> The question here is: When initscripts is broken, and a new version of
> nfs-common exposes that breakage, what is the right course of action?
> I'd say it is to fix initscripts. Note that this is not a simple code
> change in nfs-utils; it is a major move of functionality from one code
> base (util-linux) to a different one (nfs-utils).
The right cause of action should at least include preventing the breakage
from migrating to testing! After all, testing is supposed to be a usable
distribution. Suddenly losing all you NFS mounts on reboots after a
routine package upgrade is IMO a serious regression.
Which means that ATM an RC bug against nfs-common should be present as
nothing else will prevent its migration. (Possibly blocked by the bugs
against initscripts.)
> Try this patch:
The patch works for me. Thanks.
Steinar H. Gunderson
thanks
On Sat, Jul 14, 2007 at 07:40:13PM +0200, Frans Pop wrote:
>> I'm a bit unsure why this suddenly started going to debian-devel; I'm
>> Cc-ing the bug again, at least.
> Because I CCed it there, but you only replied to d-devel :-)
OK, my bad.
>> Try this patch:
> The patch works for me. Thanks.
Good. initscript maintainers: I intend to NMU with this patch (and this patch
alone, except for changelog changes), as per the standard NMU policy with a
week's delay. Please let me know if you have any objections.
Frans Pop
reassign -1 nfs-common 1:1.1.0-8
block -1 with 433119
tags -1 - patch
severity -1 grave
thanks
On Saturday 14 July 2007 20:09, Steinar H. Gunderson wrote:
> Good. initscript maintainers: I intend to NMU with this patch (and this
> patch alone, except for changelog changes), as per the standard NMU
> policy with a week's delay. Please let me know if you have any
> objections.
In that case we still need to block nfs-common from migrating. From these
comments on #d-devel below it would seem that RM agrees that this is an
RC issue:
<fjp> vorlon: Any opinion on #433119? As it is now, this would affect
testing too as soon as nfs-utils is old enough.
<vorlon> fjp: get the release team to block the package until sysvinit is
fixed?
This cloned bug is also a reminder to set an appropriate versioned
dependency on initscripts in nfs-common.
Thanks for the quick responses,
FJP
Elimar Riesebieter
Steinar H. Gunderson told:
> On Sat, Jul 14, 2007 at 06:17:13PM +0200, Frans Pop wrote:
> > I'm not all that interested in what the right long-term fix is, I'm
> > concerned about a change in nfs-common breaking something semi essential
> > that has worked for ages, accidentally or not.
>
> I'm a bit unsure why this suddenly started going to debian-devel; I'm Cc-ing
> the bug again, at least.
>
> > If something like that is reported, IMHO the only correct course of action
> > is first to make sure that the breakage is fixed, and then to start
> > talking with maintainers of other involved packages about the correct
> > structural fix and migration path, and only implementing your own change
> > again _after_ other packages have made the necessary modifications.
>
> The question here is: When initscripts is broken, and a new version of
> nfs-common exposes that breakage, what is the right course of action? I'd say
> it is to fix initscripts. Note that this is not a simple code change in
> nfs-utils; it is a major move of functionality from one code base
> (util-linux) to a different one (nfs-utils).
>
> Try this patch:
Doesn't work in addition to nfs-common 1.1.0-9.
Elimar
--
Excellent day for drinking heavily.
Spike the office water cooler;-)
Steinar H. Gunderson
> Doesn't work in addition to nfs-common 1.1.0-9.
What does your fstab look like? What messages do you get during boot?
(I'm taking this off debian-devel from here on; it doesn't make sense to keep
debugging there.)
/* Steinar */
--
Homepage: http://www.sesse.net/
Steinar H. Gunderson
> rpc.statd is not running but is required for remote locking
> Either use "-o nolocks" to keep locks local, or start statd.
>
> --- mountnfs.orig 2007-07-13 12:01:18.000000000 +0200
> +++ mountnfs 2007-07-15 13:38:21.000000000 +0200
> @@ -109,7 +109,7 @@
> # rpc.idmapd, and loads the right kernel modules if
> #
> - if [ "$gss_or_idmap" = yes ] && [ -x /etc/init.d/nfs-common ]
> then
> /etc/init.d/nfs-common start
> fi
>
> works.
Well, we can't start it unconditionally. With my patch applied, could you
please add an "echo $start_nfs" before the if, and report the output? I'm
wondering if nfs-common refuses to start due to portmap, or if something else
is going on.
/* Steinar */
--
Homepage: http://www.sesse.net/
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
Elimar Riesebieter
Steinar H. Gunderson told:
> On Sun, Jul 15, 2007 at 01:28:32PM +0200, Elimar Riesebieter wrote:
> > Doesn't work in addition to nfs-common 1.1.0-9.
>
> What does your fstab look like? What messages do you get during boot?
fstab:
baumbart:/exp/archiv /archiv nfs rw,nfsvers=3,rsize=32768,wsize=32768,timeo=14,hard,intr 0 0
bootmsg:
rpc.statd is not running but is required for remote locking
Either use "-o nolocks" to keep locks local, or start statd.
--- mountnfs.orig 2007-07-13 12:01:18.000000000 +0200
+++ mountnfs 2007-07-15 13:38:21.000000000 +0200
@@ -109,7 +109,7 @@
# rpc.idmapd, and loads the right kernel modules if
# applicable) if we use Kerberos and/or NFSv4 mounts.
#
- if [ "$gss_or_idmap" = yes ] && [ -x /etc/init.d/nfs-common ]
+ if [ -x /etc/init.d/nfs-common ]
then
/etc/init.d/nfs-common start
fi
works.
Elimar
--
Numeric stability is probably not all that
important when you're guessing;-)
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
Elimar Riesebieter
Steinar H. Gunderson told:
> On Sun, Jul 15, 2007 at 02:06:21PM +0200, Elimar Riesebieter wrote:
> > rpc.statd is not running but is required for remote locking
> > Either use "-o nolocks" to keep locks local, or start statd.
> >
> > --- mountnfs.orig 2007-07-13 12:01:18.000000000 +0200
> > +++ mountnfs 2007-07-15 13:38:21.000000000 +0200
> > @@ -109,7 +109,7 @@
> > # rpc.idmapd, and loads the right kernel modules if
> > # applicable) if we use Kerberos and/or NFSv4 mounts.
> > #
> > - if [ "$gss_or_idmap" = yes ] && [ -x /etc/init.d/nfs-common ]
> > + if [ -x /etc/init.d/nfs-common ]
> > then
> > /etc/init.d/nfs-common start
> > fi
> >
> > works.
>
> Well, we can't start it unconditionally. With my patch applied, could you
> please add an "echo $start_nfs" before the if, and report the output? I'm
> wondering if nfs-common refuses to start due to portmap, or if something else
> is going on.
.....
DHCPACK from 192.168.200.1
bound to 192.168.200.202 -- renewal in 12327 seconds.
yes
Starting NFS common utilities: statd.
mount.nfs: rpc.statd is not running but is required for remote locking
Either use "-o nolocks" to keep locks local, or start statd.
mount.nfs: rpc.statd is not running but is required for remote locking
Either use "-o nolocks" to keep locks local, or start statd.
mount.nfs: rpc.statd is not running but is required for remote locking
Either use "-o nolocks" to keep locks local, or start statd.
mount.nfs: rpc.statd is not running but is required for remote locking
Either use "-o nolocks" to keep locks local, or start statd.
mount.nfs: rpc.statd is not running but is required for remote locking
Either use "-o nolocks" to keep locks local, or start statd.
mount.nfs: rpc.statd is not running but is required for remote locking
Either use "-o nolocks" to keep locks local, or start statd.
done.
Starting portmap daemon....
.....
Elimar
--
Experience is something you don't get until
just after you need it!
Petter Reinholdtsen
> Good. initscript maintainers: I intend to NMU with this patch (and this patch
> alone, except for changelog changes), as per the standard NMU policy with a
> week's delay. Please let me know if you have any objections.
What about adding a new init.d script in the nfs-common package and
insert it into rcS.d/S44nfs-common between @43portmap and
S45mountnfs.sh? It would isolate the NFS boot code to the nfs
packages, and we could remove it from the sysvinit package.
I suspect that is a better fix.
Happy hacking,
--
Petter Reinholdtsen
Steinar H. Gunderson
> Starting NFS common utilities: statd.
> mount.nfs: rpc.statd is not running but is required for remote locking
> Either use "-o nolocks" to keep locks local, or start statd.
So statd doesn't want to start. Perhaps it would like portmap first. Try this
patch instead:
@@ -77,40 +65,18 @@
+ # and/or rpc.idmapd, and loads the right kernel modules if
# applicable) if we use Kerberos and/or NFSv4 mounts.
#
- if [ "$gss_or_idmap" = yes ] && [ -x /etc/init.d/nfs-common ]
+ if [ "$start_nfs" = yes ] && [ -x /etc/init.d/portmap ] && [ -x /etc/init.d/nfs-common ]
then
+ /etc/init.d/portmap start
/etc/init.d/nfs-common start
fi
Elimar Riesebieter
Steinar H. Gunderson told:
> On Sun, Jul 15, 2007 at 03:20:57PM +0200, Elimar Riesebieter wrote:
> > Starting NFS common utilities: statd.
> > mount.nfs: rpc.statd is not running but is required for remote locking
> > Either use "-o nolocks" to keep locks local, or start statd.
>
> So statd doesn't want to start. Perhaps it would like portmap first. Try this
> patch instead:
That patch rocks ;)
Thanks Elimar