@ben79 published a great how-to convert a Rock system to more cool Rolling system.
I have followed the guide step by step and can confirm it’s working very well.
Rock is currently Lx 4.1 it will become Lx 4.2 when Lx 4.2 is released. However this will require users to upgrade their systems with the sudo dnf --allowerasing distro-sync command.
In other words what happens with Rock is that when there is a new stable release developers literally change the repositories. In this case they will change from OM Lx 4.1 repositories to OM Lx 4.2 repositories.
Is there a way to avoid this? Yes, if user opens ‘Software Repository Selector’ and changes channel from Rock to Release then your repositories will remain at OM Lx 4.1 until you decide to make this change.
Currently Rolling is OM Lx 4.2 Beta. Rock and Release are both OM Lx 4.1. Rock changes Release does not.
So the workflow for OpenMandriva releases is Cooker>Rolling>Rock/Release
Rock=repositories are automatically switched by developers when there is a new release.
Release=repositories stay at same version until user changes them.
Hope this is helpful. Also I hope this is easier to understand than it was to write. I can understand if a user may find this confusing.
Yes, Rolling is also Lx 4.2. If one does this conversion today you will have the equivalent of an upgrade from OM Lx 4.1 to OM Lx 4.2 Beta. I’ll change the thread title to make this more obvious.
IMO OM Lx 4.2 Beta is better right now than OM Lx 4.1, it is certainly more up to date.
The terms Cooker, Rolling, Rock, and Release are repository names. Also called channel names.
i have trouble on 2 points
file ended to update ( rpmnew)
one with dll ?
one with sddm
on reboot wayland or failback x cant work , only plasma
in have
déc. 17 23:22:59 omd multipath[715]: Checker 'tur' not found in /lib64/multipath
déc. 17 23:22:59 omd multipath[715]: failed to initialize checkers
déc. 17 23:22:59 omd multipath[719]: Checker 'tur' not found in /lib64/multipath
déc. 17 23:22:59 omd multipath[719]: failed to initialize checkers
déc. 17 23:22:59 omd multipath[714]: Checker 'tur' not found in /lib64/multipath
déc. 17 23:22:59 omd multipath[714]: failed to initialize checkers
déc. 17 23:22:59 omd multipath[713]: Checker 'tur' not found in /lib64/multipath
déc. 17 23:22:59 omd multipath[712]: Checker 'tur' not found in /lib64/multipathdéc. 17 23:22:59 omd multipath[713]: failed to initialize checkers
déc. 17 23:22:59 omd multipath[712]: failed to initialize checkers
déc. 17 23:22:59 omd multipath[784]: Checker 'tur' not found in /lib64/multipath
déc. 17 23:22:59 omd multipath[784]: failed to initialize checkers
déc. 17 23:23:00 omd systemd[878]: -.slice: Failed to migrate controller cgroups from /user.slice/user-981.slice/user@981.service, ignorin>
déc. 17 23:23:00 omd dbus-broker-launch[895]: Service file '/usr/share/dbus-1/services/org.kde.activitymanager.service' is not named after>
déc. 17 23:23:00 omd dbus-broker-launch[895]: Service file '/usr/share/dbus-1/services/org.kde.baloorunner.service' is not named after the>
déc. 17 23:23:00 omd dbus-broker-launch[895]: Service file '/usr/share/dbus-1/services/org.kde.dolphin.FileManager1.service' is not named >
déc. 17 23:23:00 omd dbus-broker-launch[895]: Service file '/usr/share/dbus-1/services/org.kde.plasma.Notifications.service' is not named >
déc. 17 23:23:00 omd dbus-broker-launch[895]: Service file '/usr/share/dbus-1/services/obex-client.service' is not named after the D-Bus n>
déc. 17 23:23:00 omd dbus-broker-launch[895]: Service file '/usr/share/dbus-1/services/org.kde.kscreen.service' is not named after the D-B>
...
plasmashell dump
...
I don’t understand what this means. But I do very much appreciate @stephane posting his experience for other users.
The “How To” for this is based on a default system installed from the Lx 4.1 ISO upgraded and then converted with the explained steps. Thus there would be no 32 bit (i686) packages involved, no third party software, no other OM packages, ect. So if a user has any of these there obviously may be some problem solving involved. That is the nature of this type of upgrade. Also this is one reason of several reasons why any Linux distro will recommend a fresh install over a system upgrade.
For third party software it is impossible for us to predict what may happen. One big reason would be the entire system tool-chain is going to be different. The library packages will mostly be different and newer. Completely different versions of the compiler software gcc and clang/llvm. So it may be advisable to remove third party software, then do the conversion, then re-install the third party software.
Frankly if I had a system with a lot of added packages from OM and/or third parties I would not do this conversion I would do a fresh install. Doesn’t mean it can not be done, but problems are to be expected and solved by user. We will try to help if we can.
Regarding third party software a Linux distro does not have control over third party entities so we just can’t do much. A distro like OM with no employee’s, no one full time, not much money or other resources to speak of just can’t be responsible for something like this. So we will try to help in these matters if we can.
The standard “Third Party Sofware” statement:
If user chooses to install third party software then any problems are the users responsibility.
Your choice=your responsibility.
Off-topic Post-edit: Regarding the “no money” comment above every OM user should have a least one of these shirts.
I can understand if a user may find this confusing.