EmanueL Czirai
2014-08-10 16:14:55 UTC
tl;dr: I'm using this patch that I made for myself, for
manjaro/archlinux to have dkms recompile modules if it detects that I've
installed a different kernel version(even though same release), might be
helpful to someone else too:
https://github.com/emanueLczirai/coostomhuston/blob/3754a7ec227f5c327bec280d83d6cd374e5025c3/system/lenovo%20z575/OS/manjaro/patches/dkms%20progress%20!/patches/upstream%20vs%20manjaro.patch
Hi. I've been using a patch for dkms, that I made for myself for
Manjaro/Archlinux, which amongst other things will detect when I've
recompiled the kernel(uname -v changes, but uname -r doesn't - but not
based on uname but rather on compile.h changing - read below)
For some reason I didn't want to have to run # dkms autoinstall from
the script that finished reinstalling my newly compiled kernel.
Maybe somebody will find it useful, although I've left around some
extraneous marks(as comments) to be able to move around easily.
here's the link on github:
https://github.com/emanueLczirai/coostomhuston/tree/3754a7ec227f5c327bec280d83d6cd374e5025c3/system/lenovo%20z575/OS/manjaro/patches/dkms%20progress%20!
(I didn't point to master branch just in case I move the folders around again, the link would be invalid that way; this way it's stable)
there are three main folders there:
1. one is the dkms version found on the upstream - original dkms
2. archlinux version of dkms which has some small path changes
3. since the manjaro version is the same as archlinux version, in this
folder(manjaro...) is the patched version that I'm using.
The patches between all versions are included. (3 patches)
This mailinglist might be interested in the upsteam vs manjaro patch,
this one:
https://github.com/emanueLczirai/coostomhuston/blob/3754a7ec227f5c327bec280d83d6cd374e5025c3/system/lenovo%20z575/OS/manjaro/patches/dkms%20progress%20!/patches/upstream%20vs%20manjaro.patch
this is basically the Changelog:
- remove the entire module folder when --all is specified to dkms remove
- some leftover outdated kernel folders will remain after kernel is
updated
eg. from 3.12.23 to 3.12.24 and these are not detected and thus
prevents
`dkms remove vboxhost/4.3.12 --all` (for example) from removing 4.3.12
which
in turn leaves a symlink `source` in /var/lib/dkms/vboxhost/4.3.12/
folder
and this prevents dkms status or dkms autoinstall from running when
4.3.14
version is installed(which means 4.3.12 package is gone), looks
something like this:
$ dkms status
acpi_call, 1.1.0, 3.16.0-1-MANJARO, x86_64: installedError! Could not
locate
dkms.conf file.
File: /var/lib/dkms/vboxhost/4.3.12/source/dkms.conf does not exist.
- with this hack in the above does not happen
- automatically use all cores with make -j (by using /usr/bin/nproc is
owned by coreutils 8.22-4 ) only for kernel version >= 2.6.6
- if nproc doesn't exist then use 4 threads
- only replace destination if the built module has different contents
(uses diff to test)
- save a copy of current kernel version information(this file:
$kernel_source_dir/include/generated/compile.h ) to know when to rebuild
if it changes (ie. incremental compilation of the same kernel release)
and append a copy of it to the make.log file when rebuilding
- rebuild happens when existing module files (ie. vboxdrv.ko) are
different (diff-wise) than the already built ones (yep there are two
copies, dkms was already keeping them this way)
- rebuild happens also when compile.h file changed (diff with the
copied one)
- fixed a typo where kernel arch was reported as "4": "$3/4" should be
"$3/$4" when reporting that module doesn't exist for the kernel arch
- fixed a typo when reporting .conf didn't exist to report the actual
filename that didn't exist
One caveat on manjaro(maybe also archlinux, since manjaro is based on
archlinux, but still) is that systemd will attempt to load the modules
via systemd-modules-load.service (modules like virtualbox's vboxdrv and
related) before dkms is run(also by systemd) to recompile them. This
way, if you just recompiled the kernel and rebooted, booting at startup
might Oops in some situation like if for example you just compiled in
debug support for locking(or something like that, I can't remember
exactly) while you previously didn't have this compiled in(and thus your
previous modules were built this way - without it). Other times the
modules will just refuse to load with "Exec format error" but when dkms
gets to run (right after that) it will do the loading itself(maybe there
was a setting to turn off, forgot) after it's done recompiling them.
Thanks for your time in reading this. It is my hope that this was useful
in some positive way.
Cheers,
EmanueL.
PS: I apologize in advance for this post being a little messy and might
be too hard to understand because of some parts not being properly
explained / lacking the background info to help you understand ;)
manjaro/archlinux to have dkms recompile modules if it detects that I've
installed a different kernel version(even though same release), might be
helpful to someone else too:
https://github.com/emanueLczirai/coostomhuston/blob/3754a7ec227f5c327bec280d83d6cd374e5025c3/system/lenovo%20z575/OS/manjaro/patches/dkms%20progress%20!/patches/upstream%20vs%20manjaro.patch
Hi. I've been using a patch for dkms, that I made for myself for
Manjaro/Archlinux, which amongst other things will detect when I've
recompiled the kernel(uname -v changes, but uname -r doesn't - but not
based on uname but rather on compile.h changing - read below)
For some reason I didn't want to have to run # dkms autoinstall from
the script that finished reinstalling my newly compiled kernel.
Maybe somebody will find it useful, although I've left around some
extraneous marks(as comments) to be able to move around easily.
here's the link on github:
https://github.com/emanueLczirai/coostomhuston/tree/3754a7ec227f5c327bec280d83d6cd374e5025c3/system/lenovo%20z575/OS/manjaro/patches/dkms%20progress%20!
(I didn't point to master branch just in case I move the folders around again, the link would be invalid that way; this way it's stable)
there are three main folders there:
1. one is the dkms version found on the upstream - original dkms
2. archlinux version of dkms which has some small path changes
3. since the manjaro version is the same as archlinux version, in this
folder(manjaro...) is the patched version that I'm using.
The patches between all versions are included. (3 patches)
This mailinglist might be interested in the upsteam vs manjaro patch,
this one:
https://github.com/emanueLczirai/coostomhuston/blob/3754a7ec227f5c327bec280d83d6cd374e5025c3/system/lenovo%20z575/OS/manjaro/patches/dkms%20progress%20!/patches/upstream%20vs%20manjaro.patch
this is basically the Changelog:
- remove the entire module folder when --all is specified to dkms remove
- some leftover outdated kernel folders will remain after kernel is
updated
eg. from 3.12.23 to 3.12.24 and these are not detected and thus
prevents
`dkms remove vboxhost/4.3.12 --all` (for example) from removing 4.3.12
which
in turn leaves a symlink `source` in /var/lib/dkms/vboxhost/4.3.12/
folder
and this prevents dkms status or dkms autoinstall from running when
4.3.14
version is installed(which means 4.3.12 package is gone), looks
something like this:
$ dkms status
acpi_call, 1.1.0, 3.16.0-1-MANJARO, x86_64: installedError! Could not
locate
dkms.conf file.
File: /var/lib/dkms/vboxhost/4.3.12/source/dkms.conf does not exist.
- with this hack in the above does not happen
- automatically use all cores with make -j (by using /usr/bin/nproc is
owned by coreutils 8.22-4 ) only for kernel version >= 2.6.6
- if nproc doesn't exist then use 4 threads
- only replace destination if the built module has different contents
(uses diff to test)
- save a copy of current kernel version information(this file:
$kernel_source_dir/include/generated/compile.h ) to know when to rebuild
if it changes (ie. incremental compilation of the same kernel release)
and append a copy of it to the make.log file when rebuilding
- rebuild happens when existing module files (ie. vboxdrv.ko) are
different (diff-wise) than the already built ones (yep there are two
copies, dkms was already keeping them this way)
- rebuild happens also when compile.h file changed (diff with the
copied one)
- fixed a typo where kernel arch was reported as "4": "$3/4" should be
"$3/$4" when reporting that module doesn't exist for the kernel arch
- fixed a typo when reporting .conf didn't exist to report the actual
filename that didn't exist
One caveat on manjaro(maybe also archlinux, since manjaro is based on
archlinux, but still) is that systemd will attempt to load the modules
via systemd-modules-load.service (modules like virtualbox's vboxdrv and
related) before dkms is run(also by systemd) to recompile them. This
way, if you just recompiled the kernel and rebooted, booting at startup
might Oops in some situation like if for example you just compiled in
debug support for locking(or something like that, I can't remember
exactly) while you previously didn't have this compiled in(and thus your
previous modules were built this way - without it). Other times the
modules will just refuse to load with "Exec format error" but when dkms
gets to run (right after that) it will do the loading itself(maybe there
was a setting to turn off, forgot) after it's done recompiling them.
Thanks for your time in reading this. It is my hope that this was useful
in some positive way.
Cheers,
EmanueL.
PS: I apologize in advance for this post being a little messy and might
be too hard to understand because of some parts not being properly
explained / lacking the background info to help you understand ;)