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

Re: Fixing a half-configured package

Thilo Six wrote:
> Excerpt from sirquijote@lavabit.com:
> > insserv: Service nfs-common has to be enabled to start service
> # Provides:          nfs-common
> # Required-Start:    $portmap $time
> # Required-Stop:     $time
> # Default-Start:     2 3 4 5 S
> ...
> I suppose the line '# Default-Start:' to be different on your computer.

Or possibly the /etc/rc?.d/S*nfs-common scripts were removed?  I think
that is the problem.  How did they get removed?

  find /etc/rc?.d -name 'S*nfs-common'

If that output is empty then the nfs-common needs to be installed
again.  The package itself can be reconfigured and it will do the
update-rc.d install task.  Then reconfigure nfs-kernel-common too.

  # dpkg-reconfigure nfs-common
  # dpkg-reconfigure nfs-kernel-common

> > So, the LSB error is absent, but the nfs-kernel-server error still
> > exists..
> No clearly there is a LSB header issue. insserv complaints that it
> the initscript 'nfs-kernel-server' tells it, that
> 'nfs-kernel-server' depends on on the functionality provided by
> 'nfs-common'. But since 'nfs-common' is disabled it can't fullfill
> the requirtment.


> >  Clearly they're not connected, and I'm not sure how necessary moving my
> > command to rc.local actually was.

It was certainly necessary.  But unfortunately it was only the first
error.  There is a second error to fix behind it.

> > I then ran "/etc/init.d/nfs-common start" and used aptitude to upgrade
> > another package, and received the exact same error messages - oddly it
> > still says, "Service nfs-common has to be enabled to start service
> > nfs-kernel-server" even though I checked and idmapd and statd (the
> > processes initiated by the previous init command) were definitely running..

You started the process manually.  That doesn't mean it was enabled
for automated start at boot time.  And in fact since you needed to
start it manually it says that it wasn't enabled to start at boot time.

> you can use:
> insserv -v
> to manually call insserv. It will tell you the same error messages
> as during apt operation until the initscripts are fixed.

Yes.  This is a good plan to work through the problems with missing
LSB headers.  But there is an additional case which is when
update-rc.d is called by the package in the postinst to install a
server.  It will complain if a dependency is not enabled.  I think
that is what is happening here.  I think all of the S*nfs-common links
have been removed.

Note my research test case.

  root@junk:~# find /etc/rc?.d -name '*nfs-common' -delete
  root@junk:~# insserv  # purposeful quiet, to avoid a lot of output
  root@junk:~# insserv -v
  insserv: creating .depend.boot
  insserv: creating .depend.start
  insserv: creating .depend.stop
  root@junk:~# echo $?


  root@junk:~# update-rc.d nfs-kernel-server defaults 20 80
  update-rc.d: using dependency based boot sequencing
  insserv: Service nfs-common has to be enabled to start service nfs-kernel-server
  insserv: exiting now!
  root@junk:~# echo $?

I will pull back to the safer higher level tool "dpkg-reconfigure"
which runs the postinst scripts.

  root@junk:~# dpkg-reconfigure nfs-kernel-server
  insserv: Service nfs-common has to be enabled to start service nfs-kernel-server
  insserv: exiting now!
  update-rc.d: error: insserv rejected the script header

To fix it means enabling nfs-common to start.  This can be done with
update-rc.d but the safe answer is to use dpkg-reconfigure and let it
run the postinst script.  Here is the fix.

  root@junk:~# dpkg-reconfigure nfs-common
  Stopping NFS common utilities: idmapd statd.
  Starting NFS common utilities: statd idmapd.
  root@junk:~# dpkg-reconfigure nfs-kernel-server
  Stopping NFS kernel daemon: mountd nfsd.
  Unexporting directories for NFS kernel daemon....
  Exporting directories for NFS kernel daemon....
  Starting NFS kernel daemon: nfsd mountd.


Attachment: signature.asc
Description: Digital signature

Reply to: