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

[osprinzl]

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]

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

[SandakovMM]

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]

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]

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]

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]

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]

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

[brownsugar]

Hi I got the same error and I think it's using BIOS mode.

# ll /sys/firmware/
total 0
drwxr-xr-x.  5 root root 0 Feb 15 16:42 acpi
drwxr-xr-x.  4 root root 0 Feb 15 16:42 dmi
drwxr-xr-x. 13 root root 0 Feb 15 15:21 memmap
drwxr-xr-x.  4 root root 0 Feb 15 16:42 qemu_fw_cfg

I provided the full feedback archive here: #416 (comment)

[brownsugar]

I guess I've found the root cause of the failure.

In file leapp-report.txt:

Risk Factor: high
Title: Leapp could not identify where GRUB2 core is located
Summary: We assumed GRUB2 core is located on the same device(s) as /boot, however Leapp could not detect GRUB2 on those device(s). This means GRUB2 core will not be updated during the u
pgrade process and the system will probably boot into the old kernel after the upgrade. GRUB2 core needs to be updated manually on legacy (BIOS) systems to fix this.

Try to execute grub2-install <GRUB_DEVICE> get the following error

Installing for i386-pc platform.
grub2-install: warning: File system ext2' doesn't support embedding.
grub2-install: warning: Embedding is not possible.  GRUB can only be installed in this setup by using blocklists.  However, blocklists are UNRELIABLE and their use is discouraged..
grub2-install: error: will not proceed with blocklists.

Check my disks:

$ lsblk
NAME MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda    8:0    0 159.8G  0 disk /boot
sdb    8:16   0   256M  0 disk [SWAP]

$ fdisk -l
Disk /dev/sdb: 268 MB, 268435456 bytes, 524288 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk /dev/sda: 171.5 GB, 171530256384 bytes, 335020032 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

$ cat /proc/partitions
major minor  #blocks  name
   8       16     262144 sdb
   8        0  167510016 sda

According to ChatGPT, there are usually two partitions for /dev/sda, /dev/sda1 for /boot and /dev/sda2 for /, however in my case, /boot seems to be directly mounted on /sda.
It suggested that I have to split the partitions for /sda, but it will wipe all data on the disk, since I'm not sure if this is the correct solution, I want to confirm if there's a better way to deal with this...