8.6 upgrade problems [Resolved]

RL1000 · May 17, 2022, 1:58am

Hi, I am a happy and grateful user of Rocky Linux.

Edit:
I ran:
sudo dnf upgrade --refresh
and now dnf is downloading packages so I believe this is resolved.

I am running 8.5 and did a successful “sudo dnf up” this morning. I presume this was pre-8.6 being released.

As per:
https://docs.rockylinux.org/release_notes/8_6/
I just ran:
sudo dnf -y upgrade

And dnf reported 23 problems, eg:

Error:
Problem 1: cannot install the best update candidate for package clevis-15-1.el8_5.1.x86_64

nothing provides libjansson.so.4(libjansson.so.4)(64bit) needed by clevis-15-8.el8.x86_64
Problem 2: cannot install the best update candidate for package cups-1:2.2.6-40.el8.x86_64

nothing provides cups-libs(x86-64) = 1:2.2.6-44.el8 needed by cups-1:2.2.6-44.el8.x86_64
Problem 3: cannot install the best update candidate for package cups-client-1:2.2.6-40.el8.x86_64

nothing provides cups-libs(x86-64) = 1:2.2.6-44.el8 needed by cups-client-1:2.2.6-44.el8.x86_64
Problem 4: cannot install the best update candidate for package cups-ipptool-1:2.2.6-40.el8.x86_64

nothing provides cups-libs(x86-64) = 1:2.2.6-44.el8 needed by cups-ipptool-1:2.2.6-44.el8.x86_64
Problem 5: cannot install the best update candidate for package dbus-x11-1:1.12.8-14.el8.x86_64

nothing provides dbus-daemon = 1:1.12.8-18.el8 needed by dbus-x11-1:1.12.8-18.el8.x86_64
Problem 6: cannot install the best update candidate for package firewall-config-0.9.3-7.el8_5.1.noarch

nothing provides firewalld = 0.9.3-13.el8 needed by firewall-config-0.9.3-13.el8.noarch

thru to:

Problem 23: problem with installed package selinux-policy-targeted-3.14.3-80.el8_5.2.noarch

package flatpak-1.8.7-1.el8.x86_64 requires (flatpak-selinux = 1.8.7-1.el8 if selinux-policy-targeted), but none of the providers can be installed

package gnome-software-3.36.1-10.el8.x86_64 requires flatpak(x86-64) >= 0.9.4, but none of the providers can be installed

package flatpak-1.8.5-5.el8_5.x86_64 requires flatpak-session-helper(x86-64) = 1.8.5-5.el8_5, but none of the providers can be installed

cannot install both flatpak-session-helper-1.8.7-1.el8.x86_64 and flatpak-session-helper-1.8.5-5.el8_5.x86_64

cannot install the best update candidate for package gnome-software-3.36.1-10.el8.x86_64

cannot install the best update candidate for package flatpak-session-helper-1.8.5-5.el8_5.x86_64

nothing provides selinux-policy >= 3.14.3-93.el8 needed by flatpak-selinux-1.8.7-1.el8.noarch

nothing provides selinux-policy-base >= 3.14.3-93.el8 needed by flatpak-selinux-1.8.7-1.el8.noarch
(try to add ‘–allowerasing’ to command line to replace conflicting packages or ‘–skip-broken’ to skip uninstallable packages or ‘–nobest’ to use not only best candidate packages)

I am just a home user of Rocky Linux and hence not a sys admin and I am not sure if I should follow the advice of:

(try to add ‘–allowerasing’ to command line to replace conflicting packages or ‘–skip-broken’ to skip uninstallable packages or ‘–nobest’ to use not only best candidate packages)

Nor which to choose.

The announcement:

Mentions:
General Repository Changes
But I am not sure if I need to make changes to my installed repos or not.

This is not an urgent issue for me, Rocky 8.5 is running fine for me, but I thought I would report this, and any help would be appreciated.

Thanks ahead of time.

mattboston · May 17, 2022, 3:14pm

I’ve had the same issue. Is this a RHEL issue or a Rocky one?

[root@hqrockytest01 ~]# dnf check-update
Last metadata expiration check: 2:09:05 ago on Tue 17 May 2022 09:03:27 AM EDT.
Module yaml error: Unexpected key in data: static_context [line 9 col 3]
Module yaml error: Unexpected key in data: static_context [line 9 col 3]

python36.x86_64                                                   3.6.8-38.module+el8.5.0+671+195e4563                          appstream
rocky-logos-httpd.noarch                                          85.0-4.el8                                                    baseos   
rocky-repos.noarch                                                8.6-2.el8                                                     baseos   
Obsoleting Packages
NetworkManager-initscripts-updown.noarch                          1:1.36.0-4.el8                                                baseos   
    NetworkManager.x86_64                                         1:1.30.0-10.el8_4                                             @baseos  
[root@hqrockytest01 ~]# dnf upgrade
Last metadata expiration check: 2:09:10 ago on Tue 17 May 2022 09:03:27 AM EDT.
Module yaml error: Unexpected key in data: static_context [line 9 col 3]
Module yaml error: Unexpected key in data: static_context [line 9 col 3]
Error: 
 Problem 1: package rocky-repos-8.6-2.el8.noarch requires system-release = 8.6, but none of the providers can be installed
  - cannot install the best update candidate for package rocky-repos-8.5-3.el8.noarch
  - package rocky-release-8.6-2.el8.noarch is filtered out by modular filtering
 Problem 2: package python36-3.6.8-38.module+el8.5.0+671+195e4563.x86_64 requires alternatives >= 1.19.1-1, but none of the providers can be installed
  - cannot install the best update candidate for package python36-3.6.8-2.module+el8.4.0+597+ddf0ddea.x86_64
  - package chkconfig-1.19.1-1.el8.x86_64 is filtered out by modular filtering
 Problem 3: both package NetworkManager-initscripts-updown-1:1.36.0-4.el8.noarch and NetworkManager-1:1.36.0-4.el8.x86_64 obsolete NetworkManager < 1:1.36.0-0.6
  - cannot install the best update candidate for package NetworkManager-1:1.30.0-10.el8_4.x86_64
  - package NetworkManager-1:1.36.0-4.el8.x86_64 is filtered out by modular filtering
(try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)

RL1000 · May 17, 2022, 3:31pm

Hi @mattboston,
Please see my Edit near the top of my original post.
The issue was that my Rocky Linux on my computer had an old cache of the repos. The --refresh switch updates the cache…
I also added a separate post marked Solution.
Hope this helps…

RL1000 · May 17, 2022, 3:32pm

Update:
I ran:
sudo dnf upgrade --refresh
and dnf downloaded packages and upgraded to 8.6 so this is resolved.

jlehtone · May 17, 2022, 3:41pm

The Appstream repository has descriptions of dnf modules in (compressed) text file that is in Yaml-format.

Apparently, that file looks corrupted. That could mess up dnf. Could be that something was up with the mirror.

I would remove all cached data with dnf --enablerepo=* clean all (although the --refresh option might achieve similar result).
That way dnf at least checks the repo thoroughly on next transaction.

I have not used any of those. If there are conflicting packages, I usually try to figure out which ones are not essential and manually remove those (unless there are a lot of them). Then upgrade the rest. Finally, reinstall the packages that were removed. Been lucky, haven’t had issues that this procedure could not clear.

mattboston · May 17, 2022, 3:57pm

Tried both the “dnf upgrade --refresh” and just now tried this:

Still seeing similar issue.

[root@hqrockytest01 ~]# dnf upgrade --refresh
Rocky Linux 8 - AppStream                                                                                1.3 MB/s | 8.2 MB     00:06    
Rocky Linux 8 - BaseOS                                                                                   1.1 MB/s | 2.6 MB     00:02    
Rocky Linux 8 - Extras                                                                                    25 kB/s |  11 kB     00:00    
Extra Packages for Enterprise Linux Modular 8 - x86_64                                                   1.0 MB/s | 1.0 MB     00:01    
Extra Packages for Enterprise Linux 8 - x86_64                                                           6.7 MB/s |  11 MB     00:01    
internal-amazon-corretto-8                                                                                63 kB/s |  10 kB     00:00    
internal-frt-thirdparty-8                                                                                992 kB/s | 204 kB     00:00    
internal-saltstack-py3                                                                                   797 kB/s | 245 kB     00:00    
Module yaml error: Unexpected key in data: static_context [line 9 col 3]
Module yaml error: Unexpected key in data: static_context [line 9 col 3]
Error: 
 Problem 1: package rocky-repos-8.6-2.el8.noarch requires system-release = 8.6, but none of the providers can be installed
  - cannot install the best update candidate for package rocky-repos-8.5-3.el8.noarch
  - package rocky-release-8.6-2.el8.noarch is filtered out by modular filtering
 Problem 2: package python36-3.6.8-38.module+el8.5.0+671+195e4563.x86_64 requires alternatives >= 1.19.1-1, but none of the providers can be installed
  - cannot install the best update candidate for package python36-3.6.8-2.module+el8.4.0+597+ddf0ddea.x86_64
  - package chkconfig-1.19.1-1.el8.x86_64 is filtered out by modular filtering
 Problem 3: both package NetworkManager-initscripts-updown-1:1.36.0-4.el8.noarch and NetworkManager-1:1.36.0-4.el8.x86_64 obsolete NetworkManager < 1:1.36.0-0.6
  - cannot install the best update candidate for package NetworkManager-1:1.30.0-10.el8_4.x86_64
  - package NetworkManager-1:1.36.0-4.el8.x86_64 is filtered out by modular filtering
(try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)

RL1000 · May 17, 2022, 4:12pm

I’m just a user of RL and unfortunately dont know what else to suggest…

SomervilleTom · May 17, 2022, 4:16pm

II have been running v8.5 for some time now with no issues.

At the prompt from the system installer, I just attempt to upgrade to v8.6 using the “Update” widget in plasma. I think this is synonymous with sudo dnf update.

The update seems to have finished successfully.

I shut down, restarted, and selected the top “v8.6” from the grub list. The system starts, and I’m able to SSH into it from the outside.

Sadly, I get no plasma/UI. At the point where I usually get a password prompt, I instead have a blank black screen with a working cursor and nothing else.

I’ve restarted using the older v8.5 grub entry and it restarted as usual.

I have journalctl enabled (I’ve added journal to `/var/log’).

I’d appreciate guidance in getting plasma working in v8.6. I’m at a loss about how to identify and resolve whatever is making the updated system work.

Following the guidance from this topic, I did dnf --enablerepo=* clean all (as root) with the following result:

# dnf --enablerepo=* clean all
95 files removed
[root@tms-desktop ~]# dnf update
Rocky Linux 8 - AppStream                                                        5.6 MB/s | 7.8 MB     00:01    
Rocky Linux 8 - BaseOS                                                           2.0 MB/s | 2.6 MB     00:01    
Rocky Linux 8 - Extras                                                            24 kB/s |  11 kB     00:00    
Rocky Linux 8 - PowerTools                                                       2.0 MB/s | 2.2 MB     00:01    
Extra Packages for Enterprise Linux 8 - x86_64                                   886 kB/s |  11 MB     00:12    
Extra Packages for Enterprise Linux Modular 8 - x86_64                           995 kB/s | 1.0 MB     00:01    
google-chrome                                                                     14 kB/s | 3.6 kB     00:00    
MySQL 8.0 Community Server                                                       6.0 MB/s | 2.3 MB     00:00    
MySQL Connectors Community                                                       266 kB/s |  74 kB     00:00    
MySQL Tools Community                                                            2.5 MB/s | 459 kB     00:00    
Oracle Linux / RHEL / CentOS-8 / x86_64 - VirtualBox                             735 kB/s | 204 kB     00:00    
Visual Studio Code                                                                20 MB/s |  25 MB     00:01    
Error: 
 Problem 1: cannot install the best update candidate for package anaconda-live-33.16.5.6-1.el8.rocky.1.x86_64
  - nothing provides anaconda-gui = 33.16.6.7-1.el8.rocky.0.3 needed by anaconda-live-33.16.6.7-1.el8.rocky.0.3.x86_64
 Problem 2: package anaconda-live-33.16.5.6-1.el8.rocky.1.x86_64 requires anaconda-gui = 33.16.5.6-1.el8.rocky.1, but none of the providers can be installed
  - cannot install both anaconda-gui-33.16.6.7-1.el8.rocky.0.4.x86_64 and anaconda-gui-33.16.5.6-1.el8.rocky.1.x86_64
  - problem with installed package anaconda-live-33.16.5.6-1.el8.rocky.1.x86_64
  - cannot install the best update candidate for package anaconda-gui-33.16.5.6-1.el8.rocky.1.x86_64
  - nothing provides anaconda-gui = 33.16.6.7-1.el8.rocky.0.3 needed by anaconda-live-33.16.6.7-1.el8.rocky.0.3.x86_64
(try to add '--allowerasing' to command line to replace conflicting packages or '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)

I hope this is helpful – I remain stuck until I understand what these complaints mean. Like rl100, I’m just a user – I have limited insight into how to proceed.

SomervilleTom · May 17, 2022, 4:21pm

This may have solved your issue, but perhaps you might clear the “Resolved” flag – there at least two more users that seem to have a related issue.

irisx · May 17, 2022, 7:41pm

I have exactly the same issue with failing to start Plasma desktop: instead of login prompt I get a black screen and a functioning mouse cursor. dnf update from 8.5 to 8.6 went smoothly.

Things I tried that didn’t help with the Plasma problem:

Reinstalling latest nVidia binary driver (390.151) followed by dracut --force + reboot
Reinstalling all Kde workspaces rpm’s

Thing that works:

Booting with the last 8.5 kernel-4.18.0-348.23.1, I am able to start Plasma normally (both with the previous-to-last and the latest nVidia drivers, both installed with the nvidia installer).

So it seems to be some quick caused by kernel-4.18.0-372.9.1 ?

Any ideas?

Edit: I am using sddm

ValorCat · May 17, 2022, 8:29pm

Same here! Was especially a pain cause once I successfully updated to 8.6 (sudo dnf update --allowerasing --nobest -y) I got a cursor over a black background… I had to plug my headless server back into a monitor and switch back the last 8.5 kernel…

It also completely busted my redshift for maya - maxon one licence (which was very difficult to install in the first place…

Maybe the 8.6 updates are being added to the Rocky Repo one-by-one? And the Rocky update is stilll incomplete? Therefore, breaking everyone’s delicate mission-critical server situation?

Edit: I am also using sddm (maybe this is an epel-release delayed update situation? Whoever is maintaining the SDDM is the culprit (poor soul)?)

irisx · May 17, 2022, 9:05pm

For people dealing with the sddm blackout after upgrading to 8.6, a temporary (and perhaps obvious) workaround is to switch to gdm. From a console or ssh, as root:

dnf install gdm
systemctl stop display-manager
systemctl disable sddm
systemctl enable gdm
systemctl start display-manager

The disable/enable commands do the actual work, so if they succeed you can just reboot and gdm will (hopefully) come up.

Don’t forget upon the first login to click on the “gear” icon and select Plasma as the preferable desktop.

The process should be reversible once sddm (or whatever causes the problem) gets repaired…

YMMV etc.

Note: in my case gdm spends a little while after entering the password apparently doing nothing, but I guess it’s better than staring into a black screen with a pointer

ValorCat · May 17, 2022, 9:18pm

"and perhaps obvious*
Ouch! No, not to me. I also chose sddm for its lightweight versatility (and cause lxdm is borking on boot lately)
I am running an animation studio, and sddm is what works most stable for us when animating/rendering.
I think its super inconvenient to have to switch something as fundamental as your chosen display manager.

jlehtone · May 17, 2022, 9:59pm

There at least were some issues with KDE/sddm that EPEL maintainers were working on:
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/thread/ENI3SYPO7NOVTVDE6FTXB6I5PBOSFQ7D/

irisx · May 17, 2022, 10:41pm

So it appears it is indeed an upstream 8.6 kernel bug that affects both sddm and kscreenlocker:

https://bugzilla.redhat.com/show_bug.cgi?id=2043771
https://bugzilla.redhat.com/show_bug.cgi?id=2082719

It’s currently unknown when it will be fixed and unfortunately the relevant tracker bug is private.

SomervilleTom · May 18, 2022, 12:51pm

Is there some way to adjust the process so that updates like this are not pushed through the dnf repos until they are “mature”?

At the moment, I’m not sure what state my system is in. I had to revert to an earlier grub entry (I don’t even know what vocabulary to use!) to make it work at all. I’m afraid to do another yum update because the last time I tried it, I got the above error complaints.

I’m migrating my world to Rocky Linux system by system (away from CentOS 7 and Windows 10 Pro). That makes me increasingly vulnerable to issues like this.

I’m ok with simply waiting a few days, but I wonder if there’s some way to improve the release process so that I don’t have to worry about a bug like this knocking me entirely off the grid.

jlehtone · May 18, 2022, 1:05pm

Too many chefs on the soup.

What Rocky Linux has in its repositories is consistent, as “mature” as possible from the sources of RHEL. It is very rare that RHEL or rebuild has major regressions. The same was/is with CentOS 7.

It is the content that you insist on getting from third party repositories that does not always sync with the distro. The third-party repositories do build to the best of their ability, but it definitely is not the responsibility of the distro (RHEL, CentOS, Rocky) to wait until someone somewhere that almost nobody knows about has updated and tested their package to be compatible, particularly when that somebody cannot build nor test before they have the new Rocky to work on.

That boils down to you knowing what you have and keeping taps on (and possibly inspiring the third-party maintainers) until “all the pieces” are safe for you.

SomervilleTom · May 18, 2022, 1:22pm

Let me try using different language.

I’m still unsure what has broken on my system. I have a reasonably vanilla desktop – KDE/Plasma. So far as I can tell, the issue on my system is with KDE/Plasma.

If my use of KDE/Plasma makes me “someone somewhere that almost nobody knows about”, then it leads me to question whether Rocky Linux is the right choice for me. While I do use a large number of headless systems on AWS/EC2, and even here on my home network, I do still want a desktop on the machine I use all day every day.

Is Gnome a better choice? I thought I was choosing mainstream-vanilla when I chose KDE/Plasma. Is there a way to migrate from KDE/Plasma to Gnome without rebuilding the world from bits?

That boils down to you knowing what you have and keeping taps on (and possibly inspiring the third-party maintainers) until “all the pieces” are safe for you.

Blaming the user/customer is not the most effective way to either build a community or solve a problem. I have KDE/Plasma. KDE/Plasma is – I thought – a mainstream choice of desktop. I have the perhaps unreasonable expectation that I should be able to run “dnf update” without fear of a black screen being the result.

I will happily pay a reasonable price for some entity to manage this for me – I thought that such a package was in the works for Rocky Linux. In the meantime, do you have any constructive suggestions for how I proceed?

For example, is Gnome a more mainstream choice? Is there a deterministic way to migrate from KDE/Plasma to Gnome?

I just want this work, I don’t want to argue about it. I’ve been a professional software developer since 1982 – I understand that bugs happen, and they don’t provoke angst or drama in me.

I just want my system to work when I turn it on.

iwalker · May 18, 2022, 2:41pm

KDE/Plasma is not vanilla because it’s not included in RHEL, and therefore not included in Rocky. A vanilla system is installing Rocky with the desktop that it comes with by default - which is Gnome. If you install an additional desktop GUI like KDE, or Cinnamon or something else then this is not the fault of Rocky Linux. As @jlehtone said, and what I’ve also said in another thread as well - if you see such conflicts when attempting to update the best thing to do is wait. Wait until the third party repos like where you are installing KDE from fix the issues, so that when you do in a few days time run the update command again - chances are it will work. I have Cinnamon in my installation, and if it breaks, then it is my fault for installing it, instead of using the default Gnome desktop.

If you installed a desktop that is by default in Rocky and it doesn’t work for you, then it is Rocky that needs to sort it out. If you install a desktop like KDE from wherever you installed it from and it doesn’t work, then ideally you need to be asking them or saying why this doesn’t work, and providing the info. Rocky cannot solve it for you, because it’s not software that they developed. Basically if you see problems when doing an update, don’t do it!

Also, using things like --allowerasing I don’t recommend using. Especially if the output from the command on what it is going to do next isn’t completely read and understood clearly, since this command is going to potentially remove packages from your system and in some cases has meant people lost their desktop completely, with black screens or whatever. If in doubt about the output on what it’s going to do, best not do it.

Best to use a vanilla system and not customise it using third-party repositories unless you are willing to tinker and fix problems when they occur. I don’t like Gnome, so I’ve always tended to go for systems that have Cinnamon by default because I like that. So Linux Mint in some respects. If you like KDE, then Kubuntu unless you don’t like that kind of system. SUSE/OpenSUSE includes KDE by default from what I remember as well.

It should be said, playing with and customising a system takes it outside of the boundaries that it was meant to be in. At this point, the responsibility for that lies with the person who made those changes to the system. In this instance, with Rocky+Cinnamon I’m the person who made it a different system, I customised it, therefore the only person I can blame when it goes wrong is me. It applies when adding KDE to a system when it’s not there by default.

Third-party repositories cannot be blamed if their packages mess up your system either. They make them and they try their best to ensure it works. It most cases it will work, when it doesn’t, then that’s too bad, it happens. You either use it or you don’t. They didn’t force it on you to use.

SomervilleTom · May 18, 2022, 3:51pm

I hear you.

I think it’s time I finish the job of migrating from KDE/Plasma back to Gnome. I attempted this last November (see my earlier thread), and hit some repo issues at that time.

I apologize for sounding cranky.

My first order of business is to get a reasonable backup, which means (I think) either getting nfs to work from a local fileserver or getting an external volume mounted (through USB3.1). I suspect/hope that rsync is good enough for that.