Hello. It is possible to update? Thanks
It is! You will need to use ELevate to get there: ELevating CentOS 7 to AlmaLinux 9 | AlmaLinux Wiki
It’s also possible without ELevate, but isn’t recommended. Essentially the process is installing the updated repo/release/gpg-keys packages, and running a distro-sync, but please don’t do that unless you want to learn how to do this.
IMHO, the “update” is not a specific term.
The methods above convert existing system in-place from one distro (Alma 8) to another (Alma 9).
The other “update” approach is to make a fresh install of Alma 9, install desired packages, deploy appropriate config, and restore user data from backup (unless it is on separate filesystem that can be simply mounted by Alma 9).
Either way, (and even when not attempting update of any kind), have backups.
REPORT OVERVIEW
============================================================
Upgrade has been inhibited due to the following problems:
1. Detected RPMs with RSA/SHA1 signature
2. Firewalld Configuration AllowZoneDrifting Is Unsupported
HIGH and MEDIUM severity reports:
1. Packages not signed by Red Hat found on the system
2. Remote root logins globally allowed using password
3. Detected custom leapp actors or files.
4. Leapp detected loaded kernel drivers which are no longer maintained in RHEL 9.
5. MariaDB (mariadb-server) has been detected on your system
Reports summary:
Errors: 0
Inhibitors: 2
HIGH severity reports: 4
MEDIUM severity reports: 1
LOW severity reports: 1
INFO severity reports: 3
Before continuing, review the full report below for details about discovered problems and possible remediation instructions:
A report has been generated at /var/log/leapp/leapp-report.txt
A report has been generated at /var/log/leapp/leapp-report.json
============================================================
END OF REPORT OVERVIEW
Alma 9 defaults to not support SHA1. Implicitly, Alma 8 packages are not signed with SHA1 either, or the problem would be with every system. Therefore, you probably have el8 packages from a third-party repo that is still using SHA1.
The logical action is to uninstall those packages and (re)install equivalent functionality when system is Alma 9.
The AllowZoneDrifting feature used to be default, but should not be any more. You have most likely customized the FirewallD config to re-enable it. You know what you did and why?
The logical action is to update the firewall config to behave without the AllowZoneDrifting. (One could drop to minimal default config, elevate, and then build the new ruleset “from scratch”.)
Third-party packages, as we already know from the SHA1 issue.
Alma 9 defaults to disable ssh to root with password (and allow keypair auth) for better security. Not an error, but a thing to consider.
I’ve never used ELevate, so cannot guess what that means.
You have some older devices that el9 kernel does not have (included) drivers for. The drivers can usually be found and installed from ELRepo, but the question is whether the devices are critical?
- If the device is critical, for example the disk controller, then you cannot trivially boot with el9 kernel and then install the driver (as you cannot access the disk).
- If the device is not critical, then that is no issue.
lspci -nn lists devices (with device ID). The logs should tell which devices to look at?
SQL databases tend to have their own procedures for migration from one version of the database engine to another version of the engine.
Perhaps one can dump the database to file, remove mariadb-server, and import the data to new install after update? If mariadb’s version stays the same, then that should be trivial. If mariadb’s version changes, then you may have to do whatever the version change requires.
2 Likes