I have successfully upgraded to Rocky Linux 9;
It doesn’t work. Fails on:
dnf -y --releasever=9 --allowerasing --setopt=deltarpm=false distro-sync
with a whole load of perl, python dependency errors. Also, best to use official links to the Rocky mirror to be sure they are official rpm’s. This can also depend on the amount of packages installed and from what location, so the upgrade process is pretty risky. I’m attempting some other parameters, but it looks like I will have to remove some of them to get that stage to work.
Not only that, officially upgrades are not supported, therefore only clean installs are recommended by the Rocky team.
These are mentioned in the last description. The default python of linux8 is 3.6, and linux9 becomes 3.8. It will be automatically upgraded. After the upgrade is over, 3.6 will be automatically removed, but because 3.6 is used in the kernel, it does not actually exist. And 3.8 has also been created, you just need to disable or remove 3.6 from the module and it will automatically use 3.8. Unless your application is not compatible with python3.8, this method is feasible; if it is a python production environment, it is not recommended to upgrade. Because I am in a java environment and don’t rely on python, I can upgrade as much as I want and enjoy the latest system
Yeah, I had to extend it:
First failure that had to be addressed:
dnf -y --releasever=9 --allowerasing --nobest --setopt=deltarpm=false distro-sync
--nobest to get through it. Any package complaints I had to remove, so:
dnf remove ruby-irb
some of the commands in between were not needed, so the epel-rpm-macros-systemd and removing redhat-logos:
dnf module disable perl:5.26 perl-IO-Socket-SSL:2.066 perl-libwww-perl:6.34 python36:3.6 httpd javapackages-tools maven ruby virt python38
this command wasn’t needed as it was already installed:
dnf -y install kernel kernel-core shim
There were still 45+ packages from el8 still installed, so requires a cleanup:
rpm -qa | grep el8 | sort
technically you could do this:
dnf remove -y `rpm -qa | grep el8`
but I went down the list removing the leftovers just in case too much of the system got uninstalled. But I expect it would have worked though. Those packages wouldn’t upgrade so needed removing. According to the dnf update command the system was up-to-date, so these were just leftovers - most likely from the modules I was using.
And I used the official rocky mirror for the packages in the first step, so:
dnf -y install https://download.rockylinux.org/pub/rocky/9/BaseOS/x86_64/os/Packages/r/rocky-release-9.0-2.1.el9.noarch.rpm https://download.rockylinux.org/pub/rocky/9/BaseOS/x86_64/os/Packages/r/rocky-repos-9.0-2.1.el9.noarch.rpm https://download.rockylinux.org/pub/rocky/9/BaseOS/x86_64/os/Packages/r/rocky-gpg-keys-9.0-2.1.el9.noarch.rpm
my system does work now with Rocky 9 though, so works but just need to be careful and the procedure will need to be edited to different installation scenarios.
As seen on CentOS Forums:
“If you break it, then you can keep the pieces.”
upgrade virtual machine running rocky 8.6 to rocky 9 following method
- same package as your first step but using wget download package and install package separate
rpm -ivh rocky-gpg-keys-9.0-2.1.el9.noarch.rpm
2.dnf install --skip-broken rocky-release-9.0-2.1.el9.noarch.rpm rocky-repos-9.0-2.1.el9.noarch.rpm
- dnf update --allowerasing
- dnf update
- when you run dnf update you may get following error
warning: Found bdb_ro Packages database while attempting sqlite backend: using bdb_ro backend. solving this using
1960991 – RPM unusable following upgrade to Fedora 34: cannot open Packages index using bdb_ro - Operation not permitted (1)
- dnf install sqlite2 , restorecon -Rv /var/lib/rpm , rpmdb --rebuilddb
- you may get this error also
Problem …: conflicting requests refer below just reset conflict package
Resolve conflicting requests with perl:5.26 – it.megocollector.com
yum module reset httpd:2.4 mariadb:10.3 nginx:1.14 perl:5.26 php:7.4 for my case
- grub2-mkconfig -o /boot/grub2/grub.cfg [ precaution step to avoid boot issue]
I have made several upgrade attempts using the information in this thread.
I have found that disabling all modules via dnf module -y disable "" before starting the package upgrade makes the process a lot smoother.
There have been multiple snags along the way.
Once the package upgrade process finishes, a handful of packages are corrupt, such that I cannot uninstall or even list their names. For example, here is what I see when I look for el8 packages hanging around:
$ rpm -qa | grep el8 | sort error: rpmdbNextIterator: skipping h# 538 Header V3 RSA/SHA1 Signature, key ID 158b3811: BAD Header SHA256 digest: OK Header SHA1 digest: OK error: rpmdbNextIterator: skipping h# 1308 Header V3 RSA/SHA1 Signature, key ID bdda8475: BAD Header SHA256 digest: OK Header SHA1 digest: OK aspell-0.60.6.1-22.el8.x86_64 autogen-libopts-5.18.12-8.el8.1.x86_64 bind-export-libs-9.11.36-3.el8.x86_64 celt051-0.5.1.3-15.el8.x86_64 centos-backgrounds-80.5-2.el8.noarch centos-indexhtml-8.0-0.el8.noarch centos-logos-80.5-2.el8.x86_64 ...
I can’t even tell what packages are corrupt.
Rebuilding the rpm dB does not solve this.
Going to restore from a snapshot again and start over…
The rpm db from 8 to 9 changes. Errors are changing from Berkeley DB to Sqlite. If rebuilding the rpmdb in-place doesn’t work, then:
cd /var/lib/rpm rm -f __ db. 00* rpm --rebuilddb
it’s important to only remove the particular files that would be deleted by that command, and not what is in the entire directory.
That said, as you’ve found out by having issues with rpmdb, is that this is why upgrades are not supported, and clean install is recommended. There are potential other problems that can be encounted, especially when more and more packages are installed, be it from official repositories or third-party ones.
Not only that, I see you have centos packages installed, which means this is not a pure Rocky system in the first place. I guess you upgraded from CentOS in the past, so will be even more difficult and problematic.
error: rpmdbNextIterator: skipping h# 2208 Header V3 RSA/SHA1 Signature, key ID 158b3811: BAD Header SHA256 digest: OK Header SHA1 digest: OK error: rpmdbNextIterator: skipping h# 4578 Header V3 RSA/SHA1 Signature, key ID bdda8475: BAD Header SHA256 digest: OK Header SHA1 digest: OK
In my case, this message wasn’t telling me the rpm dB was corrupt. Instead, the message is saying the gpg keys on two installed packages are no longer valid.
After a bit of searching, I realized that key ID’s 158b3811 and bdda8475 are the signing keys for the rpmfusion-free and rpmfusion-nonfree el8 repos. Two packages with these keys must not have updated, despite having installed the el9 rpmfusion repo packages and then running a dnf update.
Knowing that, I ran the update again and simply removed all rpmfusion packages before updating to el9. I then reinstalled them after the update was successful.
Yes, you are absolutely right. Centos-backgrounds, centos-indexhtml, and centos-logos seem to be dependencies of several x11 el8 packages still hanging around. Removing those packages, however, results in losing my desktop. I need to look into this further.
This particular virtual machine is my sandbox for building (and breaking) things, so I might just leave it the way it is for now.
The steps below were taken on my system to upgrade to el9, avoiding any package errors, module errors, or any other errors.
Several of these steps are specific to my own system and won’t apply to you or should be generalized… for example you won’t have the same repo files lying around in your yum.repos.d folder, but it would be a good idea to clean them up before upgrading, like I did.
sudo su cd /etc/yum.repos.d rm -f CentOS* _copr* weewx.repo zmrepo* mv -f Rocky-PowerTools.repo.rpmnew Rocky-PowerTools.repo dnf remove -y rpmfusion-free-release rpmfusion-nonfree-release zoneminder-common ffmpeg libbluray zram \ epel-rpm-macros-systemd weewx usbmuxd perl-DBI perl-IO-Socket-SSL perl-DBD-SQLite \ lame-libs libvdpau python3-gevent python3-greenlet python3-ouimeaux python3-pyyaml xorg-x11-drv-nvidia-kmodsrc \ mock-rpmfusion-free mock-rpmfusion-nonfree rpmfusion-free-appstream-data rpmfusion-nonfree-appstream-data dnf module -y disable "*" dnf install -y https://download.rockylinux.org/pub/rocky/9/BaseOS/x86_64/os/Packages/r/rocky-release-9.0-2.1.el9.noarch.rpm \ https://download.rockylinux.org/pub/rocky/9/BaseOS/x86_64/os/Packages/r/rocky-repos-9.0-2.1.el9.noarch.rpm \ https://download.rockylinux.org/pub/rocky/9/BaseOS/x86_64/os/Packages/r/rocky-gpg-keys-9.0-2.1.el9.noarch.rpm dnf -y --releasever=9 --allowerasing --nobest --setopt=deltarpm=false distro-sync restorecon -Rv /var/lib/rpm rpmdb --rebuilddb -v dnf install -y https://mirrors.rpmfusion.org/free/el/rpmfusion-free-release-9.noarch.rpm \ https://mirrors.rpmfusion.org/nonfree/el/rpmfusion-nonfree-release-9.noarch.rpm dnf install -y mock-rpmfusion-free mock-rpmfusion-nonfree dnf update -y
While my system appears to be running normally, there are 51 el8 packages still on my machine. I plan to evaluate each before deciding what to do with them.
Last post I promise…
I went through all 51 leftover el8 packages and, other than the ~6 packages which affected the desktop GUI, removing them had no side affects. I went ahead and removed them all.
To restore the desktop, I simply issued the following then rebooted:
dnf -y group install "Server with GUI"
All el8 packages are gone and the system works normally now.
Sir, Thank you for these steps.
Tempted to try them on a live server.
thank you for these steps!
I am currently trying to figure out why I can’t get dnf to not brick itself every time I try fixing it during the upgrade process, it seems like every time I fix one issue, a new one arises, I managed to get the bulk of the errors fixed, but then I get this error
Error: Transaction test error: file /usr/share/redhat-logos from install of rocky-logos-90.11-1.el9.x86_64 conflicts with file from package rocky-logos-86.2-1.el8.x86_64
I am no longer getting this error, but now I am getting the error of
Error: Transaction test error: file /usr/sbin/service from install of initscripts-service-10.11.4-1.el9.noarch conflicts with file from package initscripts-10.00.17-1.el8.x86_64 file /usr/share/man/man8/service.8.gz from install of initscripts-service-10.11.4-1.el9.noarch conflicts with file from package initscripts-10.00.17-1.el8.x86_64
I had followed some of the advice from this thread and I am stumped.