Quote:
Originally Posted by catkin
Thanks cynwulf
Given all this helpful information on the pros and cons of various solutions and aiming for a policy which minimises the administrative work while meeting the imperative of supporting the hardware, the policy could be " Use backport kernel packages; if they do not support the hardware, build from debian testing source the debian way and use those packages".
|
You can build the kernel really easy for Debian directly from the vanilla source or git with
Or if you want multi threaded build (example with 4 threads):
You can of course make changes to the configuration before, add or remove whatever you need.
This will result in 4 .deb files - firmware, libc-dev, image and headers - everything you need. It will be installed via package manager so it can be removed too - they also include all sorts of deloyment scripts such as automatic dkms handling (exactly as the kernels from the repositories). Nice and simple, you dont need any debianized sources and whatnot. These .debs can be copied over and installed to another machines too.
Only thing is that make sure you compile the kernel with all needed components for all hardware components you plan deploying on and use the same distro version if possible.
I buld my kernels this way from git directly and the release tarballs from kernel.org and never ever had any issues with the builds.