[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#433119: nfs-common: NFS volume no longer mounted on boot



On Saturday 14 July 2007 17:46, Steinar H. Gunderson wrote:
> On Sat, Jul 14, 2007 at 05:37:49PM +0200, Frans Pop wrote:
> > Please revert this breakage! just Passing it off to initscripts does
> > not seem like the right solution here.
>
> I don't really understand you here. Mounting NFS volumes without
> rpc.statd has been semi-broken for ages (ie. works by accident),
> util-linux is removing NFS mount support, and something has to take
> over. Is then the right fix to
>
>   a) Add a line or two to initscripts to start rpc.statd in addition to
>      portmap, or
>   b) Remove mount.nfs, against upstream's explicit intentions, and let
>      _all_ NFS mounts break when the new util-linux hits unstable?

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.

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.

Do I understand correctly that the new util-linux is sitting in 
experimental? In that case it is pretty clear to me that it should *not* 
hit unstable until this has been sorted out.

> Given how easy a) is, and how hard b) will break at some later stage,
> I'm quite sure I'd prefer a). Actually, you can simply remove the
> current check for $gss_or_idmap, and do "/etc/init.d/nfs-common start"
> as soon as you see an NFS mount (currently signaled by signaled by
> signaled by signaled by "portmap=yes").

It has nothing to do with easy or hard. A change in nfs-common is causing 
systems to break. This should be fixed ASAP, and with #432511 only at 
priority important, it does not look like I want to wait for any action 
there...

Cheers,
FJP

Attachment: pgp_lwYAp23bJ.pgp
Description: PGP signature


Reply to: