Bug 1175090 - adapt default zypp.conf multiversion.kernels section to keep last iteration of prior major release installed longer
Summary: adapt default zypp.conf multiversion.kernels section to keep last iteration o...
Status: NEW
Alias: None
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Basesystem (show other bugs)
Version: Current
Hardware: Other Other
: P5 - None : Enhancement (vote)
Target Milestone: ---
Assignee: Lubos Kocman
QA Contact: E-mail List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-08-11 05:16 UTC by Felix Miata
Modified: 2020-08-20 09:53 UTC (History)
1 user (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Felix Miata 2020-08-11 05:16:37 UTC 
original summary:
adapt default zypp.conf multiversion.kernels section to keep last iteration of prior major release installed longer

This is for those who for whatever reason do not use BTRFS and/or snapper.

multiversion.kernels = latest,latest-1,running often isn't long enough.

Recent example:
sumarized/described:
1-newly installed via zypper dup 5.7.x kernel did not work satisfactorily
2-installed another kernel to see if a solution, thereby eliminating latest-2 that did work
3-noboot with either kernel

Detail:
<https://forums.opensuse.org/showthread.php/542872-Plasma-desktop-black-screen-with-cursor-only-after-update-to-kernel-5-7>

IOW, if 5.6.x had still been automatically kept on the installed system, non-bootability could have been avoided, or restored more easily. Yes, booting previous kernel would have worked, but that option slips away too easily, with prior kernel boot option squirreled away in Grub's "Advanced" options instead of in front of a frustrated user's face every boot.