Rhel8.6 has been released do we have an eta for rocky 8.6?

rhel8.6 has been released, is there an eta for rocky 8.6 ?


I’m guessing pretty soon, if you go by this post:

that does talk about updates, I assume that it will be similar for a full release, or maybe a little longer.

Just wanted to thank everyone at the Rocky Linux team for creating and maintaining and supporting and updating Rockly Linux so well :slight_smile:

1 Like

We generally don’t give an ETA for minor version releases. I generally strive to have them within a week to the community. We’ve ran into a few snags while building out 8.6. However, as I type this message, we are producing 8.6 images to hand off to the testing team to evaluate and report back issues. In particular, with the likes new modules such as log4j and new streams of php (8.0) and perl (5.32).

If I had to guess, we may have a release sometime this weekend or starting next week as we also continue to work on Rocky 9.


It is done when it is done. I’ve never felt (with CentOS) that I didn’t get what I paid for even if I have to wait a bit. Rocky has the same price as CentOS …

ELRepo has already some ‘el8_6’ packages. That is good. It would be embarrassing to update kernel and boot without critical devices. (Been there, done that. :flushed: )

ELRepo has already some ‘el8_6’ packages.

This also means you should not try to update ELRepo packages till the time you update to Rocky 8.6.

OK is this going to be like CentOS and be a simple Rollover? If so I’d better start thinking of Backingup my WS NOW!! (This should be "Interesting" as Rocky sits on an NVMe Gen 4 drive).

To be fair, that’s the same as RHEL, RHEL will automatically go from 8.5 to 8.6 on a “dnf update” in most cases, the only time it won’t is if you have run:

subscription-manager release --set=8.5

Also, there won’t be a 8.5 EUS so far as I’m aware, since 8.4 was the previous EUS, so 8.6 is the current/next EUS, so even with RHEL, it’ll be recommended to go from 8.5/8.4 to 8.6.

So basically, any RHEL clone will automatically rollover into the next release, it’s completely normal.

With that said, so far all upgrades from 8.4/8.5 to 8.6 have been successful without any problems for me[1].

[1] I use both official RHEL and RockyLinux.

PS: You should have backups in any case, just because it’s an enterprise level distro and on an NVMe, doesn’t make it immune from disasters and I have seen NVMe’s fail :stuck_out_tongue:

Always keep a working, checked and tested backup at all times…

Amen Brother! You are preaching to the choir – I usually make two full disk backups: one right after a new release comes out and has more or less stabilized; and one right before before a NEW release comes out, just in case the NEW release goes South. That has pulled my butt out of the fire twice, when I ran a rollover that took issue with something that it did not like. I wiped the entire drive out and then restored it from by backup. In this case I have RL 8.5 on a 4th Gen NVMe drive, which has given me a bunch of hissy fits, but I think I have solved the problem. I have already made a backup just in case the problem reoccurs again, but so far NOT (fingers crossed – I have ZERO idea which solved the problem). Guess I’ll find out for sure when I do the rollover…

Naturally. Although, that is more about user data and config – the system files should be trivial to reinstall.

By definition of Enterprise Linux, the point updates do not introduce drastic changes and hence dnf up should be quite safe. The “migrate from CentOS Linux 8 to another clone” script was more “exciting”, but since I have means to trivially (re)install from scratch it was not so scary.

@desercat Fair enough, I misunderstood your meaning about your backups, glad to hear you keep routine backups :slight_smile:

@jlehtone To be fair, it read to me as though s/he had no backups at all with the only backup being that one prior to upgrade. I agree entirely with your backup method, but my point was that s/he should always have backups (not just for upgrades) as I thought he wasn’t keeping daily/hourly/etc user data backups, naturally we’ve since seen s/he does. :slight_smile:

I agree entirely that most upgrades will go without problems. Although, even on systems which do introduce drastic changes for example Tumbleweed (rolling release) which I use for my workstation can mostly also upgrade without problems so long as you keep an eye on recent changes and/or read release notes and make adjustments as necessary.

But I’ve got big plans for new RHEL 9 / Rocky 9 setups, but with 8.6 remaining on the current “underlying” libvirt host servers - so I’m just reading everything about the recent changes to prep for upcoming changes and plans. Hyped over here :smiley:

PS: Yes, I totally see the irony of only using RHEL+Clones for our servers and SUSE for my own desktop/workstation - in my defence I used Fedora for 15+ years previously on my workstation, but fancied a change and it stuck :stuck_out_tongue: :joy:

In addition to my FULL DISK backups I use BackupNinja for weekly backups of key partitions.

As to RHEL (or is that OUR HELL?) 9 / Rocky 9… I have no intention of loading 9.0, or 9.1 XYZ.0 is filled with so many BUGS if industrial strength RAID does not exterminate them all, and XYZ .1 is only slightly better. With LUCK by the time 9.2 or 9.3 rolls around 8.x will have stabilized enough to actually be useful.

Like you my buddy and I are considering switching to openSUSE 15.3 Leap for our day-to-day WS. Me?? I feel more comfortable with Red Hat as I understand the way it works – I better after 20+ years. openSUSE is simply WEIRD. That said I have it up and running. Right now either SUSE or RL will become our primary OS, and the other will be our secondary OS.

As to Fedora… I’ve feel I’ve been to the the Blood Bank, but that’s the price for living on the Bleeding Edge.

D’ Cat

This is all going off topic now… but you’ve got me talking about servers… I can’t hold back :stuck_out_tongue:

Depends on your use case to be fair, I say the same about which distro to use (with the exception being new distros that were invented “last night” with “some new unknown guy” that simply change the theme - they will never hit my systems)

For example, on the bare metal - I will be absolutely leaving 8.6 in place. 9 will only come into play on bare metal after 9.2+ and only as new servers come into play. Although, hardware RAID generally doesn’t fix software bugs, unless those bugs happen to be in md itself - so software raid or hardware raid - buggy software will mostly still be there.

In my experience, I’ll go with hardware raid on data-critical systems where that battery comes in handy (something software raid can never supply). Hardware raid doesn’t always mean a faster array rebuild these days either, heck sometimes it could be slower, unlike the old days!

(I’m talking about hardware raid with battery, not the default BIOS raid… which is often simply a glorified software raid).

In any case, I always say use the distro that’s most suitable for the job, not the distro with the prettiest name.

For example, one system of ours runs debian - why? Because of the software it runs - despite being provided as a docker container - is only “officially” supported on debian. Could you get EL to run it? Almost certainly. But then you’ll get the loathsome “disable SELinux” advice or “sorry, we don’t support that platform” response.

So, if you stick it on the “distro we recommend” - they’re happy when it comes to bug reports etc and can’t blame SELinux and/or EL for the problem. Though, you’ll find the same thing with software that’ll say only supported for RHEL “and not clones”.

On the other hand, another system runs RHEL 8.6 and acts more like a fileserver for our other servers to backup to using SSH and GPG encrypted archives. Those servers have a login with a passwordless keyfile - each to their own user account, with their own key on the file server. That user account is restricted to being unable to run binary files, unable to use su or sudo, and confined to the SELinux “guest” user (system policy also being set to MLS). The SSH also only being open to systems within our internal VPN (rocky server :smiley:). I wouldn’t trust this system at all if it was debian based without SELinux in place…

I really, really, hate when someone proposes disabling SELinux as a “solution”. SELinux is relatively easy once you understand it, and if you install SETroubleshoot, it’ll even tell you how to fix it in most cases, could be as simple as toggle a bool. It’s been around long enough now… it makes me laugh when someone says “Disable SELinux, it’s a PITA!” followed by “Linux is insecure!” :joy:

RHEL 9 / Rocky 9 will come into play for web servers that run on top of RHEL 8 hosts - I already know what to expect with this since our development/testing servers run CentOS Stream 9 already on those hosts (as libvirt guests).

For a web server, more recent versions of PHP / MariaDB etc are more desirable. Sure, RHEL 8 has software collections & remi repo. But there’s other new things in RHEL 9 also (Like support for ed25519_sk SSH keys, I really wish RH would backport this already).

So generally, I always use and recommend the distro best suited for the job at hand.

With that said, even on RHEL 8.5, one of my servers was throwing a kernel error every night due to the hardware being a little bit too new for the old kernel - thankfully the kernel in 8.6 has stopped those nightly errors.

I haven’t tried/used SUSE Leap personally, but it seems stable? Although I did read recently there is a push to change it into MicroOS (their version of Silverblue, immutable filesystems…) with the current Leap format coming to an end in favour of it.

For my own system, I use Tumbleweed (not immutable, software comes from distro itself) simply because out of all the rolling distros, I found it to be the most stable. It provides me with the latest software and uses btrfs with snapshots enabled by default - so you can simply rollback to pre-update should something break. That’s super handy for a system that needs to be used for development, administration (servers), accounting, gaming (sorry!) and pretty much anything else I need/want to do.

Of course, I wouldn’t put it on a server however :stuck_out_tongue:

Anyhow… this post became longer than I intended… sorry!

1 Like