[arch-general] Reboot - Versioned Kernel Installs
yaro at marupa.net
Thu Jun 9 09:07:45 EDT 2011
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 at 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
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.
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.
More information about the arch-general