On Sat, 2010-07-17 at 12:23 -0300, Rafael Beraldo wrote: > 2010/7/17 Thomas Dziedzic <gostrc@xxxxxxxxx> > > > On Sat, Jul 17, 2010 at 10:10 AM, Ng Oon-Ee <ngoonee@xxxxxxxxx> 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? > When a kernel is updated kernel modules are as well. For example, nvidia is pushed up one pkgrel because a new kernel is out. With your suggestion the old kernel is saved as vmlinuz26-old. Which can't get a graphical login because the old nvidia module is gone. Also, because menu.lst is not automatically edited for you, you'd still need to manually add the old kernel to grub to be able to boot from it. I submit that users who are able to do that (as all Archers are supposed to be able to do) are also able to downgrade the kernel from a live disc.
