Hi all,
I’ve been spammed by redhat now for some time about the rhel9 beta.
Yesterday the first beta rhel9 ubi cloud container images were released (7Mb compressed…impressive)
Also centos9stream has been available for some time now.
Is there any work or preparation being done for Rocky 9 yet ?
Would be cool if Rocky 9 would be released really soon after RHEL9 goes gold.
Rob Verduijn
A note before answering your question: The current RHEL 9 beta is not a 9.0 beta, it’s a 9.-1, basically, and won’t be what will be GA in 6 months time. We have no plans of building that beta in particular. We will build a 9.0 beta when that’s ready.
To answer your question though, we are not building 9 stuff just yet. We are currently finishing up some pieces of our new build system to present to the community for general use, SIG work, and open development. That new build system will be used to build Rocky 9. We may be ambitious (and maybe a bit idealistic) that we can build out Rocky 9 and have our own release within days of upstream release, but we want to try to see if we can. (We are volunteers after all, and we have 6 months of time before 9.0 releases)
Either way, we want to do this with quality in mind. And that’s why we want the build system ready to go first and available to the public before anything else. We hope to have information in the coming days!
Related to this topic. Will it be possible to do an in place upgrade from Rocky 8 to Rocky 9 when it comes out.
While there will be folks who will come up with the steps to do so (like they did between CentOS 7 and 8), we generally don’t support in place upgrades. It is likely that the ELEvate tool from alma will support 8 to 9 upgrades though.
There has been some interest in a leapp SIG that would be part of either extending that tool or building their own pieces around the leapp framework. (Though I admit I haven’t heard much movement around it for many months.)
Isn’t it leapp that the ELevate does use?
CentOS has never officially supported in-place upgrades (aka 'migration") between major versions. Red Hat has had leapp for RHEL, but they have always had a long list of cases that definitely will fail.
@BillT
Regardless whether on considers in-place upgrade, one must always have a recovery plan should something go wrong (hardware breakage, intrusion, human error). Both a backup of data and a procedure to restore system into functional state. That procedure could start with “fresh install”.
If the existing recovery procedure is {fresh install, (re)deploy config, restore user data}, then how much work is to create alternative deploy config that is appropriate for new major version?
The 9 might differ less from 8 than, for example, the 7 did differ from 6, but isn’t it important for admin to know what is in the box and how it should be used, rather than rely that the black box handed by some migration tool is ok?