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. Agreed. > > 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 $? 0 But: 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 $? 1 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. Bob
Attachment:
signature.asc
Description: Digital signature