I have successfully upgraded to Rocky Linux 9;
see : 百度翻译-200种语言互译、沟通全世界！
original: Rocky Linux 8无缝升级Rocky Linux 9（RedHat系列均可）-RedHat-BUG汇总 - 找BUG就上BUG汇总
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
adding --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]
Thanks
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.
Fixed.
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.
Boom. Fixed.
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.
4 Likes
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.
4 Likes
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.
Hi @knight-of-ni,
First of all thank you for sharing those steps.
When running step
dnf -y --releasever=9 --allowerasing --nobest --setopt=deltarpm=false distro-sync
I am getting following conflict regarding systemd, how did you overcome it?
Running transaction check
Transaction check succeeded.
Running transaction test
The downloaded packages were saved in cache until the next successful transaction.
You can remove cached packages by executing 'dnf clean packages'.
Error: Transaction test error:
file /usr/lib/systemd/systemd-network-generator from install of systemd-250-6.el9_0.x86_64 conflicts with file from package systemd-networkd-250.3-1.el8.x86_64
Did anyone come across similar error scenario? Thanks.
I think it’s saying that one of them is “el8” and the other is “el9”.
Yes, thanks for the tip.
It appears that systemd-networkd is not part of baseOS.
Just needed to install EPEL Repo 9 prior to the dnf command.
sudo dnf install \
https://dl.fedoraproject.org/pub/epel/epel-release-latest-9.noarch.rpm \
https://dl.fedoraproject.org/pub/epel/epel-next-release-latest-9.noarch.rpm
I just ran into this too.
Issue rpm -e --nodeps rocky-logos then start the upgrade again and it should work.
I would like to once again point out once again that upgrades between major versions of Rocky Linux and the systems that result from such upgrades are not supported. Any such upgrade that you attempt is entirely at your own risk and is likely to have many many hurdles that you will need to overcome. This is not something I would recommend for any kind of production servers or any machine that has to reliably maintain any kind of uptime.
You break it you keep the pieces.