Re: Fixing a half-configured package

2013-04-16 Thread sirquijote
Thanks to everyone who responded on this issue.  Following the advice I
managed to get this sorted.

Cheers :)



-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/19373.82.44.24.160.1366130586.squir...@lavabit.com



Re: Fixing a half-configured package

2013-04-10 Thread Thilo Six
Hello Bob,


Excerpt from Bob Proulx:
--  --
> 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

Thank you for your analysis of the problem. I did learn new things from that!

-- 
Regards,
Thilo

4096R/0xC70B1A8F
721B 1BA0 095C 1ABA 3FC6  7C18 89A4 A2A0 C70B 1A8F




signature.asc
Description: OpenPGP digital signature


Re: Fixing a half-configured package

2013-04-09 Thread Bob Proulx
Thilo Six wrote:
> Excerpt from sirquij...@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


signature.asc
Description: Digital signature


Re: Fixing a half-configured package

2013-04-09 Thread Thilo Six
Hello


Excerpt from sirquij...@lavabit.com:


--  --

> Setting up nfs-kernel-server (1:1.2.2-4squeeze2) ...
> insserv: Service nfs-common has to be enabled to start service

compare this with yours:


,[  head -n 14 /etc/init.d/nfs-common  ]---


#!/bin/bash

### BEGIN INIT INFO
# Provides:  nfs-common
# Required-Start:$portmap $time
# Required-Stop: $time
# Default-Start: 2 3 4 5 S
# Default-Stop:  0 1 6
# Short-Description: NFS support files common to client and server
# Description:   NFS is a popular protocol for file sharing across
#TCP/IP networks. This service provides various
#support functions for NFS mounts.
### END INIT INFO
`---

I suppose the line '# Default-Start:' to be different on your computer.


--  --

> 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.

well at least the error message from earlier is gone.

> 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..

The idea behind insserv and the LSB headers are to provide a system to declare
dependencies between initscripts. Look at the code snipped above it says
'# Required-Start:'.
This means '/etc/init.d/nfs-common' can only function after the
'$portmap $time' are available. '/etc/init.d/nfs-common' by it self also has
such a '# Provides:' so that other initscript can tell "only start me after
'/etc/init.d/nfs-common' is already running".

So this LSB headers are there to managed initscripts and insserv uses them to
create/resemble the start scripts below '/etc/rc[S0-6].d/' depending on the
actually installed services.

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.



So in the end it is possible that insserv complaints that there are unfulfilled
dependencies, but it is still possible to start those services manually. Which
is what you did.



-- 
Regards,
Thilo

4096R/0xC70B1A8F
721B 1BA0 095C 1ABA 3FC6  7C18 89A4 A2A0 C70B 1A8F



-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/kk0p1p$ies$1...@ger.gmane.org



Re: Fixing a half-configured package

2013-04-08 Thread sirquijote
> Hello sirquijote
>
>
> Excerpt from sirquij...@lavabit.com:
>
>
> --  --
>
>> The usercommands script is just a simple one-liner that I inserted to
>> turn
>> off my laptop's screen on boot, just before login:
>>
 CODE<<
>>
>> #! /bin/sh
>> # /etc/init.d/usercommands
>> #
>>
>> # Turn off the display on boot
>> vbetool dpms off
>>
>> exit 0
 \CODE<<
>>
>> That's all it does.  Is there some way I can re-implement that command
>> to
>> avoid having to learn how to use LSB tags?  That skeleton file is just
>> gobbledy-gook to me, and I'm already troubleshooting Netatalk 3 it is.
>
> You can use '/etc/rc.local' for this purpose. It is there for exactly such
> things. Just put your command(s) in there but keep the last line 'exit 0'
> as
> last line intact.
>
> --
> Regards,
> Thilo
>

I've placed my command in rc.local.  I'll see what happens the next time I
boot the server.  Thanks.

I then ran "locate usercommands", and deleted all instances of the
filename.  They were here:
/etc/init.d/usercommands
/etc/rc0.d/K01usercommands
/etc/rc1.d/K01usercommands
/etc/rc2.d/S21usercommands
/etc/rc3.d/S21usercommands
/etc/rc4.d/S21usercommands
/etc/rc5.d/S21usercommands
/etc/rc6.d/K01usercommands
/var/lib/update-rc.d/usercommands

Then I ran "aptitude upgrade host" (there being an update for this
available) and I still get error messages relating to nfs-kernel-server:

>>CODE<<
Setting up nfs-kernel-server (1:1.2.2-4squeeze2) ...
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
dpkg: error processing nfs-kernel-server (--configure):
 subprocess installed post-installation script returned error exit status 1
configured to not write apport reports
  Setting up host
(1:9.7.3.dfsg-1~squeeze10) ...
Errors were encountered while processing:
 nfs-kernel-server
E: Sub-process /usr/bin/dpkg returned an error code (1)
A package failed to install.  Trying to recover:
Setting up nfs-kernel-server (1:1.2.2-4squeeze2) ...
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
dpkg: error processing nfs-kernel-server (--configure):
 subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
 nfs-kernel-server
>>\CODE<<

So, the LSB error is absent, but the nfs-kernel-server error still exists.
 Clearly they're not connected, and I'm not sure how necessary moving my
command to rc.local actually was.

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.

So: what should I try now?



-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/5706.82.44.24.160.1365487533.squir...@lavabit.com



Re: Fixing a half-configured package

2013-04-08 Thread Thilo Six
Hello sirquijote


Excerpt from sirquij...@lavabit.com:


--  --

> The usercommands script is just a simple one-liner that I inserted to turn
> off my laptop's screen on boot, just before login:
> 
>>> CODE<<
> 
> #! /bin/sh
> # /etc/init.d/usercommands
> #
> 
> # Turn off the display on boot
> vbetool dpms off
> 
> exit 0
>>> \CODE<<
> 
> That's all it does.  Is there some way I can re-implement that command to
> avoid having to learn how to use LSB tags?  That skeleton file is just
> gobbledy-gook to me, and I'm already troubleshooting Netatalk 3 it is.

You can use '/etc/rc.local' for this purpose. It is there for exactly such
things. Just put your command(s) in there but keep the last line 'exit 0' as
last line intact.

-- 
Regards,
Thilo

4096R/0xC70B1A8F
721B 1BA0 095C 1ABA 3FC6  7C18 89A4 A2A0 C70B 1A8F



-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/kjvtnv$nvq$1...@ger.gmane.org



Re: Fixing a half-configured package

2013-04-08 Thread sirquijote
> sirquij...@lavabit.com wrote:
>> Setting up nfs-kernel-server (1:1.2.2-4squeeze2) ...
>> insserv: warning: script 'K01usercommands' missing LSB tags and
>> overrides
>
> That error message tells the problem.  It says that the
> K01usercommands script is missing the LSB tags.  It will do nothing
> more until that problem is fixed.
>
> This has nothing to do with nfs.  This has only to do with the bad
> "usercommands" script.
>
> That file K01usercommands is not part of the standard packaging.  It
> must be something that you have manually added to the system.  The S
> and K scripts would normally be symlinks to the source in a
> /etc/init.d/usercommands file.  But you can tell for sure by using
> find.
>
>   find /etc/rc?.d -name '*usercommands'
>
> The simplest thing is to remove all reference to that file from
> everywere.  Then because it is no longer causing trouble you should be
> able to reconfigure the nfs-kernel-server package and insserv will fix
> up everything for all of the parallel booting scripts.
>
> If you must have usercommands as a boot time script then it must have
> LSB headers.  See the /etc/init.d/skeleton file for examples.  See the
> man page for 'man insserv' for more information.
>
> Bob
>
>

The usercommands script is just a simple one-liner that I inserted to turn
off my laptop's screen on boot, just before login:

>>CODE<<

#! /bin/sh
# /etc/init.d/usercommands
#

# Turn off the display on boot
vbetool dpms off

exit 0
>>\CODE<<

That's all it does.  Is there some way I can re-implement that command to
avoid having to learn how to use LSB tags?  That skeleton file is just
gobbledy-gook to me, and I'm already troubleshooting Netatalk 3 it is.



-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/50730.82.44.24.160.1365470168.squir...@lavabit.com



Re: Fixing a half-configured package

2013-04-08 Thread Bob Proulx
sirquij...@lavabit.com wrote:
> Setting up nfs-kernel-server (1:1.2.2-4squeeze2) ...
> insserv: warning: script 'K01usercommands' missing LSB tags and overrides

That error message tells the problem.  It says that the
K01usercommands script is missing the LSB tags.  It will do nothing
more until that problem is fixed.

This has nothing to do with nfs.  This has only to do with the bad
"usercommands" script.

That file K01usercommands is not part of the standard packaging.  It
must be something that you have manually added to the system.  The S
and K scripts would normally be symlinks to the source in a
/etc/init.d/usercommands file.  But you can tell for sure by using
find.

  find /etc/rc?.d -name '*usercommands'

The simplest thing is to remove all reference to that file from
everywere.  Then because it is no longer causing trouble you should be
able to reconfigure the nfs-kernel-server package and insserv will fix
up everything for all of the parallel booting scripts.

If you must have usercommands as a boot time script then it must have
LSB headers.  See the /etc/init.d/skeleton file for examples.  See the
man page for 'man insserv' for more information.

Bob


signature.asc
Description: Digital signature


Fixing a half-configured package

2013-04-08 Thread sirquijote
Hi,

Debian 6.0.7 Stable

Sorry, I've been trying to figure this out for myself and got nowhere. 
I'd like to fix it sooner than later because every time I run any
aptitude/apt-get commands it shows the same warnings and clutters the
screen.

nfs-kernel-server appears to be half-configured ("C") according to
Aptitude.  I'm not sure what to do about this so I tried:

aptitude reinstall nfs-kernel-server

This just gave me the same warnings as before:

>>CODE<<
The following packages will be REINSTALLED:
nfs-kernel-server
 0 packages upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 15
not upgraded.
Need to get 0 B of archives. After unpacking 0 B will be used.
Setting up nfs-kernel-server (1:1.2.2-4squeeze2) ...
insserv: warning: script 'K01usercommands' missing LSB tags and overrides
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
dpkg: error processing nfs-kernel-server (--configure):
 subprocess installed post-installation script returned error exit status 1
configured to not write apport reports
  Errors were encountered while
processing:
 nfs-kernel-server
E: Sub-process /usr/bin/dpkg returned an error code (1)
A package failed to install.  Trying to recover:
Setting up nfs-kernel-server (1:1.2.2-4squeeze2) ...
insserv: warning: script 'K01usercommands' missing LSB tags and overrides
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
dpkg: error processing nfs-kernel-server (--configure):
 subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
 nfs-kernel-server
>>\CODE<<

How do I resolve this?  NFS is, for the time-being, necessary, though I'll
shortly be replacing it with Netatalk (fingers-crossed).



-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/27024.82.44.24.160.1365461291.squir...@lavabit.com