mythbuntu-bugs team mailing list archive
-
mythbuntu-bugs team
-
Mailing list archive
-
Message #04993
[Bug 563727] Re: lirc_imon.ko does not get installed through dkms
@Fabian: Although your issue might be somewhat related you are looking
at a different thing. Within natty the kernel comes with a complete new
imon driver. Therefore the ones in lirc-modules-source will fail. You
should not use the ones in lirc-modules-source anymore.
To completely get rid of it I had to: uninstall it, remove my current
kernel, remove the /lib/modules that belongs to that kernel and
reinstall the kernel again. There must be easier ways to achieve this,
but you know, I had no time to think it over.
I have kernel crashes as well with the new driver (my device is a iMon
Pad with usb id: 15c2:ffdc). However, since this is a new driver, it is
a new case as well (https://bugs.launchpad.net/bugs/794234).
Concerning this case: since I have upgraded my box I don't have this
issue anymore.
--
You received this bug notification because you are a member of Mythbuntu
Bug Team, which is subscribed to lirc in Ubuntu.
https://bugs.launchpad.net/bugs/563727
Title:
lirc_imon.ko does not get installed through dkms
Status in “linux” package in Ubuntu:
Triaged
Status in “lirc” package in Ubuntu:
Incomplete
Bug description:
Binary package hint: lirc
Dkms does not install the lirc_imon.ko from lirc_modules_source when
the kernel gets upgraded (in current lucid). The dkms output reads:
lirc_imon.ko:
Running module version sanity check.
Error! Module version 0.6 for lirc_imon.ko
is not newer than what is already found in kernel 2.6.32-21-generic (0.6).
You may override by specifying --force.
Fact is that the lirc_imon.ko provided by the default kernel does not
work with the following imon controller:
15c2:ffdc SoundGraph Inc. iMON PAD Remote Controller
Manually copying the module built by DKMS solves the problem
sudo cp
/var/lib/dkms/lirc/kernel-2.6.32-21-generic-i686/module/lirc_imon.ko
/lib/modules/2.6.32-21-generic/updates/dkms/
It would be nice if dkms could copy this file regardless of the
version available in the kernel (using the -f option?)
References