LEAP 15.1 Upgrade from Leap 15.0 :after update system is not usable with its kernel

HI,
after an upgrade from Leap 15.0 to Leap 15.1 if I use kernel 4.12.14-lp151.27-default, my system, under KDE, is totally unusable: cpu busy at 100% quite forever, windows opened and quite never closed, no answer from mouse actions, screen “dirty” etc. etc.
If I use the old kernel (luckily the upgrade did not deleted this one) as an “advanced” choice at the grub menu, i.e. version 4.12.14-lp150.12.61-default, kde starts without problem as usual and the computer is running fine.
I applied all the latest update but the problem is still there.
Thank you for understanding what is happening.

How did you upgrade?

and…

What repositories have you enabled?

sudo zypper lr -d

Hi,
I just upgraded by an iso image dvd, starting with the option upgrade.
My repos are as follows, taking care the I added the repos of Vivaldi, skype, chrome and packman after I rebooted with the old kernel:

±-------------------------------------------------------------------------±--------
1 | openSUSE-Leap-15.1-1 | openSUSE-Leap-15.1-1 | Sì | (r ) Sì | No | 99 | rpm-md | cd:/?devices=/dev/disk/by-id/ata-hp_DVDRW_GUD1N_KZ3GBHN2513 |

2 | packman.inode.at-suse | Packman Repository | Sì | (r ) Sì | Sì | 99 | rpm-md | http://packman.inode.at/suse/openSUSE_Leap_15.1/ |

3 | repo-debug | Debug Repository | No | ---- | ---- | 99 | NONE | http://download.opensuse.org/debug/distribution/leap/15.1/repo/oss/ |

4 | repo-debug-non-oss | Debug Repository (Non-OSS) | No | ---- | ---- | 99 | NONE | http://download.opensuse.org/debug/distribution/leap/15.1/repo/non-oss/ |

5 | repo-debug-update | Update Repository (Debug) | No | ---- | ---- | 99 | NONE | http://download.opensuse.org/debug/update/leap/15.1/oss/ |

6 | repo-debug-update-non-oss | Update Repository (Debug, Non-OSS) | No | ---- | ---- | 99 | NONE | http://download.opensuse.org/debug/update/leap/15.1/non-oss/ |

7 | repo-non-oss | Non-OSS Repository | Sì | (r ) Sì | Sì | 99 | rpm-md | http://download.opensuse.org/distribution/leap/15.1/repo/non-oss/ |

8 | repo-non-oss_1 | Repository Non-OSS | Sì | (r ) Sì | Sì | 99 | rpm-md | http://download.opensuse.org/distribution/leap/15.1/repo/non-oss/ |

9 | repo-oss | Main Repository | Sì | (r ) Sì | Sì | 99 | rpm-md | http://download.opensuse.org/distribution/leap/15.1/repo/oss/ |

10 | repo-oss_1 | Repository principale | Sì | (r ) Sì | Sì | 99 | rpm-md | http://download.opensuse.org/distribution/leap/15.1/repo/oss/ |

11 | repo-source | Source Repository | No | ---- | ---- | 99 | NONE | http://download.opensuse.org/source/distribution/leap/15.1/repo/oss/ |

12 | repo-source-non-oss | Source Repository (Non-OSS) | No | ---- | ---- | 99 | NONE | http://download.opensuse.org/source/distribution/leap/15.1/repo/non-oss/ |

13 | repo-update | Main Update Repository | Sì | (r ) Sì | Sì | 99 | rpm-md | http://download.opensuse.org/update/leap/15.1/oss/ |

14 | repo-update-non-oss | Update Repository (Non-Oss) | Sì | (r ) Sì | Sì | 99 | rpm-md | http://download.opensuse.org/update/leap/15.1/non-oss/ |

15 | repo-update-non-oss_1 | Repository degli aggiornamenti (Non-Oss) | Sì | (r ) Sì | Sì | 99 | rpm-md | http://download.opensuse.org/update/leap/15.1/non-oss/ |

16 | repo-update_1 | Repository principale degli aggiornamenti | Sì | (r ) Sì | Sì | 99 | rpm-md | http://download.opensuse.org/update/leap/15.1/oss |

17 | stable | skype(stable) | Sì | (r ) Sì | Sì | 99 | rpm-md | https://repo.skype.com/rpm/stable/
|
18 | x86_64 | vivaldi | Sì | (r ) Sì | Sì | 99 | rpm-md | http://repo.vivaldi.com/archive/rpm/x86_64
|
19 | x86_64_1 | google-chrome | Sì | (r ) Sì | Sì | 99 | rpm-md | http://dl.google.com/linux/chrome/rpm/stable/x86_64
|

All looks OK …

Strange, I don’t think there is a problem with the 15.1 kernel per se, or there would be more reports of it.

What if you force reinstalled the kernel again, use YaST2 Software Management, select the kernel (default-4.12.14-lp151.27.3), and “Update Unconditionally”.

I reinstalled the kernel, but the exit is the same.
By the way I see the kernel is 4.12.14-lp151.27.3 but it is shown on the grub menu as 4.12.14-lp.151.27 missing the last “3” : is it correct?
In the mean time I noted that I have 3 instances of “lo_kde5filepick” sucking the cpu at 100%. I don’t know if it is useful, while in the running fine kernel (the old one) I still see these program running, but after a while they are not so heavy and it is possible to work without problems.

Yes, that’s correct.

The last digit is a build number. If there were ever a kernel 4.12.14-lp151.27.4, that would just be a recompile of the same sources. And it would be stored with the same filenames in your system.

There was mention of that in this thread: how to disable kde5filepick etc.... - Install/Boot/Login - openSUSE Forums

There was a bug in libreoffice, fixed in 6.1.4.2-1.1

Hi,
I installed the latest available LibreOffice (6.4.2) experimental branch and the load on the CPUs disappeared.
Unfortunately this had no impact on how the system works, i.e. with the latest kernel the machine is quite totally locked, while with the old one it works fine.
Please take care I think the problem is only on the graphical environment (Plasma), because if I change console (i.e. if I go with CTR+SHIFT+F2 for instance) there it seems I can work in text mode without problem.
While in Plasma the problem was that both the keyboard and the mouse seem not respondent: i.e. if I click on a window (a console for instance) the window appears after a while and if I write something nothing happens; then if I iconize the window, after a while the window has been iconized, then If I enlarge it the command I entered before has been executed.
This is with everything: from the buttons on the desktop bar to any other thing on the screen.
Thank you,
regards

By the way, I tried using IceWM as a session, but I had the same things, so I suppose, just suppose, it is something linked to X and the kernel and not linked to Plasma.

Very weird… as I wrote previously I don’t think there is a problem with the 15.1 kernel per se, or there would be more reports of it.

Also the two kernels are essentially the same version 4.12.14 (4.12.14-lp150.12.61-default and 4.12.14-lp151.27-default).

Can you spot anything obvious from any of the logs ?

~/.xsession-errors

/var/log/Xorg.0.log (or Xorg.0.log.old)

or from the journal for an offending boot

sudo sudo journalctl -b -*boot_number*

you can obtain the boot_number by using

sudo journalctl --list-boots

Whoops… I seem to have stuttered on “sudo” lol! …

@gio_kheper

Just a thought…

It would probably be a good idea to edit “/etc/zypp/zypp.conf” and add the option “oldest” to the line beginning “multiversion.kernels =” so as to keep your working version of the kernel on your machine.

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

Hi,unfortunately I read your message late, so wrongly I made an update and now I have kernel 4.12.14 lp.151.28.4 that is wrong as the …lp151.27 so now I have nothing working.
However the I had no errors about X (file.xerrors is void).
I have ready the tgz of the other file you cited: please let me know how I can attach that file here.
Thank you again

Another strange thing. If I create a new user and I try to login with it, in graphic mode, there is no problem.
So I think I have to investigate on my programs running in my session.
However the oddity is that was enough to change a subversion of the kernel to see that nothing was working.

OK… so it’s something in your user profile.

For starters: from the command line try deleting the contents of ~/.cache for your original non-working user.

rm -rf ~/.cache/*

Please note the following upgrade documentation: <https://doc.opensuse.org/documentation/leap/startup/html/book.opensuse.startup/cha.update.osuse.html&gt;.
And, the following Support Database (SDB) article: <https://en.opensuse.org/SDB:System_upgrade&gt;.
In general:

   YaST shows a list of Previously Used Repositories.       By default all repositories will get removed. If you had not added any       custom repositories, do not change the settings. The packages for the       upgrade will be installed from DVD and you can optionally enable the       default online repositories can be chosen in the next step.      
   **If you have had added custom repositories**, for example from the       openSUSE Build Service, you have two choices:
  • Leave the repository in state Removed. Software that was installed from this repository will get removed during the upgrade. Use this method if no version of the repository that matches the new openSUSE Leap version, is available.
  •      Update and enable the repository. Use this method if a version that         matches the new openSUSE Leap version is available for the         repository. Change it's URL by clicking the repository in the list and         then Change. Enable the repository afterwards by         clicking Toggle Status until it is set to         Enable. 
    

Do not use repositories matching the previous version unless you are absolutely sure they will also work with the new openSUSE version. If not, the system may be unstable or not work at all.

My view is:

  • During a system upgrade, document exactly the existing repositories and packages and, do not attempt to upgrade any packages which have been installed from custom repositories.
  • After the upgrade has been performed and, the new system version is running correctly and, “/usr/sbin/rpmconfigcheck
    ” has been executed and, all the upgraded configuration files have been correctly checked for changes which have occurred due upgraded packages and, the configuration changes have been dealt with (don’t complain – this usually needs an hour or two of effort … ) and, the system has been rebooted (without any errors … ), then,

Add the custom repositories (if needed – the upgrade may have introduced the correct, newest, versions of the applications which were previously only available by means of the custom repositories … ) and then, reinstall the applications/packages which are only available from custom repositories.

Hi, thank you all, but I was away from the machine I have access only now.
I cleaned the cache, but this lead to nothing new (i.e. everything was wrong as usual).
After that I acted in a radical way, cleaning all the config so that I have a quite neat picture and from that I will try adding a piece of my config trying to understand what was happening and from the moment I can use it.
Thank you I will keep understanding better what I have to consider when upgrading, looking in a deeper way to the “custom” things.
However the strange things that happened to me were linked to an upgrade, but I was able to see everything running fine with a not so old previous kernel, while running everything else from the upgraded Leap 15.1.

A lot of strange things are happening…
After i cleaned everything I tried to put everything as I was used, but the system locked after a while. So I tried in a more systematic way.
At first glance there was no problem if I was using desktop on folder view mode, but if I move to folder view I got the lock.
I was thinking it was a problem of Skype requesting the use of the wallet, but it stopped even if I did not use it.
Another possible indict was Kget, and in effect after i set it up as working with Konqueror, my system crashed.
Please consider that often the crash is after some minutes of use.
After that I tried to put a widget after another, everytime testing at least skype, and stopping and rebooting the machine. It was all ok.
My widgets are: folderView,Kcalc,CpuMonitor, NetworkMonitor, AnalogClock and Weather Station.
Sure, I do not know because my system was locked because it is the same that is running now: I keep my fingers crossed till the next boot.

After a day it seems everything is working. My main suspect, but without any proof of it, is that it was due to some interactions with skype itself or to the claim by skype to the wallet, because initially I had problems while not using Plasma but just IceWM.

Thanks for the updates. Pleased you have it working now :slight_smile:

I neither use or am familiar with skype, so can’t comment on the likelihood of that being the cause of your problems.

In terms of the way you did the upgrade, I don’t believe you did anything “wrong”, it was rather unfortunate you suffered the problems.