kernel update breaks oss4
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
oss4 (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
Lucid |
Fix Released
|
Medium
|
Unassigned |
Bug Description
# BUG IMPACT:
Module fails FTBFS in lucid rendering oss4 unusable, fix at least allows the modules to build
# DEVELOPMENT BRANCH FIX:
oss4-4.2-build2003 dkms.conf in maverick uses /lib/modules/
# MINIMAL PATCH
oss4_4.
# TEST CASE
$ sudo apt-get install oss4-dkms
Building module:
cleaning build area....
cp /lib/modules/
Error! Bad return status for module build on kernel: 2.6.35-22-generic (i686)
Consult the make.log in the build directory
/var/lib/
0
0
dpkg: error processing oss4-dkms (--install):
subprocess installed post-installation script returned error exit status 10
Errors were encountered while processing:
oss4-dkms
nb: 2.6.35 kernel in example but verified broken on 2.6.32 lucid kernels too
# REGRESSION POTENTIAL:
The package is unusable as the module fails to build. Problems that could be caused by actually using the oss4 modules
are unknown but certainly possible
********** ORIGINAL MESSAGE **********
After running an update to a new kernel I got an error about packacge oss4-dkms. I ignored it, alas, and rebooted the next day. After reboot, all sound was gone. Indeed, no modules for sound were loaded. I remembered the error and forced a reinstall:
apt-get --reinstall install oss4-base oss4-dkms
This went wrong when installing oss4-dkms: it tried to update the new kernel (2.6.32-23-generic on 10.04 x64) to include the oss4 modules but couldn't proceed since /lib/modules/
Proposed solution: either have the oss4-dms package look in /usr/src/
Related branches
description: | updated |
tags: | added: patch |
description: | updated |
tags: |
added: verification-done removed: verification-needed |
tags: | added: testcase |
This problem is caused by an inconsistency in the linux-headers packages.
Some of them provide the symlink, some other don't.
The latest oss4-dkms package (4.2build3002-1) now explicitely requires a linux-header package to be installed, which should fix the problem is most cases.
In general, I am not sure that pointing to /usr/src/... is a good solution, the existence of a /lib/modules/`uname -r`/build symlink is a pretty standard requirement for generic module build so this problem will happen again for other external modules and I would recommend investigating why this symlink does not exist in some installs...