Open osprinzl opened 4 months ago
The option --repo is not known in yum. This should be --enablerepo=
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?
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:
ls -la /boot/grub2
cat /boot/grub2/grub.cfg
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: `
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 `
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 :)
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.
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
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:
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