Upgrade from v8 to v9 - how to get "clean" state at the end

Rocky Linux Help & Support
1

Hi,

in some PoC, I had to test possibility to upgrade from Rocky linux v8.x to v9.x. The gole I expected is, to have v9.x after upgrade, and then to execute “yum update -f” which will return no errors.
To do that, I started with official v8.6 minimal installation ISO file, and installed test virtual machine.
Then, I made full update (yum update -y), and that finished with update to v8.9.
Then, I followed some of available web linkes, where upgrade from v8 to v9 is explained (here is the list for references):

To be clear, I tried with first link in this list.
Upgrade was done without any significant issues.

So, I started with:

[root@rockyvm ~]# cat /etc/os-release
NAME=“Rocky Linux”
VERSION=“8.9 (Green Obsidian)”
ID=“rocky”
ID_LIKE=“rhel centos fedora”
VERSION_ID=“8.9”
PLATFORM_ID=“platform:el8”
PRETTY_NAME=“Rocky Linux 8.9 (Green Obsidian)”
ANSI_COLOR=“0;32”
LOGO=“fedora-logo-icon”
CPE_NAME=“cpe:/o:rocky:rocky:8:GA”
…
SUPPORT_END=“2029-05-31”
ROCKY_SUPPORT_PRODUCT=“Rocky-Linux-8”
ROCKY_SUPPORT_PRODUCT_VERSION=“8.9”
REDHAT_SUPPORT_PRODUCT=“Rocky Linux”
REDHAT_SUPPORT_PRODUCT_VERSION=“8.9”
[root@rockyvm ~]#

And, after following first link, after upgrading and restarting, I finished with:

[root@rockyvm ~]# date
Thu Dec 7 12:16:06 CET 2023
[root@rockyvm ~]# cat /etc/os-release
NAME=“Rocky Linux”
VERSION=“9.3 (Blue Onyx)”
ID=“rocky”
ID_LIKE=“rhel centos fedora”
VERSION_ID=“9.3”
PLATFORM_ID=“platform:el9”
PRETTY_NAME=“Rocky Linux 9.3 (Blue Onyx)”
ANSI_COLOR=“0;32”
LOGO=“fedora-logo-icon”
CPE_NAME=“cpe:/o:rocky:rocky:9::baseos”
…
SUPPORT_END=“2032-05-31”
ROCKY_SUPPORT_PRODUCT=“Rocky-Linux-9”
ROCKY_SUPPORT_PRODUCT_VERSION=“9.3”
REDHAT_SUPPORT_PRODUCT=“Rocky Linux”
REDHAT_SUPPORT_PRODUCT_VERSION=“9.3”
[root@rockyvm ~]#

Everything seems to be fine, so far. But, then I tried to update again, and I got the following:

[root@rockyvm ~]# dnf update
Last metadata expiration check: 0:15:09 ago on Thu 07 Dec 2023 12:07:33 PM CET.
Error:
Problem 1: cannot install both gdbm-libs-1:1.19-4.el9.x86_64 from baseos and gdbm-libs-1:1.18-2.el8.x86_64 from @System

  • package gdbm-1:1.18-2.el8.x86_64 from @System requires gdbm-libs(x86-64) = 1:1.18-2.el8, but none of the providers can be installed
  • cannot install the best update candidate for package gdbm-libs-1:1.18-2.el8.x86_64
  • problem with installed package gdbm-1:1.18-2.el8.x86_64
    Problem 2: cannot install both iptables-libs-1.8.8-6.el9_1.x86_64 from baseos and iptables-libs-1.8.5-9.el8.x86_64 from @System
  • package iptables-1.8.5-9.el8.x86_64 from @System requires iptables-libs(x86-64) = 1.8.5-9.el8, but none of the providers can be installed
  • cannot install the best update candidate for package iptables-libs-1.8.5-9.el8.x86_64
  • problem with installed package iptables-1.8.5-9.el8.x86_64
    Problem 3: cannot install both libevent-2.1.12-6.el9.x86_64 from baseos and libevent-2.1.8-5.el8.x86_64 from @System
  • package python3-unbound-1.16.2-5.el8.x86_64 from @System requires libevent-2.1.so.6()(64bit), but none of the providers can be installed
  • cannot install the best update candidate for package libevent-2.1.8-5.el8.x86_64
  • problem with installed package python3-unbound-1.16.2-5.el8.x86_64
    Problem 4: package python3-3.9.18-1.el9_3.x86_64 from baseos obsoletes platform-python < 3.9 provided by platform-python-3.6.8-56.el8_9.rocky.0.x86_64 from @System
  • package python3-html5lib-1:0.999999999-6.el8.noarch from @System requires python(abi) = 3.6, but none of the providers can be installed
  • cannot install the best update candidate for package platform-python-3.6.8-56.el8_9.rocky.0.x86_64
  • problem with installed package python3-html5lib-1:0.999999999-6.el8.noarch
    Problem 5: cannot install both python3-libs-3.9.18-1.el9_3.x86_64 from baseos and python3-libs-3.6.8-56.el8_9.rocky.0.x86_64 from @System
  • package unbound-libs-1.16.2-5.el8.x86_64 from @System requires libpython3.6m.so.1.0()(64bit), but none of the providers can be installed
  • cannot install the best update candidate for package platform-python-pip-9.0.3-23.el8.rocky.0.noarch
  • problem with installed package unbound-libs-1.16.2-5.el8.x86_64
    Problem 6: package python3-unbound-1.16.2-5.el8.x86_64 from @System requires libpython3.6m.so.1.0()(64bit), but none of the providers can be installed
  • cannot install both python3-libs-3.9.18-1.el9_3.x86_64 from baseos and python3-libs-3.6.8-56.el8_9.rocky.0.x86_64 from @System
  • cannot install the best update candidate for package python3-unbound-1.16.2-5.el8.x86_64
  • cannot install the best update candidate for package platform-python-setuptools-39.2.0-7.el8.noarch
    Problem 7: package unbound-libs-1.16.2-5.el8.x86_64 from @System requires libpython3.6m.so.1.0()(64bit), but none of the providers can be installed
  • cannot install both python3-libs-3.9.18-1.el9_3.x86_64 from baseos and python3-libs-3.6.8-56.el8_9.rocky.0.x86_64 from @System
  • cannot install the best update candidate for package unbound-libs-1.16.2-5.el8.x86_64
  • cannot install the best update candidate for package python3-libs-3.6.8-56.el8_9.rocky.0.x86_64
    Problem 8: package python3-3.9.18-1.el9_3.x86_64 from baseos obsoletes platform-python < 3.9 provided by platform-python-3.6.8-56.el8_9.rocky.0.x86_64 from @System
  • package blktrace-1.2.0-19.el9.x86_64 from appstream requires /usr/bin/python3, but none of the providers can be installed
  • package python3-pydbus-0.6.0-5.el8.noarch from @System requires python(abi) = 3.6, but none of the providers can be installed
  • cannot install the best update candidate for package blktrace-1.2.0-10.el8.x86_64
  • problem with installed package python3-pydbus-0.6.0-5.el8.noarch
    Problem 9: package python3-3.9.18-1.el9_3.x86_64 from baseos obsoletes platform-python < 3.9 provided by platform-python-3.6.8-56.el8_9.rocky.0.x86_64 from @System
  • package cockpit-bridge-300.1-1.el9_3.x86_64 from baseos requires /usr/bin/python3, but none of the providers can be installed
  • package cockpit-bridge-300.1-1.el9_3.x86_64 from baseos requires python(abi) = 3.9, but none of the providers can be installed
  • package python3-slip-0.6.4-13.el8.noarch from @System requires python(abi) = 3.6, but none of the providers can be installed
  • cannot install the best update candidate for package cockpit-bridge-300.1-1.el8_9.x86_64
  • problem with installed package python3-slip-0.6.4-13.el8.noarch
    Problem 10: package python3-3.9.18-1.el9_3.x86_64 from baseos obsoletes platform-python < 3.9 provided by platform-python-3.6.8-56.el8_9.rocky.0.x86_64 from @System
  • package cockpit-storaged-300.1-1.el9_3.noarch from appstream requires /usr/bin/python3, but none of the providers can be installed
  • package python3-slip-dbus-0.6.4-13.el8.noarch from @System requires python(abi) = 3.6, but none of the providers can be installed
  • cannot install the best update candidate for package cockpit-storaged-300.1-1.el8_9.noarch
  • problem with installed package python3-slip-dbus-0.6.4-13.el8.noarch
    Problem 11: package python3-3.9.18-1.el9_3.x86_64 from baseos obsoletes platform-python < 3.9 provided by platform-python-3.6.8-56.el8_9.rocky.0.x86_64 from @System
  • package firewalld-1.2.1-1.el9.noarch from baseos requires /usr/bin/python3, but none of the providers can be installed
  • package python3-webencodings-0.5.1-6.el8.noarch from @System requires python(abi) = 3.6, but none of the providers can be installed
  • cannot install the best update candidate for package firewalld-0.9.11-1.el8_8.noarch
  • problem with installed package python3-webencodings-0.5.1-6.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)
    [root@rockyvm ~]#

I then tried to use any of 3 mentioned command switch-es (‘–allowerasing’, ‘–skip-broken’ and ‘–nobest’, but never reach clean update, without any warnings/errors.

My question is: how can I proceed, to get “dnf update” (or “yum update”) to finish without any errors/warnings, and to get “clean” state of v9.3 (as this is the latest v9.x version at the moment).

2

Upgrades of Rocky are unsupported. The system should be installed from new, restoring your user data.

3

Any other opinion?
If I am not wrong, RHEL supports migration from RHEL v8 to v9 ( https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/upgrading_from_rhel_8_to_rhel_9/index ). I expected that same could be available on Rocky Linux.

Any information if that could be available in near future?

4

Your system is mixed with both el8 and el9 packages. Your system is considered unstable and it is unlikely you’ll be able to recover from this cleanly. You are recommended to do a fresh installation of Rocky Linux 9 and restore from any backups you’ve taken.

Major version upgrades of Rocky Linux will remain unsupported.

At the most basic level, upgrades involve this as a start:

  • glibc version upgrade (which involves more than just a glibc version upgrade, this also involves hardware requirement changes, e.g. x86-64-v2)
  • rpm version upgrade (credit to some guides, they point out rpm --rebuilddb, but there is no guarantee of even this working post upgrade)
  • many more version upgrades of software

It is not reasonable for us, as a project, to support major version upgrades. Everyone’s system’s will have different configurations from the next. Not everyone’s system’s are cookie-cutter. It cannot be possible for us to account for every possible upgrade situation. Red Hat can support, within reason, major version upgrades for their paying customers. Their customers pay for that kind of support. As this is a community-driven project, we are not able to put in the resources nor the time for that type of effort.

The above link notes upgrades will remain unsupported. It also notes ELevate, which is a project we do not work on nor do we have our hands in. It claims it can do system upgrades, but we do not have any formal experience in it.

For those who wish to have a way for our project to support major version upgrades in the future and are willing to put in any spare time working within the project for it: We highly recommend you joining our Mattermost and opening a discussion on it. This can be done in SIG/General, stating your case, and perhaps providing the means of bootstrapping that type of effort.

5

Chapter 9.3 in that document has long list of Known Issues – setups that can/will fail to migrate.
How much support would you expect from Red Hat for cases that they already remark: “won’t work on that”?

The RHEL migration (I’d rather say in-place conversion to different distro) is with tool Leapp and the tool depends on data (instructions, I presume). That data is RHEL-specific and not public, AFAIK.
The ELevate (by AlmaLinux project) has the Leapp and data provided by Oracle, or something like that.
The ELevate is at best as good as RHEL version, but as noted even the RHEL migration can fail.

Overall, there are many cases where a system can become unusable – (broken hardware, fire, earthquake, hacker, user error, etc). Therefore, one should always have a procedure for reinstall and restore of data. If one has such procedure, then fresh install of new distro should be relatively trivial – only the config to deploy will need adjustments.

6

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.