Notes on the 15.2 Upgrade
I finally got around to the 15.1>15.2 upgrade the other day using the iso image on dvd, and here's a few notes. I'd like to hear what people think. I initially tried to update all repositories before the upgrade, but I must have messed up the pacman url, because it was not found and I had conflicts. I tried to use the back button to fix it, but couldn't find my back to the right spot, and decided to be conservative and start again with just the dvd. I ended up with conflicts anyway and resolved them one by one. The result was about 400 packages deleted. A lot of them were development packages and debuginfo and whatnot. I haven't looked further yet. After the upgrade I used Yast to switch to pacman, and it did pull some packages back in. I also used Yast for a serious online update. BTW, I noticed the main repository does not carry some chess packages such as xboard; they are only available from pacman. I then noticed about 600 packages still had an "x-lp151.x" sort of moniker-- zypper up took care of that. KDE's notification system isn't working due to a problem with xfce as described here: https://forums.opensuse.org/showthread.php/543232-Lost-notifications . I'm not entirely happy with the proposed solutions. I seem to recall KDE notification problems before, perhaps with 15.0, or maybe 42.0, where my system would fall back to xfce notifications until the KDE problems were fixed. That seemed like a nice behavior, all in all. ksysguard has gone from maybe 6-8% of one CPU to 30-40%. I've always tended to leave that running on one desktop, but 30-40% is unacceptable. It also apparently replaced my file read/write columns with Download/Upload. I have a CPU temp monitor in one of the panels that is not working. Any attempt to open its configuration dialog crashes plasmashell. Then there's akonadi. Akonadi_imap_resource, akonadiserver, and mysqld hog CPU continually on admittedly very large gmail folders until such time as akonadiserver "closes unexpectedly". I've also suddenly got 1131-300-200-100-300 emails in a drafts folder as reported variously by kontact and xfce. None of them are visible. Akonadi server somehow restarts itself. Hey, I can't watch Netflix while akonadi is running! At times past, I've bumped akonadi's priority down a notch. I haven't mentioned bluetooth which has been an ongoing problem for a long time. I've successfully nursed it in the past with restarts and whatnot, but I don't want to get into that at the moment. I used to use serial over bluetooth a lot, as well as tethering to my phone, but for the moment, it's a bit beyond me. So, comments? I can follow up on my downtime, keeping in mind that it will take time away from watching Netflix! ;-)
On 19/02/2021 08.57, Robert Hardy wrote:
I finally got around to the 15.1>15.2 upgrade the other day using the iso image on dvd, and here's a few notes. I'd like to hear what people think.
Instructions here ;-) https://en.opensuse.org/SDB:Offline_upgrade
I initially tried to update all repositories before the upgrade,
Before the upgrade means before booting the DVD. I understand you mean tried to update the repositories URLS from inside the DVD session. No, that is prone to failure. You have to update the repositories URLS by editing the .repo files from inside the running Leap 15.1 before booting the DVD, as explained here: https://en.opensuse.org/SDB:System_upgrade#Command_line_2 cd /etc/zypp/repos.d/ For every .repo file: Make sure you are NOT using the new ${releasever} syntax.⁽¹⁾ Edit every 15.1 entry with 15.2 Finally, run "zypper clean ref --force" to check that the URLs are correct. Then, boot the DVD. (1) https://bugzilla.opensuse.org/show_bug.cgi?id=1181965 In the DVD, you have to make sure that network is configured.
but I must have messed up the pacman url, because it was not found and I had conflicts. I tried to use the back button to fix it, but couldn't find my back to the right spot, and decided to be conservative and start again with just the dvd. I ended up with conflicts anyway and resolved them one by one.
Just the DVD and having repositories causes problems.
The result was about 400 packages deleted. A lot of them were development packages and debuginfo and whatnot. I haven't looked further yet.
Like that problem.
After the upgrade I used Yast to switch to pacman, and it did pull some packages back in. I also used Yast for a serious online update. BTW, I noticed the main repository does not carry some chess packages such as xboard; they are only available from pacman.
I then noticed about 600 packages still had an "x-lp151.x" sort of moniker-- zypper up took care of that.
Maybe. Run this query in a terminal (konsole): rpm -q -a --queryformat "%{INSTALLTIME}\t%{INSTALLTIME:day} \ %{BUILDTIME:day} %-30{NAME}\t%15{VERSION}-%-7{RELEASE}\t%{arch} \ %25{VENDOR}%25{PACKAGER} == %{DISTRIBUTION} %{DISTTAG}\n" \ | sort | cut --fields="2-" | tee rpmlist \ | egrep -v "openSUSE Leap 15\.2|openSUSE_Leap_15.2|\-lp152" | less -S That will list /possible/ packages that were not upgraded, and you have to tend to them. Most will be GPG signatures. (on the other things, I can't comment. Except that you are not the only one to bump into akonadi) -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
On Friday, February 19, 2021 4:21:47 AM CST Carlos E.R. wrote:
On 19/02/2021 08.57, Robert Hardy wrote:
[...]
I then noticed about 600 packages still had an "x-lp151.x" sort of moniker-- zypper up took care of that.
Maybe. Run this query in a terminal (konsole):
rpm -q -a --queryformat "%{INSTALLTIME}\t%{INSTALLTIME:day} \ %{BUILDTIME:day} %-30{NAME}\t%15{VERSION}-%-7{RELEASE}\t%{arch} \ %25{VENDOR}%25{PACKAGER} == %{DISTRIBUTION} %{DISTTAG}\n" \
| sort | cut --fields="2-" | tee rpmlist \ | egrep -v "openSUSE Leap 15\.2|openSUSE_Leap_15.2|\-lp152" | less -S
That will list /possible/ packages that were not upgraded, and you have to tend to them. Most will be GPG signatures.
I tried using susepaste for that, but I can't. It seems I am a spammer: Sun Oct 21 2018 Mon May 05 2014 gpg-pubkey 3dbdc284-53674dd4 (none) > Sun Oct 21 2018 Thu Mar 15 2018 gpg-pubkey 307e3d54-5aaa90a5 (none) > Sun Oct 21 2018 Wed Dec 07 2016 gpg-pubkey 39db7c82-5847eb1f (none) > Sun Oct 21 2018 Fri Sep 29 2017 gpg-pubkey b3fd7e48-59ce8353 (none) > Fri Oct 26 2018 Wed Mar 09 2011 gpg-pubkey 6867f5be-4d77cecd (none) > Fri Oct 26 2018 Mon Sep 15 2014 gpg-pubkey 1abd1afb-54176598 (none) > Mon Jun 10 2019 Fri Mar 15 2019 libgsl23 2.4-lp151.4.1 x86_64 > Mon Jun 10 2019 Mon Dec 17 2018 libgwenhywfar60 4.18.0-lp151.2.4 x86_64 > Wed Oct 23 2019 Tue Oct 22 2019 libfdk-aac1 0.1.6-lp151.2.2 x86_64 http://packman.li> Sun Mar 29 2020 Sat Mar 28 2020 libx264-155 0.155svn20190201-pm151.3.1 x86_64 http://packman.li> Sun Mar 29 2020 Wed Mar 18 2020 libx265-179 3.2.1-pm151.3.3 x86_64 http://packman.li> Sun Mar 29 2020 Sun Mar 29 2020 libx265-188 3.3-pm151.1.1 x86_64 http://packman.li> Sun Apr 12 2020 Tue Mar 31 2020 libicu60_2-ledata 60.2-lp151.3.11.1 noarch > Sun Apr 12 2020 Tue Mar 31 2020 libicu60_2 60.2-lp151.3.11.1 x86_64 > Fri Jun 05 2020 Thu Jun 04 2020 libgpac8 0.8.0-pm151.1.10 x86_64 http://packman.li> Sat Jul 11 2020 Fri Jul 10 2020 libx264-159 0.159+git20191127.1771b556-pm151.3.1 x86_64 http://pa> Mon Nov 02 2020 Sat Oct 31 2020 libx264-160 0.160+git20200702.cde9a933-pm151.1.2 x86_64 http://pa> Thu Dec 10 2020 Mon Dec 07 2020 libical2 2.0.0-lp151.3.3.1 x86_64 > Fri Dec 11 2020 Sun Dec 06 2020 gpg-pubkey d4d81407-5fcd2707 (none) > Thu Jan 21 2021 Mon Dec 17 2018 libhwloc5 1.11.8-lp151.2.3 x86_64 > Wed Feb 17 2021 Mon Feb 24 2020 libdvdcss2 1.4.2-1.3 x86_64 VideoLAN Project (http://> A quick look shows libgsl23 for example is an orphan, and can probably be safely deleted. All in all, it's no surprise packages were deleted. It's a bigger surprise some weren't. In addition to pacman and debuginfo/debugsource repositories etc., I had only one, obs://build.opensuse.org/home:munix9 , from which I drew celestia. I would have expected that to be deleted, but no, it's fully up to date.
(on the other things, I can't comment. Except that you are not the only one to bump into akonadi)
Still running. Those draft message reports have disappeared. I notice kontact reports updating a new "Unified Mailboxes" folder, which is at 0% after two days runtime.
On 19/02/2021 20.05, Robert Hardy wrote:
On Friday, February 19, 2021 4:21:47 AM CST Carlos E.R. wrote:
On 19/02/2021 08.57, Robert Hardy wrote:
[...]
I then noticed about 600 packages still had an "x-lp151.x" sort of moniker-- zypper up took care of that.
Maybe. Run this query in a terminal (konsole):
rpm -q -a --queryformat "%{INSTALLTIME}\t%{INSTALLTIME:day} \ %{BUILDTIME:day} %-30{NAME}\t%15{VERSION}-%-7{RELEASE}\t%{arch} \ %25{VENDOR}%25{PACKAGER} == %{DISTRIBUTION} %{DISTTAG}\n" \
| sort | cut --fields="2-" | tee rpmlist \ | egrep -v "openSUSE Leap 15\.2|openSUSE_Leap_15.2|\-lp152" | less -S
That will list /possible/ packages that were not upgraded, and you have to tend to them. Most will be GPG signatures.
I tried using susepaste for that, but I can't. It seems I am a spammer:
Yeah, it does that {chuckle smiley} Next time, instead of pasting from display, redirect to file and attach it. I can see that part of the line at the right side was lost.
Sun Oct 21 2018 Mon May 05 2014 gpg-pubkey 3dbdc284-53674dd4 (none)
These you can ignore.
Mon Jun 10 2019 Fri Mar 15 2019 libgsl23 2.4-lp151.4.1 x86_64 Mon Jun 10 2019 Mon Dec 17 2018 libgwenhywfar60 4.18.0-lp151.2.4 x86_64
I don't know what those two are, but you need updating them.
Wed Oct 23 2019 Tue Oct 22 2019 libfdk-aac1 0.1.6-lp151.2.2 x86_64 http://packman.li> Sun Mar 29 2020 Sat Mar 28 2020 libx264-155 0.155svn20190201-pm151.3.1 x86_64 http://packman.li> Sun Mar 29 2020 Wed Mar 18 2020 libx265-179 3.2.1-pm151.3.3 x86_64 http://packman.li> Sun Mar 29 2020 Sun Mar 29 2020 libx265-188 3.3-pm151.1.1 x86_64 http://packman.li>
These will probably show in red in YaST; in that case, remove them.
Sun Apr 12 2020 Tue Mar 31 2020 libicu60_2-ledata 60.2-lp151.3.11.1 noarch > Sun Apr 12 2020 Tue Mar 31 2020 libicu60_2 60.2-lp151.3.11.1 x86_64 > Fri Jun 05 2020 Thu Jun 04 2020 libgpac8 0.8.0-pm151.1.10 x86_64 http://packman.li> Sat Jul 11 2020 Fri Jul 10 2020 libx264-159 0.159+git20191127.1771b556-pm151.3.1 x86_64 http://pa> Mon Nov 02 2020 Sat Oct 31 2020 libx264-160 0.160+git20200702.cde9a933-pm151.1.2 x86_64 http://pa> Thu Dec 10 2020 Mon Dec 07 2020 libical2 2.0.0-lp151.3.3.1 x86_64 > Fri Dec 11 2020 Sun Dec 06 2020 gpg-pubkey d4d81407-5fcd2707 (none) > Thu Jan 21 2021 Mon Dec 17 2018 libhwloc5 1.11.8-lp151.2.3 x86_64 > Wed Feb 17 2021 Mon Feb 24 2020 libdvdcss2 1.4.2-1.3 x86_64 VideoLAN Project (http://>
All those, check if there is an upgrade; the libx[NUMBER] will have a library with a bigger number installed, so just remove them. libdvdcss2 is probably correct, just follows a different naming convention.
A quick look shows libgsl23 for example is an orphan, and can probably be safely deleted. All in all, it's no surprise packages were deleted. It's a bigger surprise some weren't.
Right :-)
In addition to pacman and debuginfo/debugsource repositories etc., I had only one, obs://build.opensuse.org/home:munix9 , from which I drew celestia. I would have expected that to be deleted, but no, it's fully up to date.
(on the other things, I can't comment. Except that you are not the only one to bump into akonadi)
Still running. Those draft message reports have disappeared. I notice kontact reports updating a new "Unified Mailboxes" folder, which is at 0% after two days runtime.
I don't know, I use Thunderbird. Fewer surprises. -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
On 2021-02-19 2:57 a.m., Robert Hardy wrote:
I finally got around to the 15.1>15.2 upgrade the other day using the iso image on dvd, and here's a few notes. I'd like to hear what people think.
It sounds like more and more reasons not to do it. Not just this but many other reports. I admit that 15.1 hasn't been the greatest; as many have commented there are swap problems and I can't keep it running for more that a day or if I use much video: play a couple of DVDs or watch much on Firefox or YouTube. Yes, there have been many other reports of problems with upgrade. It doesn't seem worth it. Perhaps openSUSE is running out of steam and it's worth looking again at Fedora or Malveria -- “Reality is so complex, we must move away from dogma, whether it’s conspiracy theories or free-market,” -- James Glattfelder. http://jth.ch/jbg
On Friday, February 19, 2021 5:44:32 AM CST Anton Aylward wrote:
Firefox...
Ongoing problem with Firefox. It tends to lose track of network connections, especially but not exclusively of the hotplugging variety, and has to be restarted. (Possibly also with a renewed wifi lease?) Same for ksysguard, guaranteed. It doesn't register new connections while running.
Anton Aylward wrote:
On 2021-02-19 2:57 a.m., Robert Hardy wrote:
I finally got around to the 15.1>15.2 upgrade the other day using the iso image on dvd, and here's a few notes. I'd like to hear what people think.
It sounds like more and more reasons not to do it. Not just this but many other reports.
Maybe just for balance, let me report the opposite - I have upgraded three ARM Boards, two laptops, four desktops, some virtual machines, a couple of physical servers - no problems. All of the openSUSE infrastructure was also upgraded to 15.2 not long ago. -- Per Jessen, Zürich (12.3°C)
I finally got around to the 15.1>15.2 upgrade the other day using the iso image on dvd, and here's a few notes. I'd like to hear what people think. a reasonable thought I initially tried to update all repositories before the upgrade, but I must have messed up the pacman url, because it was not found and I had conflicts. I tried to use the back button to fix it, but couldn't find my back to the right spot, and decided to be conservative and start again with just the dvd. I ended up with conflicts anyway and resolved them one by one.
The result was about 400 packages deleted. A lot of them were development packages and debuginfo and whatnot. I haven't looked further yet. This is not unusual if you used a lot of particular repos. I cannot confirm so many packages, the main part of my upgrade (done via zypper however) at the time was smooth. After the upgrade I used Yast to switch to pacman, and it did pull some packages back in. I also used Yast for a serious online update. BTW, I noticed the main repository does not carry some chess packages such as xboard; they are only available from pacman. The offer between vendors seems to change all the time. I expect a major remix with the 15.3 as the code base AFAIU will change quite a lot. I then noticed about 600 packages still had an "x-lp151.x" sort of moniker-- zypper up took care of that.
In data venerdì 19 febbraio 2021 08:57:25 CET, Robert Hardy ha scritto: that is odd. But not related to the problems now listed below.
KDE's notification system isn't working due to a problem with xfce as described here: https://forums.opensuse.org/showthread.php/543232-Lost-notifications . I'm not entirely happy with the proposed solutions. I seem to recall KDE notification problems before, perhaps with 15.0, or maybe 42.0, where my system would fall back to xfce notifications until the KDE problems were fixed. That seemed like a nice behavior, all in all. I do not use xfce so I cannot tell. ksysguard has gone from maybe 6-8% of one CPU to 30-40%. I've always tended to leave that running on one desktop, but 30-40% is unacceptable. It also apparently replaced my file read/write columns with Download/Upload. I confirm this.
I have a CPU temp monitor in one of the panels that is not working. Any attempt to open its configuration dialog crashes plasmashell. I can confirm this too.
Then there's akonadi. Akonadi_imap_resource, akonadiserver, and mysqld hog CPU continually on admittedly very large gmail folders until such time as akonadiserver "closes unexpectedly". I've also suddenly got 1131-300-200-100-300 emails in a drafts folder as reported variously by kontact and xfce. None of them are visible. Akonadi server somehow restarts itself. Hey, I can't watch Netflix while akonadi is running! At times past, I've bumped akonadi's priority down a notch. This was the reason why I had to give up two times the upgrade to 15.2 and switched back to 15.1. It is also the reason why I will skip all together 15.2. My personal experience is that with 15.2 and KDE you are not getting your work done.
I haven't mentioned bluetooth which has been an ongoing problem for a long time. I've successfully nursed it in the past with restarts and whatnot, but I don't want to get into that at the moment. I used to use serial over bluetooth a lot, as well as tethering to my phone, but for the moment, it's a bit beyond me. This appears to be a problem of KDE and pulseaudio. While the issue with audioprofiles is quite old, I am quite worried to see that in Tumbleweed currently since some time the BT support is practically broken with a strongly reduced functionality and an odd looking window that causes more confusion. This must be a "feature" I bet. I do not recall my BT broken in 15.2 though.
So, comments? I can follow up on my downtime, keeping in mind that it will take time away from watching Netflix! ;-) My I experience segfaults, zombie processes, excessive CPU usage, unusable IMAP with constantly broken indexes and severe data loss (until complete loss of IMAP folder from this mailing list from a few thousand to 0 (beyond repair). You can see it as a kind of "data sanitizing" (no,...that is too cynical maybe). Overheating of the CPU due to silent segfaults with zombie processes blocking one CPU to 100% were also frequent. Temperature rises n this case to 120°C. And the archiving also failed, probably because the indexes are broken. So you risk also to be without backup of your mail.
What was better with 15.2: there are a few memory leaks that do not appear, but mainly because the system crashes often so you do not reach maybe sufficient idle time. There seem to be people that claim that "I had no issue at all" (see this list). This is very good for them. But I can totally accept and confirm the greater part of your problems. Some people have claimed that erasing the indexes and reindex from scratch did help. I would also then delete the mail filter if you do it. Further you will loose all(!) settings of default folders in all accounts an personality and you have to recover them by hand. I did this all, but still faced total corruption of indexes, crashes etc so I switched back to 15.1. Your IMAP problem you find it here: bugzilla.opensuse.org/show_bug.cgi?id=1173759 ( "Kmail 20.04 as found in Leap 15.2 is unbearably slow") you can join to the cc list, currently AFAIK there is not fix foreseen as it appears it is not clear what is broken or has to be backported.
On Friday, February 19, 2021 6:44:08 AM CST Stakanov wrote:
bluetooth
This appears to be a problem of KDE and pulseaudio.
That's a new one on me. I've long suspected driver problems with two different BCM* dongles. It'll just have to stay on the list. ;-) But I have briefly attempted to use bluetooth for audio purposes.
Your IMAP problem you find it here: bugzilla.opensuse.org/show_bug.cgi?id=1173759 ( "Kmail 20.04 as found in Leap 15.2 is unbearably slow") you can join to the cc list, currently AFAIK there is not fix foreseen as it appears it is not clear what is broken or has to be backported.
Thanks for that. I'll have to look at it. Later. ;-)
On 2/19/21 6:44 AM, Stakanov wrote:
Then there's akonadi. Akonadi_imap_resource, akonadiserver, and mysqld hog CPU continually on admittedly very large gmail folders until such time as akonadiserver "closes unexpectedly". I've also suddenly got 1131-300-200-100-300 emails in a drafts folder as reported variously by kontact and xfce. None of them are visible. Akonadi server somehow restarts itself. Hey, I can't watch Netflix while akonadi is running! At times past, I've bumped akonadi's priority down a notch. This was the reason why I had to give up two times the upgrade to 15.2 and switched back to 15.1. It is also the reason why I will skip all together 15.2. My personal experience is that with 15.2 and KDE you are not getting your work done.
Have no problems with 15.2 and getting work done with KDE...3 :) -- David C. Rankin, J.D.,P.E.
In data martedì 23 febbraio 2021 23:31:42 CET, David C. Rankin ha scritto:
On 2/19/21 6:44 AM, Stakanov wrote:
Then there's akonadi. Akonadi_imap_resource, akonadiserver, and mysqld hog CPU continually on admittedly very large gmail folders until such time as akonadiserver "closes unexpectedly". I've also suddenly got 1131-300-200-100-300 emails in a drafts folder as reported variously by kontact and xfce. None of them are visible. Akonadi server somehow restarts itself. Hey, I can't watch Netflix while akonadi is running! At times past, I've bumped akonadi's priority down a notch.
This was the reason why I had to give up two times the upgrade to 15.2 and switched back to 15.1. It is also the reason why I will skip all together 15.2. My personal experience is that with 15.2 and KDE you are not getting your work done.
Have no problems with 15.2 and getting work done with KDE...3 :) Yeap, this is obviously a problem of the version of Akonadi not being compatible with the version of QT not being compatible with the recent version of kmail........ It would be wrong to blame that on the quality of KDE tout court, but it is to be attributed to the system of leap that touches it's limit in this case. I still hope for 15.3. I loved KDE3 and Kmail3, was the most stable thing I ever encountered. Using the trinity DE?
On 2/23/21 4:38 PM, Stakanov wrote:
Have no problems with 15.2 and getting work done with KDE...3 :) Yeap, this is obviously a problem of the version of Akonadi not being compatible with the version of QT not being compatible with the recent version of kmail........ It would be wrong to blame that on the quality of KDE tout court, but it is to be attributed to the system of leap that touches it's limit in this case. I still hope for 15.3. I loved KDE3 and Kmail3, was the most stable thing I ever encountered. Using the trinity DE?
Just wait for the Qt6 carnage to descend on Plasma as Trolltech has removed Qt5 from open-source development and has pushed all projects to Qt6 (including Plasma/KDE). And the big kicker -- they have intentionally broke compatibility with Qt5 in Qt6 and not all Qt5 features desktops need and rely on are available in Qt6. There will be quite a bit of porting and bug work needed for the foreseeable future with Qt6 instead of just "getting work done". (months? years?) KDE4, never quite "got there" and with the Qt change, Plasma/KDE5 may be hobbled from ever getting there due to the Trolltech debacle in yanking Qt5 pushing all projects to an unfinished Qt6. Gnome and Gtk+3.0 (oh, now it is Gtk+4.0...) is in no better shape. I am tempted to try Mate desktop which is a port of Gnome2 -- which I absolutely enjoyed as a desktop too (ah, the glory days of KDE3 and Gnome2 with Compiz and Fusion-Icon...., E16, openbox, blackbox, fluxbox [the boxtops], icewm, WindowMaker, fvwm, even sawfish and twm) -- David C. Rankin, J.D.,P.E.
David C. Rankin composed on 2021-02-23 19:33 (UTC-0600):
..(ah, the glory days of KDE3 and Gnome2 with Compiz and Fusion-Icon...., E16, openbox, blackbox, fluxbox [the boxtops], icewm, WindowMaker, fvwm, even sawfish and twm)
Who needed, or needs, all those others with TDE and KDE3 still as good as ever? -- Evolution as taught in public schools, like religion, is based on faith, not on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/
On 2/23/21 7:55 PM, Felix Miata wrote:
..(ah, the glory days of KDE3 and Gnome2 with Compiz and Fusion-Icon...., E16, openbox, blackbox, fluxbox [the boxtops], icewm, WindowMaker, fvwm, even sawfish and twm)
Who needed, or needs, all those others with TDE and KDE3 still as good as ever?
You never know what is the best until you try them all... That's why I still run KDE3 :) -- David C. Rankin, J.D.,P.E.
On 2021-02-23 16:38:30 Stakanov wrote:
|In data martedì 23 febbraio 2021 23:31:42 CET, David C. Rankin ha scritto: |> On 2/19/21 6:44 AM, Stakanov wrote: |> >> Then there's akonadi. Akonadi_imap_resource, akonadiserver, and |> >> mysqld hog |> >> CPU continually on admittedly very large gmail folders until such |> >> time as akonadiserver "closes unexpectedly". I've also suddenly got |> >> 1131-300-200-100-300 emails in a drafts folder as reported variously |> >> by kontact and xfce. None of them are visible. Akonadi server |> >> somehow restarts itself. Hey, I can't watch Netflix while akonadi is |> >> running! At |> >> times past, I've bumped akonadi's priority down a notch. |> > |> > This was the reason why I had to give up two times the upgrade to 15.2 |> > and switched back to 15.1. It is also the reason why I will skip all |> > together 15.2. My personal experience is that with 15.2 and KDE you |> > are not getting your work done. |> |> Have no problems with 15.2 and getting work done with KDE...3 :) | |Yeap, this is obviously a problem of the version of Akonadi not being |compatible with the version of QT not being compatible with the recent | version of kmail........ |It would be wrong to blame that on the quality of KDE tout court, but it | is to be attributed to the system of leap that touches it's limit in this | case. I still hope for 15.3. |I loved KDE3 and Kmail3, was the most stable thing I ever encountered. |Using the trinity DE?
Both KDE3 and Trinity are available for use on OpenSuSE. Take your pick. :-) Leslie -- openSUSE Leap 15.2 x86_64 Qt: 3.5.0 TDE: R14.0.9 tde-config: 1.0
On 2/19/21 2:57 AM, Robert Hardy wrote:
I finally got around to the 15.1>15.2 upgrade the other day using the iso image on dvd, and here's a few notes. I'd like to hear what people think.
I initially tried to update all repositories before the upgrade, but I must have messed up the pacman url, because it was not found and I had conflicts. I tried to use the back button to fix it, but couldn't find my back to the right spot, and decided to be conservative and start again with just the dvd. I ended up with conflicts anyway and resolved them one by one.
The result was about 400 packages deleted. A lot of them were development packages and debuginfo and whatnot. I haven't looked further yet.
After the upgrade I used Yast to switch to pacman, and it did pull some packages back in. I also used Yast for a serious online update. BTW, I noticed the main repository does not carry some chess packages such as xboard; they are only available from pacman.
I then noticed about 600 packages still had an "x-lp151.x" sort of moniker-- zypper up took care of that.
KDE's notification system isn't working due to a problem with xfce as described here: https://forums.opensuse.org/showthread.php/543232-Lost-notifications . I'm not entirely happy with the proposed solutions. I seem to recall KDE notification problems before, perhaps with 15.0, or maybe 42.0, where my system would fall back to xfce notifications until the KDE problems were fixed. That seemed like a nice behavior, all in all.
ksysguard has gone from maybe 6-8% of one CPU to 30-40%. I've always tended to leave that running on one desktop, but 30-40% is unacceptable. It also apparently replaced my file read/write columns with Download/Upload.
I have a CPU temp monitor in one of the panels that is not working. Any attempt to open its configuration dialog crashes plasmashell.
Then there's akonadi. Akonadi_imap_resource, akonadiserver, and mysqld hog CPU continually on admittedly very large gmail folders until such time as akonadiserver "closes unexpectedly". I've also suddenly got 1131-300-200-100-300 emails in a drafts folder as reported variously by kontact and xfce. None of them are visible. Akonadi server somehow restarts itself. Hey, I can't watch Netflix while akonadi is running! At times past, I've bumped akonadi's priority down a notch.
I haven't mentioned bluetooth which has been an ongoing problem for a long time. I've successfully nursed it in the past with restarts and whatnot, but I don't want to get into that at the moment. I used to use serial over bluetooth a lot, as well as tethering to my phone, but for the moment, it's a bit beyond me.
So, comments? I can follow up on my downtime, keeping in mind that it will take time away from watching Netflix! ;-)
I've read the other replies, some good advice there. Fwiw (or not), since you asked . . . I've been using the DVD upgrade method for ~20 years. I (still) find it the easiest, and agree with the openSUSE documentation that states this is the most "robust" method. While most on this list are probably fans of using zypper and that is just fine (I'd also guess most are also intermediate-to-advanced users), IME the DVD is easier/better for resolving hiccups before the user commits to the upgrade. But with either route the user has to understand his/her system and the process very well, if surprises are to be avoided or mitigated. Consequently one practice I borrowed from my enterprise days has been to /always/ perform a proforma upgrade. I keep storage on each machine to which I can copy my production system, test the upgrade process and then exercise the post-upgrade system with a representative suite of tests. The most difficult problems I recall have invariably been with graphics or new hardware. Or with KDE - which I blame on myself for stubbornly continue to use it. :) IMO it's also very important to clean up one's repositories and current software setup beforehand. Having many hundreds of files to delete or a load more not making any sense, would move me to look closely first to understand what this means. I'm only using ~150 Packman files, mostly multimedia apps with half the files being the libraries. Maybe you use a lot more from Packman than I do, but I would l want to understand the "whatnot" that you had "not looked further at" before. I do include Packman in my upgrade by switching the repo beforehand and then during the upgrade toggling YaST to include it. Going to 15.2 I got maybe 50 conflicts but nearly all were about version differences for which I just needed to decide which to use; all but a few were recognizable and dispositioned quickly. There are always a few where the dependencies need to be realigned. The ability to load the YaST Software module and work thru these with all its power, ensures that at least the software stack is clean before committing to proceed. Each cycle I regularly accumulate about a dozen additional OBS repositories for this or that app or to get a newer version, but all of those I remove and let the upgrade revert the files to the new main repo versions (which typically are as new/newer than the version I had added before). IMO trying to include all these in the upgrade would mean I must have a pain fetish. No comment on your xfce vs kde issue, except to say I probably wouldn't mix the two and if I did, frankly I would not consider that an openSUSE glitch unless it is a supported function/feature. Re ksysguard. First, the config file for the main window that is set up by default may make some small format change; that happens all the time with lots of KDE stuff. Your read & write columns are still there; just a couple of clicks to return/rearrange columns. With the performance hit, I have seen this after a KDE upgrade a few times and it appears that some functions do a lot of activity being reinitialized, and then KDE settles down. This happened this time around too and now a couple days later everything has calmed down. If your cpu load doesn't, obviously something not right. Trying a couple different desktop managers may help isolate the problem. Also check your power management, maybe a KDE change is causing throttling. Akonadi has long been recognized as a PITA and AFAICT it is an architecture issue that hasn't been/won't be fixed for a long time. While some misbehavior can be mitigated a bit, I still ended up dropping it altogether with 42.3. Just one last /personal/ opinion since some suggest that other distros are better at upgrades. I suppose that's entirely possible, maybe even probable. What I do know is that of the ~two dozen distros I've used, I can't offhand recall any with better system mgmt tools. It's not a coincidence that the best are backed by commercial enterprise vendors. And I never saw a shop which did not do a full system test before attempting to upgrade a production system. --dg
On 19/02/2021 21.24, DennisG wrote:
On 2/19/21 2:57 AM, Robert Hardy wrote:
I finally got around to the 15.1>15.2 upgrade the other day using the iso image on dvd, and here's a few notes. I'd like to hear what people think.
...
So, comments? I can follow up on my downtime, keeping in mind that it will take time away from watching Netflix! ;-)
I've read the other replies, some good advice there. Fwiw (or not), since you asked . . .
I've been using the DVD upgrade method for ~20 years.
Same here :-)
I (still) find it the easiest, and agree with the openSUSE documentation that states this is the most "robust" method.
Hehe :-) If you refer to the wiki page, I wrote most of that one ;-) I had a problem wit it one or two versions ago, because it refused to proceed if there was a reiserfs partition in fstab, so I had to switch to zypper dup for this computer. But on the other computers I'm using the DVD.
While most on this list are probably fans of using zypper and that is just fine (I'd also guess most are also intermediate-to-advanced users), IME the DVD is easier/better for resolving hiccups before the user commits to the upgrade. But with either route the user has to understand his/her system and the process very well, if surprises are to be avoided or mitigated.
Quite so.
Consequently one practice I borrowed from my enterprise days has been to /always/ perform a proforma upgrade. I keep storage on each machine to which I can copy my production system, test the upgrade process and then exercise the post-upgrade system with a representative suite of tests. The most difficult problems I recall have invariably been with graphics or new hardware. Or with KDE - which I blame on myself for stubbornly continue to use it. :)
If I have time, I like to install fresh the new version on a small partition to test it. Then I do a full backup of the target system, then I upgrade it. If it fails, I can find out why and I can repeat from the backup. Or install fresh, knowing that I have a backup with the configs.
IMO it's also very important to clean up one's repositories and current software setup beforehand.
Quite correct.
Having many hundreds of files to delete or a load more not making any sense, would move me to look closely first to understand what this means. I'm only using ~150 Packman files, mostly multimedia apps with half the files being the libraries. Maybe you use a lot more from Packman than I do, but I would l want to understand the "whatnot" that you had "not looked further at" before. I do include Packman in my upgrade by switching the repo beforehand and then during the upgrade toggling YaST to include it. Going to 15.2 I got maybe 50 conflicts but nearly all were about version differences for which I just needed to decide which to use; all but a few were recognizable and dispositioned quickly. There are always a few where the dependencies need to be realigned. The ability to load the YaST Software module and work thru these with all its power, ensures that at least the software stack is clean before committing to proceed.
I find easier to solve those conflicts with YaST than with zypper.
Each cycle I regularly accumulate about a dozen additional OBS repositories for this or that app or to get a newer version, but all of those I remove and let the upgrade revert the files to the new main repo versions (which typically are as new/newer than the version I had added before). IMO trying to include all these in the upgrade would mean I must have a pain fetish.
Good strategy.
No comment on your xfce vs kde issue, except to say I probably wouldn't mix the two and if I did, frankly I would not consider that an openSUSE glitch unless it is a supported function/feature.
I have both, but my desktop is XFCE while using some KD tools. Ie, the reverse. No issues. ...
Just one last /personal/ opinion since some suggest that other distros are better at upgrades. I suppose that's entirely possible, maybe even probable. What I do know is that of the ~two dozen distros I've used, I can't offhand recall any with better system mgmt tools. It's not a coincidence that the best are backed by commercial enterprise vendors. And I never saw a shop which did not do a full system test before attempting to upgrade a production system.
--dg
Me, I stick with the system I know best ;-) -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
On 2/19/21 3:45 PM, Carlos E.R. wrote:
On 19/02/2021 21.24, DennisG wrote:
On 2/19/21 2:57 AM, Robert Hardy wrote:
I finally got around to the 15.1>15.2 upgrade the other day using the iso image on dvd, and here's a few notes. I'd like to hear what people think. ...
So, comments? I can follow up on my downtime, keeping in mind that it will take time away from watching Netflix! ;-) I've read the other replies, some good advice there. Fwiw (or not), since you asked . . .
I've been using the DVD upgrade method for ~20 years. Same here :-)
I (still) find it the easiest, and agree with the openSUSE documentation that states this is the most "robust" method. Hehe :-) If you refer to the wiki page, I wrote most of that one ;-)
I had a problem wit it one or two versions ago, because it refused to proceed if there was a reiserfs partition in fstab, so I had to switch to zypper dup for this computer. But on the other computers I'm using the DVD.
While most on this list are probably fans of using zypper and that is just fine (I'd also guess most are also intermediate-to-advanced users), IME the DVD is easier/better for resolving hiccups before the user commits to the upgrade. But with either route the user has to understand his/her system and the process very well, if surprises are to be avoided or mitigated. Quite so.
Consequently one practice I borrowed from my enterprise days has been to /always/ perform a proforma upgrade. I keep storage on each machine to which I can copy my production system, test the upgrade process and then exercise the post-upgrade system with a representative suite of tests. The most difficult problems I recall have invariably been with graphics or new hardware. Or with KDE - which I blame on myself for stubbornly continue to use it. :) If I have time, I like to install fresh the new version on a small partition to test it. Then I do a full backup of the target system, then I upgrade it. If it fails, I can find out why and I can repeat from the backup. Or install fresh, knowing that I have a backup with the configs.
IMO it's also very important to clean up one's repositories and current software setup beforehand. Quite correct.
Having many hundreds of files to delete or a load more not making any sense, would move me to look closely first to understand what this means. I'm only using ~150 Packman files, mostly multimedia apps with half the files being the libraries. Maybe you use a lot more from Packman than I do, but I would l want to understand the "whatnot" that you had "not looked further at" before. I do include Packman in my upgrade by switching the repo beforehand and then during the upgrade toggling YaST to include it. Going to 15.2 I got maybe 50 conflicts but nearly all were about version differences for which I just needed to decide which to use; all but a few were recognizable and dispositioned quickly. There are always a few where the dependencies need to be realigned. The ability to load the YaST Software module and work thru these with all its power, ensures that at least the software stack is clean before committing to proceed. I find easier to solve those conflicts with YaST than with zypper.
Each cycle I regularly accumulate about a dozen additional OBS repositories for this or that app or to get a newer version, but all of those I remove and let the upgrade revert the files to the new main repo versions (which typically are as new/newer than the version I had added before). IMO trying to include all these in the upgrade would mean I must have a pain fetish. Good strategy.
No comment on your xfce vs kde issue, except to say I probably wouldn't mix the two and if I did, frankly I would not consider that an openSUSE glitch unless it is a supported function/feature. I have both, but my desktop is XFCE while using some KD tools. Ie, the reverse. No issues.
...
Just one last /personal/ opinion since some suggest that other distros are better at upgrades. I suppose that's entirely possible, maybe even probable. What I do know is that of the ~two dozen distros I've used, I can't offhand recall any with better system mgmt tools. It's not a coincidence that the best are backed by commercial enterprise vendors. And I never saw a shop which did not do a full system test before attempting to upgrade a production system.
--dg Me, I stick with the system I know best ;-)
Thank you, Carlos. And, yes, I thought I saw your fingerprint on that upgrade documentation. My hat is off to you, for all the great work you've done for the community. However, in regard specifically to a certain infamous community member whom we both have, er, enjoyed engaging, I think a general note of recognition falls short: A keg of the finest Northern California craft beer shipped over the pond your way would be much more in order. I hope he's listening. --dg
On Friday, February 19, 2021 2:24:26 PM CST DennisG wrote: Just a few more notes and then some short replies to some of your points. Akonadi has become quiet. Kontact still shows its "Unified Mailboxes" thingy at 0%, but it also says "Ready". I don't know what that's about. Also, wouldn't akonadi be more serviceable if some portion of it ran at a lower priority by default? My temp sensor has an updated version that doesn't crash plasmashell. Still, that strikes me as a plasmashell vulnerability that it can be brought down by some random app. Ksysguard's process table insists insists on showing itself at 30-40%, while its CPU History shown a quiet system at 10% (for each of two CPU's). And on to a few comments...
I've read the other replies, some good advice there. Fwiw (or not), since you asked . . .
I've been using the DVD upgrade method for ~20 years. I (still) find it the easiest, and agree with the openSUSE documentation that states this is the most "robust" method. While most on this list are probably fans of using zypper and that is just fine (I'd also guess most are also intermediate-to-advanced users), IME the DVD is easier/better for resolving hiccups before the user commits to the upgrade. But with either route the user has to understand his/her system and the process very well, if surprises are to be avoided or mitigated.
And that's the method I've used for many years with prepackaged systems like 15.2. I just had an aborted attempt at adventurousness before settling down this time, with a couple of exceptions. I left two repositories in a disabled state (with updated url's) rather than removed. One was the munix9 one from which I drew celestia. Could that be the reason celestia wasn't deleted and was ready to be upgraded once munix 9 was reenabled? and the other was opensuse-guide, which might be what redirected me to videolan under the same circumstances. That said, I did maintain a Tumbleweed installation for a couple of years using zypper up and lots of package cleaning using Yast. I still have that installation.
Consequently one practice I borrowed from my enterprise days has been to /always/ perform a proforma upgrade. I keep storage on each machine to which I can copy my production system, test the upgrade process and then exercise the post-upgrade system with a representative suite of tests. The most difficult problems I recall have invariably been with graphics or new hardware. Or with KDE - which I blame on myself for stubbornly continue to use it. :)
That's actually sort of difficult for a home user with one cheap, old computer.
IMO it's also very important to clean up one's repositories and current software setup beforehand. Having many hundreds of files to delete or a load more not making any sense, would move me to look closely first to understand what this means.
See above, in re Tumbleweed. ;-) Also, I think I know the source of some of those few orphans. One would be pacman with multiple libraries where earlier ones are quietly abandoned. Another would be Application:Geo, which I've used heavily in the past. I haven't looked yet, though.
I'm only using ~150 Packman files, mostly multimedia apps with half the files being the libraries. Maybe you use a lot more from Packman than I do, but I would l want to understand the "whatnot" that you had "not looked further at" before. I do include Packman in my upgrade by switching the repo beforehand and then during the upgrade toggling YaST to include it. Going to 15.2 I got maybe 50 conflicts but nearly all were about version differences for which I just needed to decide which to use; all but a few were recognizable and dispositioned quickly. There are always a few where the dependencies need to be realigned. The ability to load the YaST Software module and work thru these with all its power, ensures that at least the software stack is clean before committing to proceed.
Same same, mostly.
Each cycle I regularly accumulate about a dozen additional OBS repositories for this or that app or to get a newer version, but all of those I remove and let the upgrade revert the files to the new main repo versions (which typically are as new/newer than the version I had added before). IMO trying to include all these in the upgrade would mean I must have a pain fetish.
This is sounding very familiar, though I may not be as careful as you.
No comment on your xfce vs kde issue, except to say I probably wouldn't mix the two and if I did, frankly I would not consider that an openSUSE glitch unless it is a supported function/feature.
Hey, the login screen gives a choice of desktops. [...] Now, to Netflix, then bed.
On 20/02/2021 09.09, Robert Hardy wrote: Just two comments ...
That said, I did maintain a Tumbleweed installation for a couple of years using zypper up and lots of package cleaning using Yast. I still have that installation.
Tumbleweed must be updated using "zypper dup" every time, not "zypper up". Similarly, if you are testing the 15.3 beta, it has to updated using "zypper dup".
Consequently one practice I borrowed from my enterprise days has been to /always/ perform a proforma upgrade. I keep storage on each machine to which I can copy my production system, test the upgrade process and then exercise the post-upgrade system with a representative suite of tests. The most difficult problems I recall have invariably been with graphics or new hardware. Or with KDE - which I blame on myself for stubbornly continue to use it.
That's actually sort of difficult for a home user with one cheap, old computer.
My trick in that case is to keep one small partition, say 10 GB (I have one with 8) for testing the incoming new version, installed new at some point. When I upgrade the main partition, I can use the test partition for comparisons and tests. But having at least one external hard disk into which doing a full backup, at least prior to doing the upgrade, is unavoidable. Typically with laptops, people also have a windows partition. It is good to have in that external disk an image (dd) of the windows partition for recovery in case of disaster. One strategy is to have in the external disk one small bootable partition - say XFCE on ext4, 15 GB - and the rest of the disk is one huge btrfs partition, encrypted and compressed. I don't particularly like btrfs, but it is the only (major) linux filesystem that supports compression. Then you can do rsync backups into it that result in less space. Modern laptops with USB3 handle an external hard disk as fast as if were internal. -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
I did this on my 24/7 box on Monday AM, my upteen bazillionth online upgrade. IIRC I tried and offline upgrade many many moons ago, a much bigger hassle. As usual, no fault found with the process, the only optional repos being Packman Essentials, FCL, Libdvdcss2, and KDE3. The /only/ changes noticed are my OS/2 box can no longer access Samba shares (which I know is readily fixable, if only I could remember the right search terms), and bloated 5.18 kernels and initrds (already known from my other 20+ online upgrades to 15.2). I'm still on that first full boot since the upgrade, 4.5 days. -- Evolution as taught in public schools, like religion, is based on faith, not on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/
participants (10)
-
Anton Aylward -
Carlos E. R. -
Carlos E.R. -
David C. Rankin -
DennisG -
Felix Miata -
J Leslie Turriff -
Per Jessen -
Robert Hardy -
Stakanov