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?).
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.
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 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.