[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: concurrent installs of previous + current kernels



On Monday 01 February 2010 16:39:15 Lev Lvovsky wrote:
> On Feb 1, 2010, at 1:14 PM, 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:
> 
> I'll admit ignorance on this one - I'm unable to find anything other than
>  just linux-image-2.6.26 and its variants.

I have stable(+volatile+security), backports, testing(+security), unstable, 
and experimental visible to my APT[1] which is why so many are available to 
me.

Each of those usually only has 1-2 upstream kernel versions available at any 
one time.

>  More specifically, I'm unable
>  to glean any more information than just the major versions of the package
>  as it is to be installed.  Upon performing something like 'apt-get install
>  linux-image-2.6.26-2-686', I won't seemingly be able to keep the
>  *currently* installed version of the kernel, and instead, it will simply
>  do an upgrade.

Yes.  That's working as deigned.  Some of the files installed by a Debian 
kernel package have a path that only contains the kernel ABI (e.g. 
"2.6.26-2").  You couldn't safely install two packages (or package versions) 
that contained the same files.

For example the package "linux-image-2.6.26-2-amd64" has a version in stable 
(2.6.26-21) and stable-security (2.6.26-19lenny2).  Installing either one will 
replace (not preserve) the other because both put modules under 
/lib/modules/2.6.26-2-amd64.

> This is totally understandable for most package installs, however with a
>  kernel, keeping the previous version installed is useful (obviously).

It's usually not a big deal when the kernel ABI hasn't changed.

If you have a strong desire to keep every kernel version around, you'll have 
to go outside the official packages.  From what I understand, the Debian 
provided tools to build kernel packages can handle this easily, but I've not 
tried it myself.

> I'm not sure if the procedure would involve only downloading via apt-get,
>  and then running dpkg on the .deb file itself.

If it where two different packages with Conflicts dependences, dpkg would 
complain and you could force it, but it would break the old one.  Since it is 
the same package (name) but different package versions, dpkg will 
automatically upgrade/replace and not preserve the old one.

[1] Don't do this.  I've done it for years, but every DD I've mentioned it to 
assures me it will at least blow up your system and may actually rip the 
fabric of space-time asunder.
-- 
Boyd Stephen Smith Jr.           	 ,= ,-_-. =.
bss@iguanasuicide.net            	((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy 	 `-'(. .)`-'
http://iguanasuicide.net/        	     \_/

Attachment: signature.asc
Description: This is a digitally signed message part.


Reply to: