I have to move on from centOS and I’d consider Alma as my best shot. I had lots of issues in trying (and failing) major upgrades from centOS 7 to 8. So I wanted to make sure that in the goals of Alma it is comprised to offer a simple clean and fully working path for Major upgrades. Is it going to be like centOS?
The CentOS has never supported any in-place conversion from one distro to another (e.g. 6 → 7).
Red Hat has tool ‘leapp’ that can convert some RHEL systems (but not all).
AlmaLinux has separate project “ELevate” that uses leapp. Again, it can convert some, but not all, systems.
Personally, I rather do clean install, deploy config, and restore user data.
That requires two things:
- Have restorable user data
- Be able to create appropriate config for each major version
If you don’t know what config is appropriate, then you don’t know your system.
“Know thyself and know thine enemy, and you can …”
If you have no means to restore user data, then it cannot be very valuable?
As the previous poster said, CentOS didn’t have a clean upgrade path. However, we have worked with the greater RHEL community to put together Project ELevate, which allows you to upgrade in place and migrate between distros. Definitely worth checking out! It’s been stable for almost a year and we just added support for 8-> 9 upgrades.
Ironically I logged on my Ubuntu 20.04.4 LTS (picked that because it is a Raspeberry Pi) and it greeted me with
New release '22.04.2 LTS' available.
Run 'do-release-upgrade' to upgrade to it.
Can anyone explain if there is a major difference between how Debian and RHEL handle updates that can motivate RHEL and centOS not supporting major version upgrade (until leap or ELevate) while Ubuntu actually insists for me to upgrade?
Sadly centOS 7 got broken by the attempt to upgrade using dnf. So, at least for now, I cannot try ELevate. Thanks for pointing it out! it is enouraging to see that the need of major upgrade is considered. I hope it will become more common practice than doing fresh reinstalls.
This way of proceeding is more time consuming than doing an in-place system upgrade. An in-place upgrades gives me with a system already fully configured and no need to waste time on reconfiguring the system.
Except not being possible on centOS, why anyone should prefer to do system reinstall when it is possible to do an in-place upgrade?
That assumes that some automation can read all current configuration and correctly translate it to whatever the new distro requires.
What if you have hand-made customizations or third-party packages? How does a “migration script” handle that?
Note that RHEL 7 was released in 2014 and RHEL 8 in 2019. A lot of core system components were replaced between those two distros.
The Ubuntu 20.04 was released in 2020 and the 22.04 in 2022; way less changes and a game plan to progress incrementally.
Lets assume that your system goes up in flames. Then you have to get a new – no in-place option at all.
Do you have something for that? I do, and it is trivial.
Should I prefer such trivial install or in-place routine?
Do you use virtual servers? Something that is spawned once in a blue moon and is discarded after short, furious use? You want reproducible platform for the job, not something that has accumulated who-knows-what.
You sound pretty narrow minded, maybe you are not. But please consider that out there there are lots of use cases.
Doing in-place upgrades does not discount anyone from properly backup routines. That is not the point. The point is that a distribution that does not allow for in-place upgrades has a limitation by design. Maybe it is a design that gives you something, I am asking what is this “something”.
The only valid point that I see you raised is that you have a reproducible environment, but that does not really apply, imho. If you create virtual machines with a well defined point release, e.g. Ubuntu 20.4.2 LTS it seems to me that you got a pretty well defined environment, and if you have issues in that environment everyone can reproduce it as well as if you are using a given RHEL version. What am I missing?
PS
Please do not quote Sun Tsu’s “the art of war” because managing machines is not a war.
Yes, I probably have my bias.
That question is for Red Hat, because they design RHEL.
Sure RedHat can give the best answer to that. But I guess users who choose to use a RHEL derivative must have an opinion on this.
Personally I am sort of forced to use a RHEL based distribution because of some scientific software that is guaranteed to compile or install from repository on RHEL and may turn into a hell of compilation on other systems (or a waste of time to create the correct environment to compile).
For other use cases, e.g. something like a desktop I am using Debian derivatives and so far they have not failed me in major version upgrades.
I have my opinion and the very existence of the project ELevate does show that there are people with opinion that in-place conversion is a useful option.
That is one point too. All applications are not conveniently packaged for all platforms.
If one is not available for your platform, then you have “source install” – or worse yet a proprietary binary blob. If the API/ABI of your platform do change, then a painful reinstall
can become necessary, since the dnf up or apt-get upgrade is not an option.
Some core RHEL libs supposedly have guarantee that their API&ABI of two previous major versions is available too (usually as “compat-*” packages). How stable are the API&ABI in the Debian family?