Migrating from CentOS VServer - Errors with "leapp preupgrade"


I ran leapp preupgrade on my CentOS 7 VServer and got two errors:

Risk Factor: high
Title: Failed to call `grubby` to list available boot entries.
Summary: {"details": "Command ['grubby', '--info', 'ALL'] failed with exit code 1.", "stderr": ""}
Key: xxxxxx
Risk Factor: high
Title: Packages from unknown repositories may not be installed
Summary: 1 packages may not be installed or upgraded due to repositories unknown to leapp:
- kernel-uek (repoid: ol8-uek)
Remediation: [hint] Please file a bug in http://bugzilla.redhat.com/ for leapp-repository component of the Red Hat Enterprise Linux product.
Key: xxxxxx

(I removed the keys, just in case publishing them here could pose a security threat. If you need them, I can supply them).
While I’m pretty sure that the first is no problem (there is no boot option), I am concerned about the second one. I read that “uek” stands for “unbreakable enterprise kernel”, which in general is good, I guess, but I can’t do anything about it. The VServer (virtual server, based on XEN) is hosted by a provider, who usually provides the OS and installs it automatically once I’ve made the choice which one I want to use. Several years ago, I opted for CentOS and was quite happy with it. I set it up to update packages which had received security updates automatically. But i never did anything with the kernel.
Does this mean that I cannot chose Almalinux as my future server OS, or can I ignore this as well? Or should I consult with my Provider (their support is expensive, and I am not an enterprise with a budget for IT related things, but a private individual)?
The CentOS version is 7.9.2009 (Core)
The output of uname -srm is Linux 5.4.116-xen x86_64. This tells me that it is not using the kernel provided by CentOS (which should be 3.10?).

that’s not centos its oracle linux.

what does this return:

cat /etc/*release*

I get this:

CentOS Linux release 7.9.2009 (Core)
Derived from Red Hat Enterprise Linux 7.9 (Source)
NAME="CentOS Linux"
VERSION="7 (Core)"
ID_LIKE="rhel fedora"
PRETTY_NAME="CentOS Linux 7 (Core)"


CentOS Linux release 7.9.2009 (Core)
CentOS Linux release 7.9.2009 (Core)

Is ‘leapp’ same as ‘ELevate’? AlmaLinux OS - Forever-Free Enterprise-Grade Operating System

Personally, I would not migrate anything between major versions, but if forced, I’d give ELevate a try.

so someone has installed the oracle uek-kernel (for ol8!) on your centos 7.9 box.

i’d rebuild rather than bothering trying to fix that mess.

It’s a virtual server with a preinstalled OS. I could initially choose the OS, but it seems the provider chooses the kernel to make sure multiple virtual machines can run on one physical server. While I have full root access to the server via SSH, I cannot influence the boot process.
My question is only: do I need to be concerned about the two indicated problems? As mentioned, there is no grub (or rather, there is no option to choose from when booting the machine), so I guess that wouldn’t cause a problem, but I may be wrong.
And the other: I have four kernel versions sitting in the boot directory, which have been installed by the regular updates, but they are not being used. Both issues are related, and both in my view would not cause a problem, because the booted kernel cannot be accessed by any installation or migration or upgrading tool.
The right question is probably: can Almalinux handle such a situation?
I have contacted the provider and wait for his reply. The choices of OS are limited, AlmaLinux is not part of it. That’s why I thought it might be good to do the migration instead of changing the entire OS, which would be the only alternative and would mean a lot of work in order to get everything properly running again.

you need to remove the kernel-uek package and ol8-uek repo and boot back into the rhel 3.10 kernel before trying elevate again.

the first error may be as simple as you don’t have grubby installed.

There is no repo entry, and there is no kernel-uek package. As I mentioned earlier, I guess that the provider uses this kernel for all virtual machines on the physical server, and I can not influence that part.

I just checked, grubby is installed.

I presume that the kernel (and initramfs) are not in the VM image and the virtualization platform explicitly refers to them, when booting the VM. For example, libvirtd/KVM can do so.
The VM is a mere container of userland utilities.

This offers some extra security, because one cannot tamper those files from within the VM.
However, it also implies that the service provider does all kernel patching and that the userland tools must be kept compatible with the chosen kernel.

CentOS Linux 7 can be used to June 2024. Need for migration is not imminent.

What distro options are there?

yeah sounds like xen is like openvz and the like - uses/displays the host kernel and ignores whatever you have installed in the guest.

i’d say keep using centos 7.9 or move to a fresh install of alma 8.5 with a different host (that uses kvm!)