plesk / centos2alma

CentOS 7 to AlmaLinux 8 conversion tool
Apache License 2.0
39 stars 10 forks source link

centos2alma process has failed. Error: Failed: update modern mariadb. #313

Open osprinzl opened 4 months ago

osprinzl commented 4 months ago

Describe the bug I tried to upgrade a CentOS 7 system to Alma Linux 8. This system has a custom MariaDB installation (10.4). As far as I understand this will be reinstalled with CentOS/AlmaLinux 8 MariaDB packages. Here is a problem in the update/reinstall routine, it generates a yum error and breaks further install:

2024-07-24 02:49:52,497 - INFO - Running: ['/usr/bin/yum', 'install', '--repo', 'alma-alma-mariadb', '-y', 'MariaDB-client', 'MariaDB-server']. Output:
2024-07-24 02:49:52,662 - INFO - Loaded plugins: fastestmirror
2024-07-24 02:49:52,666 - INFO - Command line error: no such option: --repo
2024-07-24 02:49:52,666 - INFO - Usage: yum [options] COMMAND
...
2024-07-24 02:49:52,679 - ERROR - Command ['/usr/bin/yum', 'install', '--repo', 'alma-alma-mariadb', '-y', 'MariaDB-client', 'MariaDB-server'] failed with return code 1
2024-07-24 02:49:52,679 - ERROR - Failed: update modern mariadb. The reason: Command '['/usr/bin/yum', 'install', '--repo', 'alma-alma-mariadb', '-y', 'MariaDB-client', 'MariaDB-server']' returned non-zero exit status 1.

Could this be fixed?

The upgrade routine removes the following RPM packages: MariaDB-server MariaDB-common MariaDB-compat MariaDB-client But it needs to remove galera-4-26.4.18-1.el7.centos.x86_64 as well!

Kernel: 3.10.0-1160.119.1.el7.x86_64

Feedback archive centos2alma_feedback.zip

osprinzl commented 4 months ago

The option --repo is not known in yum. This should be --enablerepo=

SandakovMM commented 4 months ago

The option --repo is not known in yum. This should be --enablerepo=

The --repo option is meant for AlmaLinux 8, where yum is an alias of the dnf utility, which supports the --repo argument. It appears that, for some reason, centos2alma resume was initiated inside CentOS 7, which is unexpected.

It seems that CentOS 7 was not converted to AlmaLinux 8 in the temporary container created by leapp. To determine exactly what happened, the processes inside the container need to be checked via console. Can you access these logs?

SandakovMM commented 1 month ago

I suspect that your system did not reboot into the temporary container that elevate uses to install new packages. This usually occurs when there is an unexpected issue with the grub configuration. We encountered a similar issue as described in issue #224.

Could you confirm whether you are using an EFI-based system? Alternatively, please provide the following information:

  1. ls -la /boot/grub2
  2. cat /boot/grub2/grub.cfg
osprinzl commented 1 month ago

First off: this issue is not on a "high" priority anymore. I am using CentOS 7 a year further with TuxCare support. The system with this error is not a EFI system, it boots in standard BIOS mode: `

ls -l /sys/firmware/

total 0 drwxr-xr-x. 5 root root 0 Oct 8 11:08 acpi drwxr-xr-x. 4 root root 0 Oct 8 11:08 dmi drwxr-xr-x. 12 root root 0 Oct 8 11:08 memmap drwxr-xr-x. 2 root root 0 Oct 8 11:08 qemu_fw_cfg `

MegaS0ra commented 3 days ago

Hi, I had the same error, but as pointed by @SandakovMM, it's not the root cause of the problem, (and I guess it could be a different cause for everyone). So I found the "real" error (for my case at least) at the very beginning of the file /var/log/leapp/leapp-report.txt, the relevant lines were :

CalledProcessError: Command ['/bin/mount', '-a'] failed with exit code 32.
Actor remove_upgrade_boot_entry unexpectedly terminated with exit code: 1

This was because of a line in /etc/fstab about an unavailable partition (which was not needed anyway) : The Leapp process tried to mount this partition before starting to convert, and it failed to do so, so it stops the convert process right there.

On the production server, a "mount -a" gave me this error :

mount: wrong fs type, bad option, bad superblock on /dev/loop0,
       missing codepage or helper program, or other error

So for my case, fixing the /etc/fstab solves this issue.

If you end up here, I can only advice to check for the beginning of the /var/log/leapp/leapp-report.txt file :)

SandakovMM commented 1 day ago

Thank you, @MegaS0ra, for the investigation. At the very least, I can add a pre-checker to ensure that /etc/fstab is correct before beginning the conversion.

MegaS0ra commented 1 day ago

Thanks @SandakovMM, I guess a pre-check would help :)

I should also let you know that the entry in my fstab was not something mandatory for the system to work, as it contained the option "nofail" : /var/tmpDIR /tmp ext3 loop,nosuid,nofail,noexec,rw 0 0