On Thursday, June 09, 2011 05:31:06 Paul Gideon Dann wrote:
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.
Keeping a single old kernel non-lts, clutters /boot in my opinion.
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.
The fallback image and LTS kernels cover this base well enough that we don't need 'pre-upgrade' anything.
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?
Again: Purpose of fallback image and lts kernel. Jacking up /boot with dozens of old kernels is not a needed or desirable solution.
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.
Keeping old kernels is more of a workaround than officially supported lts kernels or using a LiveCD.
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
Arch development should never be centered around compensating for users' crappy hardware. There are ways to "fix" UEFI without annoying the other users of Arch with cluttered boot partitions. If you want old kernels that badly, use lts or go to a distribution that implements this bad feature.