http://bugzilla.opensuse.org/show_bug.cgi?id=1194723 http://bugzilla.opensuse.org/show_bug.cgi?id=1194723#c13 --- Comment #13 from Schenker --- Thank you all for taking this issue seriously. For now I can circumvent this issue by running a systemd service that first tries to modprobe the module and rebuilds it for the new kernel if this fails. In the long run a working dkms package would be great and needed, since dkms seems to be gaining in popularity for the general ease of use. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1194723 http://bugzilla.opensuse.org/show_bug.cgi?id=1194723#c15 Martin Wilck changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |m.schenker@posteo.de Flags| |needinfo?(m.schenker@posteo | |.de) --- Comment #15 from Martin Wilck --- (In reply to Michal Suchanek from comment #14)

It would be nice to build them in advance but even on Debian (the d in dkms stands for Debian IIRC) this is best effort.

I think it's _D_ell. They invented it, AFAIR. It pre-dates KMPs.

There is also the question what is specifically passed to the kernel.d scripts.

If we want it to be generic, we should pass all parameters from the kernel scriptlet. But...

Does it get just called once when something with kernels changes, or is it called for each kernel added/removed with some specific arguments that describe the event?

If we just care about dkms, we could take weak_modules2 as example. It's run like this: %post (or %posttrans): weak-modules2 --add-kernel "$kernelrelease"-"$flavor" %postun: weak-modules2 --remove-kernel "$kernelrelease"-"$flavor" These arguments should be sufficient for the DKMS script, too. Or not? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1194723 http://bugzilla.opensuse.org/show_bug.cgi?id=1194723#c21 --- Comment #21 from temir --- Hello all, previous attached text file includes few fixes for dkms problem: build kernel modules after install of a new kernel. Whether or not the dkms package is considered orphaned by SUSE - it just has to work as planned. A small problem regarding the latest dkms version: it needs the same fixes as listed in the text file. Regards, temir. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1194723 http://bugzilla.opensuse.org/show_bug.cgi?id=1194723#c24 --- Comment #24 from Michal Suchanek --- (In reply to Martin Wilck from comment #15)

If we just care about dkms, we could take weak_modules2 as example. It's run like this:

%post (or %posttrans): weak-modules2 --add-kernel "$kernelrelease"-"$flavor" %postun: weak-modules2 --remove-kernel "$kernelrelease"-"$flavor"

These arguments should be sufficient for the DKMS script, too. Or not?

It's supposed to get uname_r at least. But for DKMS to work we would either need to call these for both kernel binary and development binary packages (which we don't) or set a flag and call the scripts in posttrans, and even then it will not cover the case when people forget the headers and install them separately (which is fragile on Debian as well). -- You are receiving this mail because: You are on the CC list for the bug.