Attention Rock users: Rock repositories switched to OM Lx 4.2

Hello,

The steps listed here may be overkill but this is done this way in an attempt to avoid issues for our users. It is impossible to anticipate what problems may occur with 3rd party packages or expecially 3rd party repositories. By all means if you have any non-OpenMandriva repositories enabled, disable them before doing this.

  • OpenMandriva Lx version:

Rock/OM Lx 4.1

  • Description of the issue (screenshots if relevant):

Rock repositories switched to OM Lx 4.2. If user attempts to upgrade with Discover, dnfdragora, or with command ‘dnf upgrade’ there will be at a minimum these issues:

$ sudo dnf clean all ; sudo dnf distro-sync
[sudo] password for open: 
12 files removed
OpenMandriva Rock - znver1                                                                                                                                                        4.1 MB/s |  24 MB     00:05    
OpenMandriva Rock - znver1 - Updates                                                                                                                                              215  B/s | 344  B     00:01    
Error: 
 Problem 1: package lib64opencv_dnn3.4-3.4.9-1.znver1 requires libprotobuf.so.15()(64bit), but none of the providers can be installed
  - protobuf-3.5.2-3.znver1 does not belong to a distupgrade repository
  - problem with installed package lib64opencv_dnn3.4-3.4.9-1.znver1
 Problem 2: package lib64orcus-parser0.15_0-0.15.3-1.znver1 requires libboost_filesystem.so.1.72.0()(64bit), but none of the providers can be installed
  - lib64boost_filesystem1.72.0-1.72.0-4.znver1 does not belong to a distupgrade repository
  - problem with installed package lib64orcus-parser0.15_0-0.15.3-1.znver1
 Problem 3: package lib64orcus0.15_0-0.15.3-1.znver1 requires libboost_iostreams.so.1.72.0()(64bit), but none of the providers can be installed
  - lib64boost_iostreams1.72.0-1.72.0-4.znver1 does not belong to a distupgrade repository
  - problem with installed package lib64orcus0.15_0-0.15.3-1.znver1
 Problem 4: package python-json-3.4-12.noarch requires python(abi) = 3.8, but none of the providers can be installed
  - python-3.8.1-3.znver1 does not belong to a distupgrade repository
  - problem with installed package python-json-3.4-12.noarch
 Problem 5: package lib64opencv_dnn4.5-4.5.1-1.znver1 requires libprotobuf.so.23()(64bit), but none of the providers can be installed
  - package lib64digikamcore7.2.0-7.2.0-0.beta2.2.znver1 requires libopencv_dnn.so.4.5()(64bit), but none of the providers can be installed
  - cannot install both protobuf-3.12.3-1.znver1 and protobuf-3.5.2-3.znver1
  - package digikam-7.2.0-0.beta2.2.znver1 requires libdigikamcore.so.7.2.0()(64bit), but none of the providers can be installed
  - package lib64opencv_dnn3.4-3.4.9-1.znver1 requires libprotobuf.so.15()(64bit), but none of the providers can be installed
  - problem with installed package digikam-7.0.0-2.znver1
  - package lib64digikamcore7.0.0-7.0.0-2.znver1 requires libopencv_dnn.so.3.4()(64bit), but none of the providers can be installed
  - digikam-7.0.0-2.znver1 does not belong to a distupgrade repository
  - problem with installed package lib64digikamcore7.0.0-7.0.0-2.znver1
 Problem 6: package lib64opencv_dnn4.5-4.5.1-1.znver1 requires libprotobuf.so.23()(64bit), but none of the providers can be installed
  - package lib64opencv_video4.5-4.5.1-1.znver1 requires libopencv_dnn.so.4.5()(64bit), but none of the providers can be installed
  - cannot install both protobuf-3.12.3-1.znver1 and protobuf-3.5.2-3.znver1
  - package frei0r-plugins-1.7.0-3.znver1 requires libopencv_video.so.4.5()(64bit), but none of the providers can be installed
  - package lib64opencv_dnn3.4-3.4.9-1.znver1 requires libprotobuf.so.15()(64bit), but none of the providers can be installed
  - problem with installed package frei0r-plugins-1.7.0-1.znver1
  - package lib64digikamgui7.0.0-7.0.0-2.znver1 requires libopencv_dnn.so.3.4()(64bit), but none of the providers can be installed
  - frei0r-plugins-1.7.0-1.znver1 does not belong to a distupgrade repository
  - problem with installed package lib64digikamgui7.0.0-7.0.0-2.znver1
 Problem 7: package lib64opencv_dnn4.5-4.5.1-1.znver1 requires libprotobuf.so.23()(64bit), but none of the providers can be installed
  - package lib64opencv_video4.5-4.5.1-1.znver1 requires libopencv_dnn.so.4.5()(64bit), but none of the providers can be installed
  - cannot install both protobuf-3.12.3-1.znver1 and protobuf-3.5.2-3.znver1
  - package mlt-6.24.0-2.znver1 requires libopencv_video.so.4.5()(64bit), but none of the providers can be installed
  - package lib64opencv_dnn3.4-3.4.9-1.znver1 requires libprotobuf.so.15()(64bit), but none of the providers can be installed
  - problem with installed package mlt-6.18.0-2.znver1
  - package lib64opencv_tracking3.4-3.4.9-1.znver1 requires libopencv_dnn.so.3.4()(64bit), but none of the providers can be installed
  - mlt-6.18.0-2.znver1 does not belong to a distupgrade repository
  - problem with installed package lib64opencv_tracking3.4-3.4.9-1.znver1
 Problem 8: package lib64opencv_dnn4.5-4.5.1-1.znver1 requires libprotobuf.so.23()(64bit), but none of the providers can be installed
  - cannot install both protobuf-3.12.3-1.znver1 and protobuf-3.5.2-3.znver1
  - package lib64digikamcore7.2.0-7.2.0-0.beta2.2.znver1 requires libopencv_dnn.so.4.5()(64bit), but none of the providers can be installed
  - package lib64opencv_dnn3.4-3.4.9-1.znver1 requires libprotobuf.so.15()(64bit), but none of the providers can be installed
  - package showfoto-7.2.0-0.beta2.2.znver1 requires libdigikamcore.so.7.2.0()(64bit), but none of the providers can be installed
  - package lib64digikamcore7.0.0-7.0.0-2.znver1 requires libopencv_dnn.so.3.4()(64bit), but none of the providers can be installed
  - problem with installed package showfoto-7.0.0-2.znver1
  - package lib64digikamdatabase7.0.0-7.0.0-2.znver1 requires libdigikamcore.so.7.0.0()(64bit), but none of the providers can be installed
  - showfoto-7.0.0-2.znver1 does not belong to a distupgrade repository
  - problem with installed package lib64digikamdatabase7.0.0-7.0.0-2.znver1
(try to add '--allowerasing' to command line to replace conflicting packages or '--skip-broken' to skip uninstallable packages)

Unfortunately Discover, dnfdragora, or command ‘dnf upgrade’ will attempt to resolve those issues anyway and upgrade your system. This will not produce the best result and may result in problems. For this process to work properly you need (this is a must really) to upgrade with:

$ sudo dnf clean all ; sudo dnf --allowerasing distro-sync

So let’s back up a step and discuss what to do if you do not want to do this procedure now, or are not sure if you want to. I created a test example in VirtualBox so I can do this step by step and take screen-shots to illuminate users.

Now we open the Software Repository Selector and you should find it set to Rock:

In the drop down menu change that to Release and select OK. You will be asked for your password, enter that and select OK. If successful you will see this:

To be sure we run this command in Konsole (terminal):

$ dnf repolist

Result:

Now run this command to upgrade and sync everything with the Release repositories:

$ sudo dnf clean all ; sudo dnf --allowerasing distro-sync

Reboot your system for the new kernel, if new kernel was installed. If you don’t wish to upgrade to OM Lx 4.2 right away you are all set. If you do wish to upgrade go ahead and do everything as described above just to be sure you Lx 4.1 system is up to date before we do the “distro-sync” to OM Lx 4.2. We will do exactly that in the next post.

Note for more technically minded users: If you run ‘dnf clean all’ there is no need to use the option --refresh, refreshing is forced after you run ‘dnf clean all’.

Post-edit: The problems I posted about in this edit have been resolved.

1 Like

Note: It is generally better to do a fresh install than upgrading an existing system if you can manage this. OM Lx 4.2 Release announcement and link to installation media here.

If you have any third party repositories disable them before doing this. It is impossible to predict what may happen with 3rd party software with a system upgrade. The example is using a default system with no additional software installed. If any additional software is OM software there should not be any problem. If you do encounter issues let us know in a new thread devoted to your specific issue. If you post a thread with multiple issues you are likely to only get one issue answered so do not do that.

First the reason for the delay. When we switch Rock repositories to a new release there is a massive transfer of data that has to take place in steps. This takes quite a bit of time and I needed to wait until the process was complete.

Be sure that you have fully upgraded your Lx 4.1 system as described in the first post. My example test is done on a znver1 system if you have a x86_64 system you will see x86_64 instead of znver1 in the examples.

Now for the OM Lx 4.2 to 4.2 system upgrade:

Use Software Repository Selector to switch your repositories to Rock. Open Konsole (or other terminal) and upgrade your system with this command (this is a big transaction):

$ sudo dnf clean all ; sudo dnf --allowerasing distro-sync

At the end of this upgrade process you will see some scripts that run and ask user questions. If you read the output this is well explained for each script. I answered them like this:

I selected “Y” to install the package maintainers version for a few. The ones where I selected “Y”:

Configuration file ‘/etc/yum.repos.d/openmandriva-cooker-x86_64.repo’
Configuration file ‘/etc/yum.repos.d/openmandriva-release-x86_64.repo’
Configuration file ‘/etc/yum.repos.d/openmandriva-rock-x86_64.repo’
Configuration file ‘/etc/yum.repos.d/openmandriva-rolling-x86_64.repo’
Configuration file ‘/etc/default/grub’

For everything else I accepted the default suggestion by simply pressing the Enter key on keyboard.

If you accept the default for everything you will end up with the old mirror.list instead of Mirrorbits which is a notable improvement. That is why I suggest to accept the new files for all the .repo files. If you accept the default for grub you may miss changes in how grub boots newer kernels so also it is recommenced to accept the new file for grub. Otherwise for the rest the default is good.

Then before you reboot run these commands:

$ sudo rpm --rebuilddb -vvv

$ sudo dnf install plasma-workspace-x11 ; sudo dnf reinstall distro-release-theme

Reboot in to your new OM Lx 4.2 system.

This process is discussed in more detail here and there are screenshots. Also well described here in Italian. Use a translator if you need to. The Italian version by @rugyada has even better screenshots.

As you can see we have been testing this since OM Lx 4.2 Alpha. However with system upgrades like this it is always possible that some users will experience issues. That is why we continue to suggest preference for fresh installs if at all possible.