Upgrade OM Lx 4.2 to Rolling

Currently (2021-06-25) you would be upgrading from OM Lx 4.2.

  1. Preparation: User needs to be sure they have enough free space on their / (root) partition to do this transition. It is difficult to know a precise number for this as people add software and everyones system is different. We do know that applications like Flatpak eat up a lot of disk space. For now it is estimated that for most users 5 GB of free space should be enough. Before proceeding you should fully upgrade your OM Lx 4.2 system.

  2. The actual transition process begins: Change your repositories (all of them) from either Rock or Release to Rolling with the “Software Repository Selector”. Note: It is very important that all of your repositories are for the same branch, in this case Rolling so every single repository should have Rolling in file name. Disable for now all non-free, restricted and unsupported repositories. This way you are mostly upgrading “system” software. The other stuff can be upgraded after this transition.

    Check that you have only Rolling and Rolling updates repositories enabled with this command:

    $ dnf repolist

  3. About the Rolling upgrade.

    This is a major upgrade. Like any major software change you absolutely have to do this the correct way.

    It is ultra, hugely, majorly, important that you run “sudo dnf clean all ; dnf clean all” before doing this procedure. dnf clean all removes anything leftover in cache and forces dnf to download the latest metadata from repositories ensuring that users gets the latest available software. Do not skip this step.

    Do not use sudo dnf upgrade for this.

    It is important that you upgrade to Rolling the correct way:

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

    At the end there are some questions asked about keeping current file or installing the package maintainers version. Normally accepting the defaults is safe. Packages you for sure want to keep the existing file are the ones that have your users, groups, and passwords. They are:

    /etc/group
    /etc/gshadow
    /etc/passwd
    /etc/shadow
    

    For those always select to keep the existing file.

    Note: Do not use Discover or dnfdragora to upgrade a Rolling system. They use a command that is fine for our regular stable release but is not correct for the dynamic changes that happen with Rolling.

  4. There has been a bug regarding some incorrect symlinks to library files that has affected some users. To avoid this issue after the `dnf distro-sync’ completes users should run the following commands:

    First you have to remove the old symlinks to these:

    $ sudo rm /usr/lib64/libicudata.so.68 /usr/lib64/libicui18n.so.68 /usr/lib64/libicuuc.so.68

    Then you need to create new symbolic links between these:

    $ sudo ln -s /usr/lib64/libicudata.so.69.1 /usr/lib64/libicudata.so.68
    
    $ sudo ln -s /usr/lib64/libicui18n.so.69.1 /usr/lib64/libicui18n.so.68
    
    $ sudo ln -s /usr/lib64/libicuuc.so.69.1 /usr/lib64/libicuuc.so.68
    

    You are removing an outdated, incorrect link to the .so.68 files and replacing the link with the correct, updated one.

  5. Reboot into your new Rolling system.

  6. If you encounter any problems please report each issue in a new post in the Support Forum with a descriptive title and enough information so other people can help.

Note: There is an excellent “How To” describing this process with screen-shots here. The screen-shots can be especially helpful for users struggling with decisions in the dialog at the end where the system asks if you want to accept new files created by package maintainer or keep your old files.

Whether you answer yes or no to keep files or accept the new version depends on the file. For /etc/passwd , /etc/shadow , /etc/group , and /etc/gshadow you generally would want to keep the original files. For .repo files or files about grub2 you generally want to accept the new files. There sometimes may be other files with these Y or N questions.

I will ask developers a few questions about this and post some more about this here later.

I just found out here that some users may be affected by this bug.

I just found out here that some users will be affected by this bug after they reboot.

First you have to remove the old symlinks to these:

$ sudo rm /usr/lib64/libicudata.so.68 /usr/lib64/libicui18n.so.68 /usr/lib64/libicuuc.so.68

Then you need to create new symbolic links between these:

$ sudo ln -s /usr/lib64/libicudata.so.69.1 /usr/lib64/libicudata.so.68

$ sudo ln -s /usr/lib64/libicui18n.so.69.1 /usr/lib64/libicui18n.so.68

$ sudo ln -s /usr/lib64/libicuuc.so.69.1 /usr/lib64/libicuuc.so.68

Edit: You are removing an outdated, incorrect link to the .so.68 files and replacing the link with the correct, updated one. I have done this multiple times in VBox VM’s and in hardware systems.

As of 2021-06-04 Rolling is also OM Lx 4.3. When we do the final (GA) release of OM Lx 4.3 we will split the repositories and OM Lx 4.3 will become our latest stable branch. Rolling will still be Rolling and will eventually become OM Lx 5.0. At least that is the current plan. One starts to see how Rolling just keeps rolling.

This thread updated 2021-06-25 to reflect knowledge gained from our users and contributors.