Help for full recovery of Gnome Settings after faulty kernel installation

English Install/Boot/Login
1

After finally succeeding to recover after installation of the faulty kernel version 5.3.18-150300.59.43.1.150300.18.27.1, my Gnome Settings version no longer provides the feature to configure dual displays (“Display Unknown”).

How can this be restored? I have looked at the ‘warn’ log from the boot, but have no clue what it is telling me.

Gnome Version 3.34.7
Memory 3.4 GiB
Intel® Pentium(R) D CPU 2.80GHz × 2
llvmpipe (LLVM 11.0.1, 128 bits)
Radeon HD 6450 1 GB DDR3

I notice that llvm11 itself is not installed. Do I need it perhaps?

2

In the main thread on the subject of the faulty kernel, the advice was given to install an older kernel to overcome this problem (perhaps). That seems like a sledgehammer to crack a nut, but in the absence of other suggestions I am contemplating trying it.

What steps are necessary to find and install a kernel, say 5.3.18-150300.59.39*?
What about the alternative to install from the Leap 15.3-2 DVD? (…and then take 6 or 7 months worth of updates!). Would that work?

3

Open Yast Software Management.

Search for “kernel-default”.

Click on the “Versions” tab, and select the version that you want to install.

Then, in a root terminal, look at “/boot” and remove the file “do-purge-kernels” (I hope I remembered the name correctly). That’s to avoid your new kernel being automatically removed on the next boot. That will give you time to try it out and decide whether you want to keep it.

4

I selected the kernel I wanted (*40) and clicked OK. But in the /boot directory there is no file called “do-purge-kernels” or anything like that. What now?

ls
boot.readme                              sysctl.conf-5.3.18-59.40-default
config-5.3.18-150300.59.43-default       System.map-5.3.18-150300.59.43-default
config-5.3.18-150300.59.43-preempt       System.map-5.3.18-150300.59.43-preempt
config-5.3.18-59.40-default              System.map-5.3.18-59.40-default
efi                                      vmlinux-5.3.18-150300.59.43-default.gz
grub2                                    vmlinux-5.3.18-150300.59.43-preempt.gz
initrd                                   vmlinux-5.3.18-59.40-default.gz
initrd-5.3.18-150300.59.43-default       vmlinuz
initrd-5.3.18-150300.59.43-preempt       vmlinuz-5.3.18-150300.59.43-default
initrd-5.3.18-59.40-default              .vmlinuz-5.3.18-150300.59.43-default.hmac
symvers-5.3.18-150300.59.43-default.gz   vmlinuz-5.3.18-150300.59.43-preempt
symvers-5.3.18-150300.59.43-preempt.gz   .vmlinuz-5.3.18-150300.59.43-preempt.hmac
symvers-5.3.18-59.40-default.gz          vmlinuz-5.3.18-59.40-default
sysctl.conf-5.3.18-150300.59.43-default  .vmlinuz-5.3.18-59.40-default.hmac
sysctl.conf-5.3.18-150300.59.43-preempt
5

The “do-purge-kernels” is a temporary file. It disappears on the next boot.

You probably rebooted before checking.

You might want to edit “/etc/zypp/zypp.conf” (as root), and modify the line:

multiversion.kernels = latest,latest-1,running

so that it instead reads

multiversion.kernels = oldest.latest,latest-1,running

That’s just adding “oldest,”.

This will make sure that your 5.3.18-59.40 kernel is not deleted after the next kernel update. Since you depend on being able to fall back to that kernel, best to keep it around.

6

Hmmm…no I didn’t reboot before checking /boot. YaST advised me to, of course, but I held back and still haven’t rebooted yet, waiting for your reply about the missing file. Actually, I am doubtful that changing the kernel version is the solution to my problem, since my system is running on *43 at the moment. My problem is that since I completed the bug correction as advised my system boots again ‘successfully’, except that my dual displays are now ‘unconfigurable’ (by Gnome Settings) is corrupted and there have been no suggestions how to recover this. The radical idea to go back to an earlier kernel is really a last resort. I would prefer for some help to troubleshoot the reason for the missing display configuration and act rationally on that basis.

7

Please mind, that is a , (as in the last line), not a . (as in the CODE example)!

8

Oops. My goof.

9

OK Got it! oldest,latest NOT oldest.latest. Thanks. I would have fallen for the mistake.:\

Is the oldest the last one in the YaST ‘Versions’ list (i.e. 5.3.18.59-30.1) or the one with the lowest version number 5.3.18.59-5.2 (which is higher in the list)? Or are we talking about the versions shown in the YaST package list, or even the ones in /boot list which are only *43 and *40 anyway.

10

Reverting to kernel *40 from *43 has not helped resolve my Gnome Display Settings issue.

I could postulate another cause of the problem. Namely, whilst I was recovering from the faulty kernel *43 update, there was some advice that I should delete kernel *43 and lock fall-back kernel *40. I started to follow that advice but changed my mind while YaST was busy deleting and installing the relevant packages. I wasn’t really convinced that that was a good idea and aborted the procedure before it went to conclusion, on the assumption (from previous experience) that YaST would make an orderly roll-back to the out-going status. Could I have been mistaken in that assumption?

Another question. Why does to grub boot sequence say that kernel version 5.3.18.59-43*-preempt is being loaded when I am expecting *40-default?

11

It is the one with the lowest version number amongst installed kernels. In your case, it is *40.

If a new kernel comes along, say *46, then normally you would be left with only the two latest kernels (*43 and *46). Adding that oldest makes sure that you also keep the *40. It’s a safety measure until you are sure that the newest kernel is working properly for you.

12

Thanks for the clarification.
Another question: Shouldn’t the version of the kernel-default always be the same as the the kernel-default-base?

YaST shows the installed kernel-default as *43 and kernel-default-base is now *34, update to *43 being ‘available’. If I try to update the kernel-default-base to *43 I get a dependency conflict message with a recommendation to deinstall kernel-default *43. But kernel-default *34 is not selected in my YaST Versions list. Is this normal?

(I have selected several lower kernel-default versions in turn, so that I have now landed at kernel-default-base *34, but in spite of supposed lower versions of kernel-default, *43 remains the installed version, also after reboot each time).

13

Success!! Having deliberately chosen kernel-default *37 during boot, my system now boots up ‘properly’ with dual displays and normal Gnome Settings functions.

  1. How do I make kernel-default *37 my default?
  2. What risks must now be avoided in bringing the kernel up to date?
14

As best I understand it, “kernel-default-base” should not be installed at all. It sometimes gets installed to solve a conflict, but that’s usually a mistake.

Try uninstalling it. If that causes conflicts, then other actions might be needed.

If that is your oldest kernel, then it should be the one retained by the “oldest,” entry in “/etc/zypp/zypp.conf”. I’m not sure whether that older “kernel-default-base” interferes with that. As long as you always boot that kernel first after a kernel update, it will also be retained as the “running” kernel.

I think you can use Yast bootloader to set the default boot line.

15

I am finding it difficult to understand what is going on what I should do to get back to a ‘clean’ system. I don’t want to shoot myself in the foot, by deleting or installing things that I shouldn’t. I’ve been there…:shame:

Here is my status now…

uname -r 
5.3.18-59.37-default

YaST shows the following packages are in my system:
kernel-default (Installed 5.3.18-150300.59.43.1) (Version list: *43.1, *40.1, *37.2)
kernel-default-base (installed 5.3.18-59.34.1.18.21.1, available 5.3.18-150300.59.43.1.150300.18.27.1)(Version list *34 only)
kernel-default-extra (installed 5.3.18-150300.59.43.1) (Version list *43, *40.1)
kernel-default-optional (installed ditto) (Version list *43, *40)

Nothing here makes sense to me, and even stranger things happen, for example, if I click to delete the installed kernel-default (*43) package then all three in the version list are also earmarked for deletion, and the available kernel-default-base package is flagged for installation. What is going on? Is this an integral system? If not, what is the best way to do to get there with minimum risk?

16

That has to do with the way that kernel packages are handled.

To delete a specific kernel, you need to use the “Versions” tab and select which to delete there. Otherwise it wants to delete all. It is probably the same for “kernel-default-base”.

17

Managed at last. There was apparently a inconsistent dependency between kernel-default *43.1 and kernel-default-base *43.1. I spent a whole morning trying to find out how to delete either one or both without invalidating my system. In the end both had to go. and my system works correctly on *40.1. (although the base package is not installed)

Many thanks for everyone’s support!!

One final (?) question: Now the YaST search for available update packages suggests kernel default *43.1 and kernel-preempt *43.1 together wit the corresponding *-extra and *-optional ones. Is it risky to install them now, or are we sure the error has been corrected?

18

Do not install a preempt kernel.

19

I suggest you wait. When the problem has been corrected, it will be a different kernel version (higher than 43).

20

Thanks for this tip and the henks on preempt.