Libguestfs - Jan 2019 - [PATCH] v2v: Fix kernel disambiguation by dropping Epoch field (RHBZ#1669395).

When detecting kernels we have to list the files in the package to
find the right /boot/vmlinuz file.

In virt-v2v 1.28 we ran:

  rpm -ql kernel

Because multiple kernels can be installed this gave incorrect results,
which was reported in RHBZ#1161250 and initially fixed in
commit 377bc302f11db3da4263f894c76a7d280fb25dbd.  This changed the
command to:

  rpm -ql [epoch:]kernel-version.release

where the epoch: prefix was only used if the epoch was != 0.

However this in fact failed if epoch was != 0 (which isn't the case
for ordinary RHEL kernels in RHEL >= 5).  Since it broke RHEL <= 4
this was reported as bug RHBZ#1170685 and fixed only for RHEL 3/4 in
commit 205a8c7ca1ed1d66bef56d75c3c244e726e3bbbf.

That fix removed the optional epoch: prefix for RHEL 3/4.  But the
prefix is wrong on all versions of RPM, even the latest one.  eg. on
Fedora 29:

  $ rpm -ql 2:qemu-3.1.0-4.fc30.x86_64
  package 2:qemu-3.1.0-4.fc30.x86_64 is not installed

(In fact latest RPM does let you use name-epoch:version.release, but
that was not true in RHEL 6 or 7).

The solution here is to remove the epoch entirely.  It's rather
unlikely that two kernels will be installed with identical NVR and
different Epoch.  Just using NVR is sufficient to fix the original bug
RHBZ#1161250.

Thanks: Germano Veit Michel for bug reporting and analysis.
---
 v2v/linux.ml | 20 +-------------------
 1 file changed, 1 insertion(+), 19 deletions(-)

diff --git a/v2v/linux.ml b/v2v/linux.ml
index 43449157b..663db8697 100644
--- a/v2v/linux.ml
+++ b/v2v/linux.ml
@@ -80,29 +80,11 @@ let file_list_of_package (g : Guestfs.guestfs) inspect app  
   | "rpm" ->
     (* Since RPM allows multiple packages installed with the same
-     * name, always check the full ENVR here (RHBZ#1161250).
+     * name, always check the full NVR here (RHBZ#1161250).
      *)
     let pkg_name        sprintf "%s-%s-%s" app.G.app2_name
         app.G.app2_version app.G.app2_release in
-    let pkg_name -      if app.G.app2_epoch > 0_l then (
-        (* RHEL 3/4 'rpm' does not support using the epoch prefix.
-         * (RHBZ#1170685).
-         *)
-        let is_rhel_lt_5 -          match inspect with
-          | { i_type = "linux";
-              i_distro = "rhel" | "centos" |
"scientificlinux" |
-                  "oraclelinux" | "redhat-based";
-              i_major_version = v } when v < 5 -> true
-          | _ -> false in
-        if is_rhel_lt_5 then
-          pkg_name
-        else
-          sprintf "%ld:%s" app.G.app2_epoch pkg_name
-      ) else
-        pkg_name in
     let cmd = [| "rpm"; "-ql"; pkg_name |] in
     debug "%s" (String.concat " " (Array.to_list cmd));
     let files = g#command_lines cmd in
-- 
2.20.1

On Tuesday, 29 January 2019 11:41:16 CET Richard W.M. Jones
wrote:
> When detecting kernels we have to list the files in the package to
> find the right /boot/vmlinuz file.
> 
> In virt-v2v 1.28 we ran:
> 
>   rpm -ql kernel
> 
> Because multiple kernels can be installed this gave incorrect results,
> which was reported in RHBZ#1161250 and initially fixed in
> commit 377bc302f11db3da4263f894c76a7d280fb25dbd.  This changed the
> command to:
> 
>   rpm -ql [epoch:]kernel-version.release
> 
> where the epoch: prefix was only used if the epoch was != 0.
> 
> However this in fact failed if epoch was != 0 (which isn't the case
> for ordinary RHEL kernels in RHEL >= 5).  Since it broke RHEL <= 4
> this was reported as bug RHBZ#1170685 and fixed only for RHEL 3/4 in
> commit 205a8c7ca1ed1d66bef56d75c3c244e726e3bbbf.
> 
> That fix removed the optional epoch: prefix for RHEL 3/4.  But the
> prefix is wrong on all versions of RPM, even the latest one.  eg. on
> Fedora 29:
> 
>   $ rpm -ql 2:qemu-3.1.0-4.fc30.x86_64
>   package 2:qemu-3.1.0-4.fc30.x86_64 is not installed
> 
> (In fact latest RPM does let you use name-epoch:version.release, but
> that was not true in RHEL 6 or 7).
> 
> The solution here is to remove the epoch entirely.  It's rather
> unlikely that two kernels will be installed with identical NVR and
> different Epoch.  Just using NVR is sufficient to fix the original bug
> RHBZ#1161250.
Or it could do what supermin does, i.e. use NEVR:

  let rpm_package_to_string pkg     (* In RPM < 4.11 query commands that use
the epoch number in the
     * package name did not work.
     *
     * For example:
     * RHEL 6 (rpm 4.8.0):
     *   $ rpm -q tar-2:1.23-11.el6.x86_64
     *   package tar-2:1.23-11.el6.x86_64 is not installed
     * Fedora 20 (rpm 4.11.2):
     *   $ rpm -q tar-2:1.26-30.fc20.x86_64
     *   tar-1.26-30.fc20.x86_64
     *
     *)
    let is_rpm_lt_4_11       !rpm_major < 4 || (!rpm_major = 4 &&
!rpm_minor < 11) in
  
    let rpm = rpm_of_pkg pkg in
    if is_rpm_lt_4_11 || rpm.epoch = 0 then
      sprintf "%s-%s-%s.%s" rpm.name rpm.version rpm.release rpm.arch
    else
      sprintf "%s-%d:%s-%s.%s"
        rpm.name rpm.epoch rpm.version rpm.release rpm.arch

https://github.com/libguestfs/supermin/blob/master/src/ph_rpm.ml#L171

I just sent a patch to fix this:
https://www.redhat.com/archives/libguestfs/2019-January/msg00222.html

-- 
Pino Toscano