OK, so I understand 9.4 is out. I’m running Rocky 9.3, Mate edition.
So, I type in “sudo dnf update” and get a stream of errors that I don’t know how to resolve:
Last metadata expiration check: 2:40:11 ago on Fri 10 May 2024 06:17:57 PM EDT.
Error:
Problem 1: package mate-applets-1.26.1-2.el9.x86_64 from @System requires libcpupower.so.0()(64bit), but none of the providers can be installed
cannot install both kernel-tools-libs-5.14.0-427.16.1.el9_4.x86_64 from baseos and kernel-tools-libs-5.14.0-362.24.1.el9_3.0.1.x86_64 from @System
cannot install the best update candidate for package mate-applets-1.26.1-2.el9.x86_64
cannot install the best update candidate for package kernel-tools-libs-5.14.0-362.24.1.el9_3.0.1.x86_64
Problem 2: problem with installed package mate-applets-1.26.1-2.el9.x86_64
package mate-applets-1.26.1-2.el9.x86_64 from @System requires libcpupower.so.0()(64bit), but none of the providers can be installed
package mate-applets-1.26.1-2.el9.x86_64 from epel requires libcpupower.so.0()(64bit), but none of the providers can be installed
cannot install both kernel-tools-libs-5.14.0-427.16.1.el9_4.x86_64 from baseos and kernel-tools-libs-5.14.0-362.24.1.el9_3.0.1.x86_64 from @System
package kernel-tools-5.14.0-427.16.1.el9_4.x86_64 from baseos requires kernel-tools-libs = 5.14.0-427.16.1.el9_4, but none of the providers can be installed
package kernel-tools-5.14.0-427.16.1.el9_4.x86_64 from baseos requires libcpupower.so.1()(64bit), but none of the providers can be installed
cannot install the best update candidate for package kernel-tools-5.14.0-362.24.1.el9_3.0.1.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)
my guess is that none of the repos offers libcpupower.so. If I am right, anyone got any good suggestions?
The issue you’re facing is because there was a library update in our kernels that mate-applets was not built for. The EPEL maintainer needs to rebuild it for the new release.
What I’ve found is a build was started by looking here. It’s tagged as pending. So perhaps a couple days or so and it’ll arrive.
Alternatively, if you’d like to update now and skip the wait to test it out, you could probably download it and update your system with it. The direct link to the package is here. You could probably download this and update that way. (Below is completely untested)
When you attempt to update mate-applets that way, make sure to read the output of what’s being updated along with it. The kernel should be getting updated first and foremost. The final dnf update is to finish getting you to 9.4.
I had the same issue as the OP on the initial 9.4 upgrade attempt. I got around the error by adding the dnf option --allowerasing which on review of the upgrade summary showed the mate-applets would be removed and I then said yes.
I have since followed @nazunalika 's suggestion and installed the mate-opplets package from koji.
Unless I’m feeling really lucky I never use the -y option to dnf or do automatic updates. Especially when adding options like --allowerasing.
Appears to be working as advertised here. I was all set to do some hardware changes when 9.4 was released. Prefer to do the update and check for problems and THEN do the hardware changes.
Yes, although the issue is due to the Mate packages and applets which come from the EPEL repository which is managed and maintained by people outside of the Rocky project. Once they fix the applet issues, then it will be OK to update. Rocky doesn’t maintain Mate.
Similar problems occured with KDE, also from EPEL. This happens unfortunately, when using third party repositories that are outside of RHEL/Rocky main repositories. Until they update and match the RHEL/Rocky dependencies, then that will be the time you can also update. Had you been using for example, Gnome which is the default graphical desktop in RHEL/Rocky, then these kind of issues you wouldn’t be experiencing.
Ideally, you would want to be asking the EPEL team on when they plan on updating their Mate packages. @nazunalika did explain this in his reply 8 days ago.
The issue that is occurring is due to the packages in EPEL, which we do not have direct control over. I have provided a suggestion earlier, which another user in this thread used and they were able to update their system.
You can either follow the suggestion I provided or use dnf update --enablerepo=epel-testing and try to update that way.
but while Rocky isn’t responsible for Mate, they DO provide a Rocky MATE installation disc, so one might hope that whoever built that distro might be involved in making sure it continues to work.
So, I’m trying dnf update --enablerepo=epel-testing, and hoping it doesn't hose my system.
And that Mate build installation disk relies on the packages from EPEL of which the Rocky team has no control over. Is it really that difficult to understand? That build disk can only be fixed to work once packages make it to the stable epel repository, or perhaps by utilising the epel-testing ones.
As you can see, the packages have made it into epel-testing, so at some point soon they will be then pushed out into the main epel repo (stable), at which point this issue will no longer exist anyway.
Also remember, everyone in the Rocky team volunteers their own free time to do everything. They don’t get paid for it. I’m sure the epel team is the same. I suggest you should be a little more patient. Or if it really is that important that all you do is complain about how long it is taking, maybe you actually offer your time and effort to get the problem fixed? And if you can’t do that, then you should just sit and wait until it get resolved. If that takes a week or a month, so be it.
Live image is a convenience created by somebody when all the bits used in the image are available. Anybody could create one. Personally, I have never had a need for such live images; the installer image is all I need and that does not depend on third party repos.
@jukka, @iwalker
Yes, I appreciate all the effort that goes into it! I did not mean any disrespect to anyone, my intention was more to express my discontent, but you have explained it to me and I accept that is the current situation.
I’ll try to be more careful of my tone in the future.
I’ve run dnf as shown early in this thread by nazunalika and got past that error, so I assume that is going to work.
however I now have hit an issue with nvidia components:
Error: Transaction test error:
file /lib/modules/5.14.0-362.8.1.el9_3.x86_64/extra/nvidia/nvidia-drm.ko.xz from install of kmod-nvidia-5.14.0-362.el9_3-3:550.78-1.el9.x86_64 conflicts with file from package kmod-nvidia-5.14.0-362.el9_3-3:550.76-1.el9.x86_64
file /lib/modules/5.14.0-362.8.1.el9_3.x86_64/extra/nvidia/nvidia-modeset.ko.xz from install of kmod-nvidia-5.14.0-362.el9_3-3:550.78-1.el9.x86_64 conflicts with file from package kmod-nvidia-5.14.0-362.el9_3-3:550.76-1.el9.x86_64
file /lib/modules/5.14.0-362.8.1.el9_3.x86_64/extra/nvidia/nvidia-peermem.ko.xz from install of kmod-nvidia-5.14.0-362.el9_3-3:550.78-1.el9.x86_64 conflicts with file from package kmod-nvidia-5.14.0-362.el9_3-3:550.76-1.el9.x86_64
file /lib/modules/5.14.0-362.8.1.el9_3.x86_64/extra/nvidia/nvidia-uvm.ko.xz from install of kmod-nvidia-5.14.0-362.el9_3-3:550.78-1.el9.x86_64 conflicts with file from package kmod-nvidia-5.14.0-362.el9_3-3:550.76-1.el9.x86_64
file /lib/modules/5.14.0-362.8.1.el9_3.x86_64/extra/nvidia/nvidia.ko.xz from install of kmod-nvidia-5.14.0-362.el9_3-3:550.78-1.el9.x86_64 conflicts with file from package kmod-nvidia-5.14.0-362.el9_3-3:550.76-1.el9.x86_64
I don’t understand why this error occurs, since they all have something to do with “conflicts” between the same two packages, and one of them is newer and should replace the older.
but, wondering if it could be resolved (without leaving my system inoperable) by removing kmod-nvidia-5.14.0-362.el9_3-3:550.76-1.el9.x86_64 and then installing nvidia-5.14.0-362.el9_3-3:550.78-1.el9.x86_64, THEN running the update?
