Almalinux 8 to the 9

Support
1

Hello
I get this error when I run this command:
sudo leap upgrade

============================================================
REPORT OVERVIEW
============================================================

Upgrade has been inhibited due to the following problems:
1. Detected incorrect order of entries or duplicate entries in /etc/fstab, preventing a successful in-place upgrade.
2. Possible problems with remote login using root account
3. Detected RPMs with RSA/SHA1 signature

HIGH and MEDIUM severity reports:
1. Packages not signed by Red Hat found on the system
2. GRUB2 core will be automatically updated during the upgrade
3. Remote root logins globally allowed using password
4. Detected custom leapp actors or files.
5. Leapp detected a processor which is no longer maintained in RHEL 9.
6. MariaDB (mariadb-server) has been detected on your system

Reports summary:
Errors: 0
Inhibitors: 3
HIGH severity reports: 5
MEDIUM severity reports: 1
LOW severity reports: 1
INFO severity reports: 2

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

Mz

2

Hi there and welcome! Were you able to find any additional information in the generated logs?

3

Hi Benny, apologies if I’m hijacking this thread, but I thought I would ask here real quick instead of making a new thread…

In the distant future, I’m planning on upgrading from 8.10 to 9 as well. I just wanted to be sure if the upgrade can be done via remotely or does it have to be done locally?

I’m mainly wondering because when I went over the guide, there are reboots that need to be done and when rebooting via remotely, you’re logged out the terminal, and I was wondering would that cause any issues for the upgrade process? Or is the process the same and/or no difference when doing it locally? Doing it remotely, do you just wait for the system to restart and then log back into the terminal remotely?

Thank you!

4

First, a separate thread for distinct issue would IMHO be warranted. The thread title here is less descriptive than it could be.

Then a disclaimer: I have never done in-place conversion, so don’t know what it does.

Logically, the process installs a new kernel and on reboot system is loaded with that new kernel. If not, then user would have to select the new kernel at bootloader, which step naturally ought to be mentioned somewhere.

Hypothetically, a process could first reboot to “installer” that does the main work, before rebooting to the “new distro”. If that installer would require any interaction, then one would have to be “on it”, and I presume that “log into” would not be possible. However, my guess is that if there is such step, then it requires no interaction.

So yes, the “wait” is the way, just like every time you reboot the machine. I do know how unnerving that can be.

A machine can have keyboard, display, and mouse (KVM) directly connected – a “console”. If so, the access is local. On console one can access also BIOS settings. There are KVM-over-network products. One can connect to such remotely and use the machine as one were local. The next level of hardware are the idrac/ilo/ipmi, which are essentially a minicomputer attached to the server. One has remote access to BIOS, console, and power button. Hard reset and poweron are things that mere KVM cannot do. Virtual machines are run by hypervisor. Hypervisor can give access to “power button” and console – there is less “BIOS”, but one can change the “virtual hardware” attached to a guest. Granted, not all “cloud providers” give access to hypervisor.

If you have no access to “console” by any of those means, then you are at the mercy of your operating system. If it fails to boot, or does not accept remote sessions (e.g. terminal via ssh), then there is nothing that you can do remotely.

There is always a chance that something goes wrong. With more radical change, like in-place conversion of AlmaLinux 8 system into AlmaLinux 9 system, there is “elevated risk” for that.

5

Thanks @jlehtone - that was a great reply.

and welcome @DonX! I’m so glad you asked this question. As a note: I definitely recommend a new thread in the future for lots of operational-type-reasons (we ask contributors to keep an eye on new posts that don’t have replies yet so that threads aren’t missed, and I honestly am only on the forums a couple times a month, so I didn’t see this one), but also (like @jlehtone said) the title isn’t as useful as it could be for future folks searching for answers.

If you’ve got more questions related to this, I recommend splitting this one into a new thread so you can have more specific conversation there, especially in case @MisterM74 does come back for more discussion of their original problem.