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).
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.
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.