similar to: [PATCH] v2v: linux: fix kernel detection when split in different packages

The current detection code for Linux kernels assumes that a kernel package contains everything in it, i.e. the kernel itself, its modules, and its configuration. However, since recent Ubuntu versions (e.g. starting from 18.04) modules & config (with few more files) are split in an own package, thus not detecting the modpath from installed vmlinuz files. To overcome this situation, rework

We check for /boot/vmlinuz-* files in packages with files, and List.find will raise Not_found if there are none. Iterating on an empty list gives the same result, so there is no need to handle empty packages in a special way. --- v2v/linux_kernels.ml | 321 +++++++++++++++++++++---------------------- 1 file changed, 158 insertions(+), 163 deletions(-) diff --git a/v2v/linux_kernels.ml

Create a new module [Linux_kernels] which does all kernel detection, and also provides a place to define the kernel_info data structure. This is essentially just code motion. --- v2v/Makefile.am | 2 + v2v/convert_linux.ml | 219 +++-------------------------------------------- v2v/linux_kernels.ml | 230 ++++++++++++++++++++++++++++++++++++++++++++++++++ v2v/linux_kernels.mli | 50

Metapackages are valid packages with no files, used to easily install something without manually installing bits. This is the case of the "kernel" package in Fedora/RHEL/etc in the last couple of years. --- v2v/linux_kernels.ml | 1 - 1 file changed, 1 deletion(-) diff --git a/v2v/linux_kernels.ml b/v2v/linux_kernels.ml index 9a41225a..78c1ee59 100644 --- a/v2v/linux_kernels.ml +++

https://bugzilla.redhat.com/show_bug.cgi?id=2175703 Vera Wu's testing covered a backport of this series to the virt-v2v project's rhel-9.2 branch (on top of commit 86517b17be98), where the "detect_kernels" function is still unique/internal to the virt-v2v project. The backport / cherry-pick from libguestfs-common to virt-v2v cannot be automated, but it's not difficult; only

https://bugzilla.redhat.com/show_bug.cgi?id=2175703 In RHEL-9.2, the "detect_kernels" function still exists in virt-v2v, not in the common submodule. Because we need to fix RHBZ#2175703 for RHEL-9.2.z as well, port of the identically named libguestfs-common patch series <http://mid.mail-archive.com/20230320115301.43051-1-lersek at redhat.com> to RHEL-9.2 virt-v2v. This port is

Try to look for a well known kernel module (so far only virtio, or kvm) to use for detecting the architecture of a kernel. This way, we can avoid picking 3rd party modules that cause troubles. --- v2v/linux_kernels.ml | 30 +++++++++++++++++++++++++++--- 1 file changed, 27 insertions(+), 3 deletions(-) diff --git a/v2v/linux_kernels.ml b/v2v/linux_kernels.ml index 3313aabc7..f1b9bdd97 100644

Kernel modules can be also symlinks to files available outside the "canonical" module directory; since `file` by default does not deference symlinks, passing directly symlinks to the architecture detection results in errors, as the "file" API does not recognize "symbolic link" as architecture. To prevent this situation, canonicalize the path of the module picked for

This is a sort of follow-up to the Linux_bootloaders patch. It turns out all the kernel detection code is nicely self- contained and can therefore be moved to its own module. Rich.

We want to detect if a Linux kernel is Xen PV only ("PV-only"). Such a kernel will not boot on KVM, and if a guest has only PV-only kernels, it will not be able to boot at all on the target. Our previous test was wrong. It tested whether the xennet.ko module exists. This module was renamed in more recent kernels (to xen-netfront.ko), so it happened to not detect modern kernels as

We want to detect if a Linux kernel is Xen PV only ("PV-only"). Such a kernel will not boot on KVM, and if a guest has only PV-only kernels, it will not be able to boot at all on the target. Our previous test was wrong. It tested whether the xennet.ko module exists. This module was renamed in more recent kernels (to xen-netfront.ko), so it happened to not detect modern kernels as

Previously the kernel_info field 'ki_supports_virtio' really meant that the kernel supports virtio-net. That was used as a proxy to mean the kernel supports virtio in general. This change splits the field so we explicitly test for both virtio-blk and virtio-net drivers, and store the results as separate fields. The patch is straightforward, except for the change to the

Split the processing of the kernel packages in two phases: - filtering only (by name) - actual processing This makes the filtering part easier to review/modify, and it is now much easier to see (in the debug log) which packages are processed as kernel packages. There are no behaviour changes (other than an additional debug message). --- v2v/linux_kernels.ml | 20 +++++++++++++------- 1 file

On Wed, Mar 20, 2019 at 05:00:06PM +0100, Pino Toscano wrote: > Kernel modules can be also symlinks to files available outside the > "canonical" module directory; since `file` by default does not deference > symlinks, passing directly symlinks to the architecture detection > results in errors, as the "file" API does not recognize "symbolic link" > as

They usually contain only the sources of the kernel, useful to build kernel modules. --- v2v/linux_kernels.ml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/v2v/linux_kernels.ml b/v2v/linux_kernels.ml index dc0c285d..9a41225a 100644 --- a/v2v/linux_kernels.ml +++ b/v2v/linux_kernels.ml @@ -92,7 +92,7 @@ let detect_kernels (g : G.guestfs) inspect family bootloader = let

Make sure the type checker can detect the real type of 'g', even when adding more code using it in detect_kernels. --- v2v/linux_kernels.ml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/v2v/linux_kernels.ml b/v2v/linux_kernels.ml index 3819d26..b292921 100644 --- a/v2v/linux_kernels.ml +++ b/v2v/linux_kernels.ml @@ -49,7 +49,7 @@ let string_of_kernel_info ki =

Actually I have another comment about this patch .. On Tue, Sep 27, 2016 at 05:58:11PM +0200, Pino Toscano wrote: > diff --git a/v2v/linux_kernels.ml b/v2v/linux_kernels.ml > index b292921..c197f78 100644 > --- a/v2v/linux_kernels.ml > +++ b/v2v/linux_kernels.ml > @@ -53,6 +53,21 @@ let detect_kernels (g : G.guestfs) inspect family bootloader = > (* What kernel/kernel-like

When checking whether a kernel supports virtio or it is Xen-based, it is assumed that the feature has the kernel module for it; this will fail if the feature is built-in in the kernel, misrepresenting it. The solution is to check the kernel configuration (/boot/config-$kver) whether the feature is built-in, in case there is no module available. This fixes the virtio detection on Ubuntu kernels,

When checking whether a kernel supports virtio or it is Xen-based, it is assumed that the feature has the kernel module for it; this will fail if the feature is built-in in the kernel, misrepresenting it. The solution is to check the kernel configuration whether the feature is built-in, in case there is no module available. This fixes the virtio detection on Ubuntu kernels, where virtio is built

Updates commit 7eb219d1938968c4d6bffda038aaace936f7efbf. --- v2v/linux_kernels.ml | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/v2v/linux_kernels.ml b/v2v/linux_kernels.ml index 2efd070a6..9fbc43b60 100644 --- a/v2v/linux_kernels.ml +++ b/v2v/linux_kernels.ml @@ -182,7 +182,8 @@ let detect_kernels (g : G.guestfs) inspect family bootloader = List.mem what