CentOS Linux 7 will reach EOL on Sunday

Directly relevant:

https://techstrongitsm.com/itsm-news/suse-offers-lifeline-to...

    All they need to do, SUSE’s GM of the Business Critical Linux
    team, Rick Spencer, said, is simply change their CentOS 7
    update repository to SUSE’s, avoiding any disruptive migrations
    or upgrades.

HN article about it: https://news.ycombinator.com/item?id=40732016

Transitioning from CentOS 7 to RedHat 8 and 9 at my former company's private cloud has smooth for most teams, pareto-style, with 80% of migration-related incidents caused by the 20% of the teams that did some really weird changes to the VM's OS that was no longer allowed under RHEL 8 or 9.

At first, I thought it was just to reduce the complexity of managing hardening rules for several OS and OS versions.

Just a heads up, since I couldn't comment on the LWP article about this a few days ago.

The leapp-upgrade program had a reproducible bug as late as last week where after every upgrade it inserted net.ifnames=0 into the kernel cmdline. So when the new RHEL 8 system booted up it was using the wrong interface names (eth).

The fix was simply grubby --remove-args="net.ifnames=0" --update-kernel ALL but felt stupid since RH emphasize the interface name change and then they themselves sabotage it for us.

I used ELevate for a few VMs at home and it worked pretty well. I upgraded from Centos 7 to Alma 9 one release at a time

https://almalinux.org/elevate/

This has been a huge shitshow for us. Migration has been such a pain for our VPS boxes, so that we just spooled up new instances on AlmaLinux and migrated data by hand. It was a long week.

What a mess. Centos Stream 8 seemed to work at first but then after upgrade to 9 secure boot didn't work at all, I couldn't even boot the 9 install media.

I stopped trusting CentOS dates and assumed CentOS 7 was EOL a long time ago because their yum repos were down, or they didn't provide certain updates anymore, or something. I noticed inconsistencies across machines I tried to update simultaneously, noticed there wasn't a common update point available (the machines were on slightly different versions to begin with), and decided it was junk and time to move on.

Companies like CIQ, OpenLogic, and TuxCare offer extended support for CentOS 7, and Red Hat offers services for RHEL7.

https://linux.slashdot.org/story/24/05/10/2256230/red-hat-an...

We experienced a migration from CentOS7 to Rocky 8. Rocky 8 running on VirtulBox produces different results on some numerical tools compared with Docker container. CentOS 7 did not use to have that problem. Same program and floating point differences. Other than that Rocky 8 ran all right.

I chose Centos Stream 8 over Centos 8 because I figured that the stream version's rolling updates would result in a later EOL. When Red Hat announced the unexpectedly short EOL for 8 I was glad for my choice. That said, what has Red Hat said about an EOL for Stream, if any?

There are so many alternatives to CentOS and RHEL that their absence is inconsequential.

I'm always amazed and envious at how many successes people have had with the conversions.

This has been a huge problem for me and I only have just about 75 boxes. Only about 15 or so have been converted successfully to RHEL 7.9 since March, none (successfully) to 8.x after that.

1. Convert2rhel has been a nightmare, only a few have worked properly the first time. I've had 8 tickets opened with Redhat. Once I get one working, the next one will fail with different problems.

2. LEAPP from 7.9 to 8.9 hasn't worked successfully yet. When it does it breaks absolutely everything from PHP to mail sending to databases.

3. I thought Alma might solve the problem, nope. Similar issues as point number 2. Or I get Python errors, or any variety of anything else.

I'm not sure what our path is going to be (maybe Tuxcare or Suse or something), but I'm concerned about my job now since I was in charge of this and it's been a disaster. The anxiety is high.

Unrelated, but any major OS version change these days feels contrived and unnecessary. What is changing so drastically that we need a major version bump and hours of upgrading?

IMO, the versioning should follow a pattern of 2024.01, 2025.03, etc.. and updates should be seamless.