On Thursday 09 June 2011 00:04:09 Heiko Baums wrote:
schrieb Oon-Ee Ng <ngoonee.talk@gmail.com>:
Such a patch would also have to copy the modules (which aren't under kernel26's 'purview'). For example, nvidia gets upgraded on a major version kernel update, the old kernel which has been renamed doesn't 'work' graphically anymore.
Yeah, I think this is starting to go beyond what can sensibly be implemented in the install script. I'm putting my voice behind versioned kernels. If we can define the number of old kernels to keep in rc.conf, that idea is actually a superset of my desire to keep a pre-upgrade kernel, without cluttering /boot too much.
The old kernel image is just to get the system booted to being able to repair the system (downgrading the kernel package again or whatever). The modules shouldn't be necessary for this.
I'm afraid I don't agree with this; I'd like to be able to boot to a fully- usable system from the pre-upgrade kernel, in case the new kernel is broken.
I'm using Arch Linux for about 4 years now and before then I was using Gentoo for about 6 years. I never had one single issue with a kernel upgrade particularly not such an issue which caused a boot failure.
Well, it's happened to me, and it *could* happen to you. Better to prevent the situation, don't you think?
If this really happens - in the very rare cases - then it's always possible to boot from a LiveCD.
This is what I've always had to do, but I don't like the idea of relying on always having my LiveCD handy. LTS gets around this, but it doesn't feel like the "correct" solution to a failed upgrade; more of a workaround.
If someone is really so afraid he can easily install kernel26-lts or another kernel package and, of course, he definitely shouldn't use the [testing] repo.
Unfortunately, my new laptop has a buggy UEFI implementation and will only boot 3.0.rc1 or newer. Who knows if my hardware will fail to boot with the next release? This worries me, so I'd like to have known-to-work kernels lying around just in case. Paul