Where did you get all these instructions from? it should work to simply do dnf update and the resulting update should bring you up to the current Rocky Linux 8.10.
First, Rocky 8 and Rocky 9 are two distinct distros, just like Rocky 8 and Debian are two distinct distros (although Rocky 9 is less dissimilar than Debian).
Rocky 8.7 was Rocky 8 until Rocky 8.8 was released. One was supposed to run dnf up when Rocky 8.8 was released.
Rocky 8.8 was Rocky 8 until Rocky 8.9 was released. …
Rocky 8.9 was Rocky 8 until Rocky 8.10 was released. …
There will be no Rocky 8.11; from now on Rocky 8 will be based on RHEL 8.10 content to 2029.
Rocky does not support past updates. If Azure does not support current Rocky 8, then that is an issue, not the “how to install unsupported packages”.
Sometimes I wish RedHat would support version updates. I understand why they don’t, but it does mean a lot of work every 8 years or so… I’m now in the middle of replacing my CentOS7 instances with Rocky 9. It’s hard work. But that’ll keep me going for another 8 years
Elevate (offered by Alma Linux) can do upgrades between major versions and does support Rocky Linux as a target. There is a non-zero chance that things will go horribly wrong, though and such installations may not be supported by Rocky Linux.
The official position of Rocky Linux is that major version upgrades are not supported and you should do a clean install of the new version.
I’ve tested elevate before on a clean C7 install, doing an C8 upgrade. It… mostly worked. Enough to let me clean up and successfully run the migrate2rocky process
Red Hat does have a tool (leapp). They have a list of setups where it will certainly fail. The Elevate does use the leapp too. (Elevate has non-RHEL data to allow use on non-RHEL distros.)
I prefer to think such operation as in-place conversion to different distro, rather than “upgrade” or “migration”. That, IMHO, makes it more clear what one does attempt.
Yes, there is work. Since I started using configuration management system (Ansible), the install, config, and maintenance got much easier. The transfer of user data is naturally its own hurdle. I have the luxury of network storage that systems mount the “user volumes” from.
You don’t need network storage to do that. You can put your user data on a separate partition and then just mount that partition into the new install without formatting it.
Depending on what you are running I would not recommend to a migration from a lower version to a higher version as the rabbit holes that you may run into can be hours and hours to resolve and still end up starting over. However what I do is backup all the important config files and production files. Build clean them restore them to their default directories and configure my server apps anew.
True. The default partitioning on install does that – creates separate /home.
The luxury in my case is that the machines have no data; they can be wiped clean without a thought. Drop in config for autofs.service after install and I’m good to go.
Backup is always recommended. However, a mere copy of config is less useful than something that can be “deployed”. The thing is that on every new distro things do change here and there. That is why automated “upgrade” is so difficult.
There are now configuration management systems. Those allow an layer of abstraction. One of them, Ansible, Rocky has in package ansible-core, and some recipes for it are in package rhel-system-roles. You can have description for Ansible: “hosts X and Y allow https traffic”. Ansible has enough logic how to actually do that on CentOS 7, Rocky 8, Rocky 9, and many other systems. And that description is text (YAML) – easy to backup.
Yes, one might have to adjust the descriptions for a new distro, but once done you can install, configure, and manage a lot of systems.
Great advice! I use BackupPC and it deploys famously once setup on new server. It also allows me to make mistakes and recover almost instantly. I was wondering if Docker might be useful for this sort of thing too.
While in the Rocky world, consider replacing the word ‘docker’ with the word ‘podman’.
Having a backup of a container might help, but not much use if yo’ve got no o/s, or if it’s on the partition of a drive that’s just died, so better to have all backup on seperate storage, e.g. network storage.
