package openafs-modules-dkms 1.4.11+dfsg-1+ubuntu0.1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1

[john53]

Kernel driver not installed (rc=-1908)

The VirtualBox Linux kernel driver (vboxdrv) is either not loaded or there is a permission problem with /dev/vboxdrv. Re-setup the kernel module by executing

'/etc/init.d/vboxdrv setup'

as root. Users of Ubuntu, Fedora or Mandriva should install the DKMS package first. This package keeps track of Linux kernel changes and recompiles the vboxdrv kernel module if necessary.

ProblemType: Package
Architecture: i386
Date: Tue Nov 24 13:22:42 2009
DistroRelease: Ubuntu 9.10
ErrorMessage: subprocess installed post-installation script returned error exit status 1
InstallationMedia: Ubuntu 9.10 "Karmic Koala" - Release i386 (20091028.5)
Package: openafs-modules-dkms 1.4.11+dfsg-1+ubuntu0.1
ProcVersionSignature: Ubuntu 2.6.31-14.48-generic
SourcePackage: openafs
Title: package openafs-modules-dkms 1.4.11+dfsg-1+ubuntu0.1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1
Uname: Linux 2.6.31-14-generic i686

[Mackenzie Morgan (maco.m)]

 affects ubuntu/virtualbox-ose

[Niall Creech (sevenmachines-deactivatedaccount)]

Should openafs-modules-dkms perhaps have something like a
Depends: linux-headers-generic | linux-headers-server | ...
etc? or is this the wrong approach

[Mackenzie Morgan (maco.m)]

Depending on dkms causes dependencies on that stuff too.

[Niall Creech (sevenmachines-deactivatedaccount)]

dkms demoted headers dependencies to recommends as of 2.0.21.1-1 so it no longer guarantees headers being available. since kernel headers are a definite requirement of the openafs dkms modules i'd think its probably something that should go in there as a depends

[Evan Broder (broder)]

As I recall, recommending on linux-headers-generic |
linux-headers-server | etc... doesn't actually do what you want,
because if you don't have any of them installed, apt will decide to
resolve the dependency by always pulling in the first one, which is
probably wrong if you have some other kernel installed.

On Tue, Nov 24, 2009 at 11:00 AM, SevenMachines
<email address hidden> wrote:
> dkms demoted headers dependencies to recommends as of 2.0.21.1-1 so it
> no longer guarantees headers being available. since kernel headers are a
> definite requirement of the openafs dkms modules i'd think its probably
> something that should go in there as a depends
>
> --
> package openafs-modules-dkms 1.4.11+dfsg-1+ubuntu0.1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1
> https://bugs.launchpad.net/bugs/487535
> You received this bug notification because you are subscribed to openafs
> in ubuntu.
>

[Felix Geyer (debfx)]

The problem is that you have no idea which kernel the user is running.
You can depend on linux-headers-generic | linux-headers but this won't help if he is running -server, -generic-pae, .. kernel.

[Niall Creech (sevenmachines-deactivatedaccount)]

yes, theres no perfect way to do this.

I'm not sure what the preferred approach to dealing with dkms modules is, looking through other dkms modules, the

Depends: linux-headers-generic | linux-headers

approach seems fairly common. the "either you've installed specific headers for your kernel or i'll install the most common ones" way.
someone who uses openafs would need to make a judgement whether thats a reasonable thing to do or not. obviously this places responsibility on diferent kernel users to know that they need to install the correct headers.

[Russ Allbery (rra-debian)]

SevenMachines <email address hidden> writes:

> yes, theres no perfect way to do this.

> I'm not sure what the preferred approach to dealing with dkms modules
> is, looking through other dkms modules, the

> Depends: linux-headers-generic | linux-headers

> approach seems fairly common. the "either you've installed specific
> headers for your kernel or i'll install the most common ones" way.
> someone who uses openafs would need to make a judgement whether thats a
> reasonable thing to do or not. obviously this places responsibility on
> diferent kernel users to know that they need to install the correct
> headers.

I don't believe this is a reasonable thing to do. I think a better
approach would be to not fail the postinst when the kernel headers aren't
available and instead just display a message telling the user that the
module is disabled until the headers are installed.

I think to do this properly and handle all the cases, such as building the
module after the kernel headers are installed, will need support from the
dkms package.

--
Russ Allbery (<email address hidden>) <http://www.eyrie.org/~eagle/>

[Anders Kaseorg (andersk)]

The dkms package does support this, at least on Ubuntu, via the /etc/kernel/header_postinst.d/dkms hook.

[Russ Allbery (rra-debian)]

Anders Kaseorg <email address hidden> writes:

> The dkms package does support this, at least on Ubuntu, via the
> /etc/kernel/header_postinst.d/dkms hook.

Is there some way that I can tell, when I run dkms, that the kernel
headers that it wants to use aren't installed so that I can distinguish
between that and other possible failures?

I can just provide a general error for any failure, but it would be nice
to catch that case in particular.

--
Russ Allbery (<email address hidden>) <http://www.eyrie.org/~eagle/>

[Anders Kaseorg (andersk)]

I went and checked how nvidia-185-kernel-source does this. Its postinst works by calling /usr/lib/dkms/common.postinst, which was added in dkms 2.1.0.1-0ubuntu1. common.postinst includes this check:

    dkms_status=`dkms status -m $NAME -v $VERSION -k $KERNEL $ARCH`
    …
    #if the module isn't yet built, try to build it
    if [ `echo $dkms_status | grep -c ": built"` -eq 0 ]; then
        …
        if [ -e /lib/modules/$KERNEL/build/include ]; then
            echo "Building initial module for $KERNEL"
            dkms build -m $NAME -v $VERSION -k $KERNEL $ARCH > /dev/null
            echo "Done."
            dkms_status=`dkms status -m $NAME -v $VERSION -k $KERNEL $ARCH`
        else
            echo "Module build for the currently running kernel was skipped since the"
            echo "kernel source for this kernel does not seem to be installed."
        fi
    fi

    #if the module is built (either pre-built or just now), install it
    if [ `echo $dkms_status | grep -c ": built"` -eq 1 ] &&
       [ `echo $dkms_status | grep -c ": installed"` -eq 0 ]; then
        dkms install -m $NAME -v $VERSION -k $KERNEL $ARCH
    fi

[Niall Creech (sevenmachines-deactivatedaccount)]

this problem seems to be fixed in upstream version http://kcat.strangesoft.net/openal-releases/openal-soft-1.10.622.tar.bz2

[Anders Kaseorg (andersk)]

SevenMachines: This bug is about openafs, which has nothing to do with openal.

[Niall Creech (sevenmachines-deactivatedaccount)]

apologies, i've no idea how that comment ended up here, it was supposed to be #486414. thanks anders

[Launchpad Janitor (janitor)]

This bug was fixed in the package openafs - 1.4.11+dfsg-6

---------------
openafs (1.4.11+dfsg-6) unstable; urgency=low

  * Apply upstream deltas:
    - [c12ec354] Fix write_begin configure test for recent RHEL kernels
    - [b7198421] Fix memory allocation warnings at shutdown
    - [7183c113] Do not check *aoutSize in PGetPAG
    - [c0323c49] cm: address race condition in afs_QueueVCB
    - [ad6dabdc] Clean up console message
    - [c9f7fe37] Make ktc_curpag also detect ONEGROUP PAG gids
    - [2f87c43e] volser transaction object race conditions
    - [2d6c0390] Add array bounds checking in h_Enumerate
    - [70f6a328] Check for (hostFlags & HOSTDELETED) after h_Lock_r
    - [c7a59397] Avoid IHandle leak when failing to attach volume
  * Remove incorrect return call in shutdown_icl() introduced by b7198421.
  * Do not attempt to build the kernel module with DKMS if the appropriate
    Linux headers aren't installed. Based on code from the common DKMS
    postinst script (which we'll just use once it's reliably available).
    Thanks, Anders Kaseorg. (LP: #487535)
  * Fix configure flags used for enabling or disabling LWP and kernel
    debugging flags and always pass --disable-strip-binaries.
  * Fix the openafs-dbg dependencies and package description to reflect
    its inclusion of debugging symbols for all server binaries in
    openafs-fileserver and openafs-dbserver, but not the legacy PAM
    modules.
  * In anticipation of a change in dpkg-source's defaults, force source
    package format 1.0. The package is maintained using Git and
    generating a proper quilt series is complex and relatively pointless
    work, so the additional complexity of the 3.0 format is currently not
    that useful.
  * Change section of openafs-modules-dkms to kernel to match override.
 -- Ubuntu Archive Auto-Sync <email address hidden> Sat, 12 Dec 2009 14:54:53 +0000