Upgrading between major versoins was never supported, but on the RHEL site it now says they ARE supported?
An in-place upgrade is the recommended and supported way to upgrade your system to the next major version of RHEL.
There a whole 10 Chapter book about it
RHEL support it because they made a tool for it that they didn’t release for anyone else. However, it doesn’t always allow the upgrades to take place.
That interesting that they made a tool, and they now support it, that’s news to me. Annoying that they didn’t make it available to everyone. Personally, I would avoid their tool anyway.
RHEL has the Leapp utility, which provides a supported upgrade path for RHEL only.
If I recall this tool was introduced with RHEL 7 upgrades.
This. There are many setups that cannot be converted. Not even all “pure” RHEL (that have no third-party content) can be converted.
The ‘leapp’ is actually available for others too, but it does not work without data about distro and that is specific to RHEL. The ELevate tool by AlmaLinux team has leapp and initial data from Oracle.
Personally, I do avoid migrations. I put my efforts in installability. If I can reinstall a system at any time effortlessly, then I have no need for might-work-but-more-likely-doesn’t endeavours.
The main reason I chose a long term distro like Rocky is due to the upgrade hassle.
My backup system BackupPC depends on the uid.gid of the backuppc user being the same across installs because it owns 1000k of files across multiple backup disks. So on new installs I either have to spend days changing file ownership across all those disks or I have to hunt down conflicting system users and their file ownerships and change them to allow the bacuppc user to again have the same uid.gid as before.
So the only reason I might risk an inline upgrade is to avoid this hassle. So I do have a system in place for that eventuality which is to maintain a separate empty partition that I clone the running system to and then I can do trial and error upgrades on the clone while maintaining the current system. If it fails I clone again. I’ve been doing this on my client Fedora machines for ten years with 90% success rate or better.
Nice. I have a variant of that. I don’t allocate all (system) disk to filesystems on install. Have done so for quite a while now. (If user files are mostly on network disk, then there is less pressure to fill the disk.) Therefore, on next install there is free room for filesystems of the new install. The new (and old) setup can even (auto)mount root of the other setup to access the other “/etc”.
Much more recently I learned Ansible. The account data (including uid/gid) can be on Ansible “inventory” and run of playbook will ensure that system has correct local accounts. Furthermore, the inventory is a git repo and a (backup) clone can be in gitlab, etc.
On larger lab accounts are in LDAP, so not at all in a machine (just to ensure that every machine in lab has same uid’s).
Following link will work for you.
https://www.centlinux.com/2022/07/upgrade-your-servers-from-rocky-linux-8-to-9.html
I’ll check out “Ansible”. Other than googling is there any good documentation you recommend?
I started more or less “from scratch” and am still adding/refining tasks in my plays (as I seem to learn by doing).
I did mainly peruse the main documentation: Getting started with Ansible — Ansible Documentation
This blog Ansible 101 - Standards - Ansible Junky seems to have nice tips on style.
The RHEL documentation does have increasing amount of “System Roles” sections too. For example: Chapter 6. Configuring an Ethernet connection Red Hat Enterprise Linux 9 | Red Hat Customer Portal
I totally agree with your statement.
For real customers with production live servers use the native tools to migrate between application servers, etc…
For servers that were setup as a hobby (non-critical data) you can always spin up a new VM in a few minutes from a backup and run the “upgrade” commands just for the fun of it.
I was in a very bike crash and was first in a Level 1 Trama Center for 6 days, then in a rehab unit for 2 weeks instead of 4-6 weeks then not more rehab for another 4-6 weeks. I was apparently in very good shape as my total time spent in the hospital was 20 days. Though I am still in very bad shape. I am just getting around to checking on whats happening on Rocky Linux.
Due to the traumatic Brain Injury I spend far less time on my computer and more time sleeping.
I had just heard that RL 9.0 was OUT. I have been busy trying to get ocelot up and running 8.6, though now it is on a 1TB HDD not an NVMe drive along with openSUSE 15.4 which is on an NVMe drive. Both now co-exist. I thought of trying to install RL 9.0 but from what I have been reading – slowly since I can’t wear glasses which makes my double vision worse – I think I’ll be passing on RL 9.0. It sounds as though it is a GIANT PITA… then there are all the GIANT bugs that come with a XYZ.0 release. Has anyone read any reviews of RHEL 9.0? is Red Hat having the exact same problems you are finding since RL is “bug-for-bug” copy of RHEL 9.0. Maybe they have come out with some work arounds for the problems you are encountering with RL 9.0. I was truly hoping that RL 9.xyz would be a better OS than RL 8.6 (so far). Installing Nvidia is proving to be a pain in 8.6, and that is just one of many problems that I am encountering in RL 8.6. The list goes on.
Have fun gang. I’ll be back — at some point.
D’ Cat
I don’t recall seeing any major “bugs” mentioned for EL9 (RHEL, RL, nor AL).
Security features have clearly been enhanced.
I hope your recovery is smooth.
I’m not aware of any major bugs in el9… just the usual things that RedHat intentionally changes.
Upgrades are doable. Disable modules before upgrading and things go a lot smoother. I am slowly upgrading all my vm’s, but for the moment I will leave my hosts at el8.
I’ve run into NVidia issues on el8 as well. There was a 50/50 chance some nvidia drm module would fail to load on boot. Changing to a mainline 5.9 kernel made the problems go away. Don’t think the nvidia driver works well with the 4.8 kernel in all cases. This was for a Mythtv box, so I was ok with running an unofficial kernel.
Jeeze, I was actually wondering what was going on with you, @desercat , as you were a frequent author here at the forums. Wishing you all the best for a speedy and smooth recovery. Get well soon! We’ll be happy to have you back around - take your time and take care.
Thanks, still being rather new to Rocky Linux this helped me out performing the upgrade from 8.7 to 9
I mistakenly remembered there was an upgrade command and this was quite shocking to be honest. Multiple upgrades went haywire leaving me at 8.7 after reboot.
After manually removing ruby-irb shim-ia32 python39-idna-2.10-3 to then do dnf -y install kernel kernel-core shim resulted in a functional upgrade process.
After successfully upgrading several Rocky 8 instances to 9 on machines with a BIOS, I finally upgraded my first modern EFI machine. In order to avoid booting to a grub prompt, I needed to call grub2-mkconfig prior to rebooting. Here is are the latest steps I took:
sudo su
Remove all packages not found in base or epel repos
dnf remove [third party packages]
dnf module -y disable “*”
these filenames change over time as new packages are published
dnf install -y https://download.rockylinux.org/pub/rocky/9/BaseOS/x86_64/os/Packages/r/rocky-release-9.1-1.11.el9.noarch.rpm \
https://download.rockylinux.org/pub/rocky/9/BaseOS/x86_64/os/Packages/r/rocky-repos-9.1-1.11.el9.noarch.rpm \
https://download.rockylinux.org/pub/rocky/9/BaseOS/x86_64/os/Packages/r/rocky-gpg-keys-9.1-1.11.el9.noarch.rpmThis step may no longer be needed
rpm -e --nodeps rocky-logos
Begin the upgrade
dnf -y --releasever=9 --allowerasing --nobest --setopt=deltarpm=false distro-sync
restorecon -Rv /var/lib/rpm
rpmdb --rebuilddb -vdnf update -y
To configure grub on an EFI machine, make sure and execute this before rebooting
grub2-mkconfig --output=/boot/efi/EFI/rocky/grub.cfg
reboot
sudo su
rpm -qa |grep el8
dnf remove -yrpm -qa | grep el8enable rocky CRB repo
re-enable third party repos then reinstall desired packages
dnf install -y https://mirrors.rpmfusion.org/free/el/rpmfusion-free-release-9.noarch.rpm
dnf install -y https://mirrors.rpmfusion.org/nonfree/el/rpmfusion-nonfree-release-9.noarch.rpm
dnf install [desired packages]The upgrade process removed the desktop, so reinstall it, if needed
dnf group install “GNOME Desktop Environment”
If, after the upgrade, dnf/rpm constantly complains of installed packages with a SHA1 signature, you can fix that with this command:
sudo update-crypto-policies --set DEFAULT:SHA1
Be advised SHA1 was (rightfully) deprecated on el9.
On my RL9 system grub.cfg is here as well as the grubenv file that corresponds to the running kernel
/boot/grub2/grub.cfg
You can confirm by looking in /etc/
$ ls -l /etc/ | grep grub
lrwxrwxrwx. 1 root root 22 Nov 17 23:22 grub2.cfg -> ../boot/grub2/grub.cfg
lrwxrwxrwx 1 root root 22 Nov 17 23:22 grub2-efi.cfg -> ../boot/grub2/grub.cfg
Threre does need to be a grub.cfg file in EFI/Rocky/ but it is just a pointer to the partition that hosts the kernel.
The contents:
###################
search --no-floppy --fs-uuid --set=dev <uuid of either boot or root>
set prefix=($dev)/boot/grub2
export $prefix
configfile $prefix/grub.cfg
###################
Substitute uuid of the partition where your system kernels are
installed to for <uuid of either boot or root> including the <>
That’s interesting.
On my system, the two grub2 symlinks under /etc match what you show, but I’ve got a symlink in /boot/grub.cfg point to /boot/efi/EFI/rocky/grub.cfg:
$ ls -l /boot/grub2/grub.cfg
lrwxrwxrwx 1 root root 26 Nov 19 2020 /boot/grub2/grub.cfg -> ../efi/EFI/centos/grub.cfg
$ ls -l /boot/efi/EFI/rocky/grub.cfg
-rwx------ 1 root root 6558 Dec 29 10:00 /boot/efi/EFI/rocky/grub.cfg
Could this be a new feature of el9?
I just checked three other el8 machines with EFI, and the grub2,cfg file lives under /boot/efi/EFI/rocky/ with symlinkgs under /etc pointing to it.
As you see in 8.x is the way it was. What you have will work. Most of my experience is with Fedora where this change was made about 3 versions ago. I just converted my bios boot rl9 to efi boot last week and this is how it is on my system. It would be good to know what a fresh 9.1 install on UEFI hardware looks like.