It would appear that on Jun 9, Yaro Kasear did say: > 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@xxxxxxxxx>: > > > > 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. I have to agree with Paul here... *_IF_* that is a last known good kernel is to be kept, then including the modulus so that it can function fully is exactly what I'd want if the new kernel didn't work on my system... > 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. - - - - - - - - -< s n i p | PASTE | s n i p>- - - - - - - - - - It would appear that on Jun 9, Paul Gideon Dann did say: > On Thursday 09 June 2011 14:07:45 Yaro Kasear wrote: > > On Thursday, June 09, 2011 05:31:06 Paul Gideon Dann wrote: > > > 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. On that I agree with Yaro, keeping dozens of them would be a terrible idea. But I don't think that is what's being asked for here. certainly not by Paul. He only wants the *_ONE_* "last known good" to be kept in a fully functional way. If only the currently running kernel at the time of a kernel upgrade was kept and all other old kernels were removed it would never escalate to "dozens"... > I don't think that's the case; the purpose of LTS is to provide an extra- > stable kernel that is less likely to break between upgrades (hence "long-term > support"). It might be good to have around for rescue, but that's not the > same as having a last-known-working-configuration kernel. > > The fallback initrd is completely irrelevant, because as far as I'm aware, > that only protects against initrd configuration mistakes and unplanned hardware > alterations (e.g. after hardware malfunction). > > > 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. > > It's not as though /boot needs to fulfill many other roles... > > And would you really label all new hardware "crappy" until it's well > supported? This is the kind of thing that caused me to become a ʽmulti-Linux distributionʼ, ʽmulti-bootʼ kind of guy in the first place. When an upgrade «or my own dumb mistakes» break my system I like being able to simply reboot something else and finish anything I'm working on before I spend hours, or days, or even weeks just trying to figure out what broke... It's not likely that anything other than a hardware failure will shut down Arch AND Ubuntu AND PCLinuxOS AND OpenSuSE all at the same time... And for that I still have a laptop... But it would sure be nice to be able to keep using my favorite distro with a fallback kernel instead of having to boot one of the others. But I do have to agree that more than one fully functional old kernel is a bad idea. Though I don't have much trouble manually deleting the really old ones from Ubuntu's /boot dir... -- | ~^~ ~^~ | <*> <*> Joe (theWordy) Philbrook | ^ J(tWdy)P | \___/ <<jtwdyp@xxxxxxxx>>
