How to: inplace upgrade from Centos 7 to Almalinux 8.5

Active8

Verified User
Joined
Jul 13, 2013
Messages
1,774
Just converted (in place upgrade) an DA Centos 7 box to Almalinux 8.5

As promised short tutorial that I made, many thanks and credits to @dmtinc to his support, good to mention that I did not had any network problems :)
It took almost 1,5 hour on an VPS 6 vCPU and 16 gb of ram so do your math :)

1. No guarantees
2. Make an backup or snapshot of your server !

Code:
mv /usr/sbin/chkconfig /usr/sbin/chkconfig.orig
touch /usr/sbin/chkconfig
chmod +x /usr/sbin/chkconfig
yum remove da_exim -y

After remove the package: (this remove exim from the system too but after upgrade with ./build all exim will be back)

Code:
rm -f /usr/sbin/chkconfig
mv /usr/sbin/chkconfig.orig /usr/sbin/chkconfig
sudo yum update -y
sudo reboot

Code:
sudo yum install -y http://repo.almalinux.org/elevate/elevate-release-latest-el7.noarch.rpm
sudo yum install -y leapp-upgrade leapp-data-almalinux
sudo leapp preupgrade

Check any errors in :/var/log/leapp/leapp-report.txt
In the text file there are also hints how to fix, I had two erros, device driver loaded into kernel and old kernels
This was my solution to my error (check your own error !)
modprobe floppy -r
yum -y remove kernel-devel-3.10.0-1160.45.1.el7 kernel-devel-3.10.0-1160.31.1.el7 kernel-devel-3.10.0-1160.36.2.el7 kernel-devel-3.10.0-1160.42.2.el7

Code:
sudo rmmod pata_acpi
echo PermitRootLogin yes | sudo tee -a /etc/ssh/sshd_config
sudo leapp answer --section remove_pam_pkcs11_module_check.confirm=True

Start an upgrade. You'll be offered to reboot the system after this process is completed.

Code:
sudo leapp upgrade
sudo reboot

A new entry in GRUB called ELevate-Upgrade-Initramfs will appear. The system will be automatically booted into it.
See how the update process goes in the console. << you must have console access to follow the process !!
Dont intterrupt the process, can take some time
After reboot, login to the system and check how the migration went. Verify that the current OS is the one you need.

To be sure that everything is updated to the latest version:
Code:
dnf update -y
sudo reboot

Code:
cat /etc/redhat-release
cat /etc/os-release
cat /etc/redhat-release
AlmaLinux release 8.5 (Arctic Sphynx)

Now reinstall / build DA

Code:
dnf install wget gcc gcc-c++ flex bison make bind bind-libs bind-utils openssl openssl-devel perl quota libaio \
libcom_err-devel libcurl-devel gd zlib-devel zip unzip libcap-devel cronie bzip2 cyrus-sasl-devel perl-ExtUtils-Embed \
autoconf automake libtool which patch mailx bzip2-devel lsof glibc-headers kernel-devel expat-devel \
psmisc net-tools systemd-devel libdb-devel perl-DBI perl-libwww-perl xfsprogs rsyslog logrotate crontabs file kernel-headers hostname

rm -rf /usr/local/uw-imap

Override the OS in directadmin.conf (only if you don't want to change it at license level) and redownload directadmin:
Code:
wget https://raw.githubusercontent.com/poralix/directadmin-utils/master/core/updateda.sh
chmod +x updateda.sh
./updateda.sh save_os --os=c10
./updateda.sh stable --os=c10

Code:
dnf config-manager --set-enabled powertools

Code:
cd /usr/local/directadmin/custombuild/
./build update
./build update_script
./build clean
./build clean_old_webapps
./build all

Now reboot your server and check your logs for any errors
 
Last edited:
Just wondering if a full reinstall with backup restore wouldn't be faster and less error prone?

Kudos for the effort tho!
 
I am getting an error with apache. When i delete the 3th line, it comes back after restarting the build command.

Can't open configure: No such file or directory.
/usr/local/directadmin/custombuild/configure/ap2/configure.apache: line 3: ./configure: No such file or directory

*** There was an error while trying to configure Apache 2. Check the configure/ap2/configure.apache file
#!/bin/sh
"./configure" \
"--enable-systemd" \
"--prefix=/etc/httpd" \
"--exec-prefix=/etc/httpd" \
 
Last edited:
I had more errors so i solved by removing cpan.
Ok thank you for sharing your experiences with the migration, I hope this will help others for an smooth upgrade
Please share any commands that you have executed for the benefit of others, after all this is an how to :)
 
@Active8 good work. I hope someday the RH flavors will fully support in place upgrades. Maybe Alma and or Rocky is moving towards that?
 
I hope someday the RH flavors will fully support in place upgrades.
I wondered about that too recently. But I got answered that this is already possible (unsupported) since Centos 7. Just a little more devious than with Debian.
So I presume Alma (and other RH deratives) will follow that.
 
Last edited:
But I got answered that this is already possible since Centos 7.
Are you saying the old centOS team said you could in place upgrade to vesion 8? I only ever heard it was only supported on Full Red Hat versions. The centos team always said it wasnt supported it one of the reasons I left them.
 
The centos team always said it wasnt supported it one of the reasons I left them.
Correct. It's not officially supported by Centos team. However, neither is the upgrade from Centos 8 to Alma Linux 8 or Centos 7 to Alma 8.
I had to be more clear so I edited my post and added the "unsupported" part.
However I have good hopes that it will be supported.

We mostly don't use our servers longer than 4 or 5 years tops (until now it was max. 4 years), so we don't really need inplace upgrade, we just install a new version when installing a new server.
 
Alma Linux 8
I see ok we agree then.

I wont consider any RH flavor until I can safetly upgrade from one major version to another. I also think Alma or Rocky isnt old enough. I am sure they work. I also would prefer to use Rocky Linux anyway based on it being closer to non commercial.
 
based on it being closer to non commercial.
Which make me choose for Alma. Because with non commercial the risk is greater they stop sooner with development or make sudden changes. So it's a flip of a coin.
Agree that Alma and Rocky are not old enough, but just in those cases, commercial support can just guarantee that some certain issues might be fixed faster on requests, because they need to support it.

So they both have their benefits. But we have to wait and see anyway how the dice are rolling. Until now I'm very happy with Alma. And I just love yum with easy config options above apt which laks them imho.
 
guarantee that some certain issues might be fixed faster on requests
When is the last time you actually requested RedHat or CentOS to really fix an issue?

Also if the OS was going to be unsupported. How long would it take you to migrate away to another flavor. A few hours maybe? If the full life expectancy was really 10 years maybe a benefit. You just said you get a new server every 4.
yum with easy config options
Like what you mentioned this before? I cant say I used a lot of options other than repo priority

Keep in mind we are just talking I used CentOS for years.
 
When is the last time you actually requested RedHat or CentOS to really fix an issue?
Well maybe "requested" was the wrong word. Lets say if some issue arises from some panel. You know what I mean, in a commercial setup certain issues will get faster because otherwise it costs money.

A few hours maybe?
On a VPS maybe, I don't know. In our case, setting up a new server, finetuning it and then migrating all accounts takes a bit more then a few hours.
It takes work and you have to be careful anyway, so exactly not an argument to choose or choose not for something.

If the full life expectancy was really 10 years maybe a benefit. You just said you get a new server every 4.
If you want to use that as an argument, there is also no reason to choose for Debian. Or do you run your same server for 10 years?

I cant say I used a lot of options other than repo priority
I know you used Centos for years. I don't know what you mean by what I mentioned before. But it's not only used for repo priority. DA also uses it to exclude certain packages from being installed via yum. I can also easily change this myself, so due to a slight change I made, it still won't install an ftp daemon, but I can install and keep an ftp client updated.
Next to that, suddenly it seemed kernels getting bigger, it was very easy in yum config to reduce them from 5 to 3.
And I don't have to worry if I type yum upgrade instead of yum update (compare apt-upgrade instead of apt-update) that my system gets an OS update.
Last year I had to remove something, and it took a couple of commands in apt. In yum I only need 1.

I haven't worked a lot with Debian yet, but these things bother me a lot when I was busy with some servers for somebody else. Those servers are still running, but I don't like

However, it's also one of the reasons that I want to try to put up a server at home with DA and Debian, to have a chance to do more with DA and Debian.
 
from some panel.
ok agreed. Not sure who is faster on that but I would think RH types win.
setting up a new server,
Ah mine is all automated.
there is also no reason to choose for Debian
No correct it is my point. Debian, Redhat, whohat, somebuntu.. doesnt matter who long the EOL support is. Unless you are keeping the hardware 10 plus years. I switched my providers twice last year alone..
yum upgrade
true I guess i dont worry to much about typing because. I scripted the process so its the same every time.

server at home with DA and Debian
Cool

Dont get me wrong there are things I dislike about both Debian and RH types. The best one well is unsupported now:)
 
Ah mine is all automated.
Yeah well if you can do that, that's fine, but I'm no scripter so I wouldn't know how. I do use a lot of rsync to move over configs and scripts from the other servers.
Same for updating, I do OS updates manually because I want to see what's going on. Not everyone can do that. But in november I updated a new kernel on 3 servers and 1 server did not came back up. So something went wrong. If I would have scripted it (if I could script), then I wouldn't have noticed this until customers were going to call me in the early morning.
And I'm night people so I sleep during the morning. :)

Benefit is that I can update everything at night and no customers notice anything from that. Anyway, this way I was able to contact the datacenter and have them take a look. They found it would not boot into the new kernel and booted it into the previous kernel.
And there we go. I use yum reinstall everything from the old kernel, removed the new kernel and then configured that for the time being on that server all kernel* stuff would not be updated. Which I removed again when the newest new kernel arrived.
I wonder if that's also that easy to do with apt.

Dont get me wrong there are things I dislike about both Debian and RH types. The best one well is unsupported now :)
Same here, everything has pro's and cons. If Freebsd is best? I don't know, I wanted to try at the homeserver which I want to install, but then they they post the message of end of support.
 
Hi,

I'm trying to update but got this message ;
Code:
============================================================
                           ERRORS                          
============================================================

2022-02-05 21:50:38.652970 [ERROR] Actor: source_boot_loader_scanner
Message: Failed to call `grubby` to list available boot entries.
Summary:
    Details: Command ['grubby', '--info', 'ALL'] failed with exit code 1.
    Stderr: Process Process-201:
            Traceback (most recent call last):
              File "/usr/lib64/python2.7/multiprocessing/process.py", line 258, in _bootstrap
                self.run()
              File "/usr/lib64/python2.7/multiprocessing/process.py", line 114, in run
                self._target(*self._args, **self._kwargs)
              File "/usr/lib/python2.7/site-packages/leapp/repository/actor_definition.py", line 72, in _do_run
                actor_instance.run(*args, **kwargs)
              File "/usr/lib/python2.7/site-packages/leapp/actors/__init__.py", line 335, in run
                self.process(*args)
              File "/usr/share/leapp-repository/repositories/system_upgrade/el7toel8/actors/sourcebootloaderscanner/actor.py", line 18, in process
                scan_source_boot_loader_configuration()
              File "/usr/share/leapp-repository/repositories/system_upgrade/el7toel8/actors/sourcebootloaderscanner/libraries/sourcebootloaderscanner.py", line 54, in scan_source_boot_loader_configuration
                entries=scan_boot_entries()
              File "/usr/share/leapp-repository/repositories/system_upgrade/el7toel8/actors/sourcebootloaderscanner/libraries/sourcebootloaderscanner.py", line 17, in scan_boot_entries
                grubby_output = run(CMD_GRUBBY_INFO_ALL, split=True)
              File "/usr/lib/python2.7/site-packages/leapp/libraries/stdlib/__init__.py", line 181, in run
                stdin=stdin, env=env, encoding=encoding)
              File "/usr/lib/python2.7/site-packages/leapp/libraries/stdlib/call.py", line 217, in _call
                os.execvpe(command[0], command, env=environ)
              File "/usr/lib64/python2.7/os.py", line 353, in execvpe
                _execvpe(file, args, env)
              File "/usr/lib64/python2.7/os.py", line 380, in _execvpe
                func(fullname, *argrest)
            OSError: [Errno 2] No such file or directory

============================================================
                       END OF ERRORS                      
============================================================

After this i did :

yum install grubby

And now i get :
Code:
============================================================


                           ERRORS                           


============================================================





2022-02-05 21:59:24.765053 [ERROR] Actor: source_boot_loader_scanner


Message: Failed to call `grubby` to list available boot entries.


Summary:


    Details: Command ['grubby', '--info', 'ALL'] failed with exit code 1.


    Stderr: 





============================================================


                       END OF ERRORS                        


============================================================
 
Back
Top