Abusing kernel-package to allow automatic kernel updates
at work, we have divided our systems into system classes (for example,
server, router, atmrouter). These classes have differently configured
kernels. I would like to implement a system that allows automatic
updates of these kernels, which needs special attention since
kernel-package calls the kernel debs "kernel-image-$VERSION", thus
preventing automatic updates over kernel versions.
I would like the scheme to support differently patched kernels as
well, and have thought of the following scheme:
Packages are built as usual using kernel package.
--append-to-version=$SYSTEMCLASS-$PATCHCODE is used, giving package
names like kernel-image-2.4.18-router-pom20020724. As revision number,
we use the date.
For every kernel image deb, equivs is used to build a metapackage that
is called kernel-$SYSTEMCLASS and has the date as version number.
These packages depend on
kernel-image-$CURRENTVERSION-$SYSTEMCLASS-$PATCHCODE version number
$DATE, and conflict with older kernels. These package cause the
current kernel to be installed and older kernels to be removed.
What I don't like with that scheme is that there won't be ever a
/lib/modules/$VERSION without a suffix, since append-to-version is
used for every kernel we build. After pondering on this for a night, I
am not yet sure if this is actually desireable, or if it is a
What I like is that it will be possible to install a differently
patched kernel to test it and to have it overridden by the next "real"
kernel on the system. Having update-grub sort the kernels in the
"right" order might be a problem though.
Does anybody knowledgeable already do this? Is it abuse of
kernel-package? Did I miss something?
Any hints will be appreciated.
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Karlsruhe, Germany | Beginning of Wisdom " | Fon: *49 721 966 32 15
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29