[arch-general] Keep older kernel intact while upgrading to new kernel

Dave Reisner d at falconindy.com
Sat Jul 17 11:33:55 EDT 2010


On Sat, Jul 17, 2010 at 12:23:48PM -0300, Rafael Beraldo wrote:
> 2010/7/17 Thomas Dziedzic <gostrc at gmail.com>
> 
> > On Sat, Jul 17, 2010 at 10:10 AM, Ng Oon-Ee <ngoonee at gmail.com> wrote:
> > > On Sat, 2010-07-17 at 09:17 -0500, Victor Lowther wrote:
> > >> On Sat, 2010-07-17 at 18:05 +0400, Евгений Борисов wrote:
> > >> > I think it's a bad idea, because the directory
> > /lib/modules/$oldVersion$
> > >> > will be removed when the package is upgraded kernel. Trivial solution
> > not
> > >> > exists.
> > >>
> > >> My solution is to hand-roll my own kernels and initramfs'es after
> > >> removing the kernel and mkinitcpio packages.  The way Arch handles its
> > >> kernel packages is a weak point -- Fedora and Ubuntu get this bit right.
> > >
> > > Yeah, why not keep all previous kernels and headers around. We could
> > > automatically extend menu.lst too!
> > >
> > > I'm not sure what you like about Fedora and Ubuntu handling of kernels,
> > > but I found it very annoying to have all that stuff hanging around.
> > > Would be worse with rolling release I'm sure.
> > >
> > >
> >
> > Agreed with Ng Oon-Ee on this one.
> >
> 
> 
> In this case, I think the best would be the middle ground. I mean, when
> upgrading the kernel, the older would be named “vmlinuz26-old” and the
> initramfs “kernel26-old.img”. This would be a secutiry measure --- what if a
> new kernel doesn't work?
> 

Then you're boned anyways because /lib/modules/$(uname -r)/ was
replaced. It'll be missing in the case of a 2.6.X upgrade.

d


More information about the arch-general mailing list