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@xxxxxxxxxxxxxx>
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
