[arch-general] Reboot - Versioned Kernel Installs

[Jelle van der Waa]

On 06/08/2011 04:12 PM, Paul Gideon Dann wrote:
> I would really like to the kernel that is being replaced kept as a backup.  If
> the latest kernel breaks your hardware, or something else goes wrong, I'd like
> to have the option of using the kernel that was just replaced, because it's
> known to work.
>
> I wouldn't want more than one old version of the kernel, though.
>
> Also, although the -lts kernel is good for this, it isn't intended to solve
> this problem, and isn't always a perfect fit.  For instance, my new laptop has
> UEFI-related issues that are only being addressed in the *very* latest
> kernels.  I'm not sure -lts would boot for me, but I know that my *current*
> kernel boots; seems a pity to throw it out it straight away on upgrade, before
> I can test that the new kernel boots OK...
>
> Paul
>
If you want this, implement it! I have seen some discussions about it 
and it always tend to users wanting feature X or Y, but didn't commit to 
it.
protip: iirc there are some threads about this on the mailing list, the 
forums  and the bugtracker, start gathering info there.

good luck!

> On Monday 06 June 2011 18:23:50 Tom Gundersen wrote:
>> On Mon, Jun 6, 2011 at 6:22 PM, Tavian Barnes<tavianator at tavianator.com>
> wrote:
>>> I have kernel26-lts installed as a backup kernel, and this is all
>>> that's really necessary for rolling back broken kernel updates.  I've
>>> been bitten by a BTRFS bug once and rolled back with -lts no problem.
>>> -1 from me on keeping multiple kernel versions installed; I really
>>> like that arch doesn't keep 6 old kernels around.
>> I agree.
>>
>> The reason I am against keeping old kernels around is that we would
>> not be able to test user space against all the possible combinations,
>> so it would not be a good idea to suggest that we do (we do try to
>> support all sorts of self-compiled kernels, but at least if you
>> compile your own kernel it is pretty obvious that it will not be as
>> well tested as the "official" ones).
>>
>> One possibility would be to do like upstream does and always rename
>> the previous kernel to .old. That should keep the last known working
>> kernel around while making it clear that it should not be relied on
>> for day-to-day use (and that it will get overwritten on the next
>> kernel upgrade so these things won't get old).
>>
>> That said, I'm not involved with packaging the kernel, so if you want
>> anything to change with how it is packaged (maybe after this
>> discussion is over), it would be best to file a feature request on FS.
>>
>> Cheers,
>>
>> Tom


-- 
Jelle van der Waa