Home_greyopenFATE - openSUSE feature tracking > #312647
Dashboard | Search | Sign up | Login

Please login or register to be able to edit or vote this feature.

Preserve Running Kernel On Kernel Update by Default

Feature state

openSUSE Distribution
Done

Description

My suggestion is to enable multiversion kernel & preserve running kernel for safer kernel updates, to reduce support problems when new kernels won't boot. This is now possible for 12.1 by 1 line change to zypp.conf.

Since Online Update was first introduced (SuSE 7.1?) it replaced the running kernel by default, which can lead to problems booting. For a while multiversion kernel has been supported by libzypp (1 line edit in zypp.conf). The drawback with multiversion was manual deletion required of unwanted kernel packages (see http://lists.opensuse.org/opensuse-kernel/2011-07/msg00056.html ). Now in Factory 12.1 M3 Michel Marek has included & announced - kernel package retention options (see http://lizards.opensuse.org/2011/07/14/improved-kernel-package-retention-in-12-1/ ).

The default is sane, to preserve the Lastest & Running Kernels. So lets use it and make 12.1 kernel updates safer for all, and by default do the right thing!

User benefit:

To reduce support caused by kernel upgrade "accidents".
To encourage safer testing of Kernel Team "stable" & "HEAD" kernels.

To correct a long standing risky choice, made for implementation convenience of deleting old kernel package, before the new was tested.

Relations

  • Duplicate of feature #314903:

Usecase

End user upgrades kernel to Tumbleweed and it fails to boot.

With kernel package retention, the running kernel was not deleted before reboot and recovery is simply a matter of choosing the "good" kernel from GRUB menu and reporting the issue, rather than figuring out system recovery.

Discussion


icons/user_comment.png M. M. wrote: (6 years ago)

Note that there are multiple ways a kernel can "fail" for the user. Right now, the purge-kernels script is run after boot.localfs, that does not help you if e.g. X doesn't work anymore. To be fully bullet proof, the script would need to be triggered much later, e.g. once the user logs in and there is network connectivity. But even the current implementation can help in many cases.

icons/user_comment.png R. D. wrote: (6 years ago)

So the issues of module loading failing, after kernel update would be solved.
Many hardware boot issues where udev hangs also solved.
For X11 not starting, even simply altering the default set for "purge-kernels" to :

multiversion.kernels = latest,latest-1,running

or :

multiversion.kernels = latest, oldest, running

Would preserve 2 "working" kernels after an update; without any coding changes. The oldest being treated as "golden" generally installation kernel without user intervention.

icons/user_comment.png S. B. wrote: (5 years ago)

The Linux backline people teams from EMEA and US discussed this on their regular meeting on Wednesday two weeks ago and we agreed that we propose that too for the next SLE Service Pack.
It would be great to have this, because boot issues with an updated kernel have several downsides:

- they come in as high severity
- customers are often not capable to use the rescue system or other tools
- the variety of issues is to big to write a simple troubleshooting guide
- fixing issues over the phone or chat takes a very long time when directing customers through steps to get the system fixed

Last change: 12 months ago
Voting
Score: 25
  • Negative: 1
  • Neutral: 0
  • Positive: 26
Feature Export
Application-xmlXML   Text-x-logPlaintext   PrinterPrint