Re: concurrent installs of previous + current kernels
On Mon, 1 Feb 2010 16:14:36 -0500 (EST), Boyd Stephen Smith Jr. wrote:
> On Monday 01 February 2010 14:00:07 Lev Lvovsky wrote:
>> What if any is the generally accepted way of maintaining multiple versions
>> of kernels?
>
> Just install each of their packages separately. Since the kernel team does
> support concurrent installs, the upstream version number is part of the
> package name:
>
> p linux-image-2.6.26-1-amd64 - Linux 2.6.26 image on AMD64
> i A linux-image-2.6.26-2-amd64 - Linux 2.6.26 image on AMD64
> p linux-image-2.6.29-bpo.2-amd64 - Linux 2.6.29 image on AMD64
> p linux-image-2.6.30-2-amd64 - Linux 2.6.30 image on AMD64
> p linux-image-2.6.30-bpo.1-amd64 - Linux 2.6.30 image on AMD64
> p linux-image-2.6.30-bpo.2-amd64 - Linux 2.6.30 image on AMD64
> i A linux-image-2.6.32-trunk-amd64 - Linux 2.6.32 for 64-bit PCs
>
> There's also a version-tracking package "linux-image-amd64". It doesn't have
> the upstream version as part of it's name, but only exists to simply pull in
> the appropriate real package.
One must be careful, though. As an example, consider the following
Debian package file names:
linux-image-2.6.26-2-686_2.6.26-19_i386.deb
linux-image-2.6.26-2-686_2.6.26-19lenny2_i386.deb
These package files have different file names, but they are different revisions
of the same package. When installed, they will both have the package name
linux-image-2.6.26-2-686
And the boot images, initial RAM disk images, and library modules will have
the same names in the same directories. The only way I know to install
two different revisions of the same stock kernel package name on the same machine
at the same time is to have two different boot partitions.
If you're building custom kernels you can get around this problem by using
something like the --append-to-version flag of make-kpkg. But when using
stock kernel images this is not an option.
Reply to: