Bug 1840485
| Summary: | Remove bogus gcry_check_version and use RPM dependencies and symbol versions to pull in necessary gnutls/libgcrypt | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux Advanced Virtualization | Reporter: | mxie <mxie> |
| Component: | qemu-kvm | Assignee: | Richard W.M. Jones <rjones> |
| qemu-kvm sub component: | Testing | QA Contact: | Yanan Fu <yfu> |
| Status: | CLOSED CURRENTRELEASE | Docs Contact: | |
| Severity: | medium | ||
| Priority: | medium | CC: | akaris, chayang, coli, hhan, jinzhao, jsuchane, juzhang, juzhou, mzhan, ptoscano, rjones, tyan, tzheng, virt-maint, xiaodwan, xuwei, yfu, yoguo |
| Version: | 8.3 | Keywords: | Triaged |
| Target Milestone: | rc | ||
| Target Release: | 8.3 | ||
| Hardware: | x86_64 | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | qemu-kvm-5.2.0-8.module+el8.4.0+10093+e085f1eb.x86_64 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2021-11-27 07:27:01 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
Very true! I noticed this problem the other day too on RHEL AV. This is the call which fails: https://git.qemu.org/?p=qemu.git;a=blob;f=crypto/init.c;h=b305381ec540ebe79903632ddc9bc1eb65274f58;hb=HEAD#l124 if (!gcry_check_version(GCRYPT_VERSION)) { error_setg(errp, "Unable to initialize gcrypt"); What this function is supposed to do is check that the minimum required version of libgcrypt is installed. The qemu-kvm binary has a later version baked in (probably "1.8.5"), so this test fails when run against the older libgcrypt (1.8.3). However I believe our use of GCRYPT_VERSION is wrong here anyway. You're supposed to pass in the minimum version you require (eg. if you're using APIs only present in a later version), or NULL if you don't care. We don't care because libgcrypt uses versioned symbols so we don't need to do anything if we use later APIs not present in an earlier version. The libgcrypt.h header even says you shouldn't use GCRYPT_VERSION. Suggested fix is: - if (!gcry_check_version(GCRYPT_VERSION)) { + if (!gcry_check_version(NULL)) { Trivial patch sent upstream. It should appear here soon: https://lists.nongnu.org/archive/html/qemu-devel/2020-05/threads.html I think this issue is same with https://bugzilla.redhat.com/show_bug.cgi?id=1828681 Hi Richard, I see you have mark https://bugzilla.redhat.com/show_bug.cgi?id=1925029 as duplicate with https://bugzilla.redhat.com/show_bug.cgi?id=1828681. They are all same issue. How about this one ? Could we close it as duplicate with https://bugzilla.redhat.com/show_bug.cgi?id=1828681, thanks! Best regards Yanan Fu The other bug is RHEL (not AV). My patch to fix this is present in qemu 5.1.0 upstream, so this has been fixed in RHEL AV 8.4.0 (and possibly earlier). (In reply to Richard W.M. Jones from comment #7) > The other bug is RHEL (not AV). > > My patch to fix this is present in qemu 5.1.0 upstream, so this > has been fixed in RHEL AV 8.4.0 (and possibly earlier). For other bugs, they does not change the qemu-kvm and libgcrypt dependencies, the issue was fixed with compose update(libgcrypt update together) What's solution for this bz ? Does it make 'libgcrypt' as the dependences for 'qemu-kvm' ? After QEMU 5.1 rebase to downstream, no new libgcrypt build was created, RHEL8.4 always use 'libgcrypt-1.8.5-4.el8'. The bug was in qemu, not libgcrypt, so no update to libgcrypt is needed or expected. Since we're going to require an exception to "fix" this bug, and since the bug has already been fixed in qemu - some time ago - I suggest we simply close this bug, unless there is any evidence that the bug is still present. (In reply to Richard W.M. Jones from comment #9) > The bug was in qemu, not libgcrypt, so no update to libgcrypt is needed > or expected. yes, i see that, no need to update libgcrypt. My point it, only one version in libgcrypt, how can we verify it will be updated automatically when we update qemu-kvm ? > > Since we're going to require an exception to "fix" this bug, and since the > bug has already been fixed in qemu - some time ago - I suggest we simply > close this bug, unless there is any evidence that the bug is still present. (In reply to Yanan Fu from comment #10) > My point it, only one version in libgcrypt, how can we verify it will be > updated > automatically when we update qemu-kvm ? The original bug was really the reverse of this. (The summary of this bug is not correct.) What happened was libgcrypt was and is being updated just fine. But qemu contained an extra check - the call the gcry_check_version - which prevented qemu from working, even though it would have worked fine. The extra check caused it to print this message and fail: qemu-img: Unable to initialize gcrypt The solution was to remove the extra check and rely on the usual mechanism of symbol versions. (In reply to Richard W.M. Jones from comment #11) > (In reply to Yanan Fu from comment #10) > > My point it, only one version in libgcrypt, how can we verify it will be > > updated > > automatically when we update qemu-kvm ? > > The original bug was really the reverse of this. (The summary of this > bug is not correct.) What happened was libgcrypt was and is being updated > just fine. But qemu contained an extra check - the call the > gcry_check_version - > which prevented qemu from working, even though it would have worked fine. > > The extra check caused it to print this message and fail: > > qemu-img: Unable to initialize gcrypt > > The solution was to remove the extra check and rely on the usual > mechanism of symbol versions. Thanks for share the details. so, update qemu-kvm still won't update libgcrypt automatically. To use this bz to track the change you mentioned above, the current summary is confused. Could you update the summary to express the issue itself ? About the 'Fixed In Version', i think it is 'QEMU 5.1' as it was fixed after the rebase. Thanks! > so, update qemu-kvm still won't update libgcrypt automatically. Yes, it will! RPM dependencies will ensure the necessary version of libgcrypt is installed. In this bug the updated libgcrypt was not necessary, so it was not pulled in, but an additional (and incorrect) check in qemu-kvm caused it to fail anyway. > Could you update the summary to express the issue itself ? Done. > About the 'Fixed In Version', i think it is 'QEMU 5.1' as it was fixed after the rebase. I just put the latest version of qemu at the time of writing, but this was indeed fixed way back in qemu 5.1. Move to VERIFIED as the comments above, thanks! After evaluating this issue, there are no plans to address it further or fix it in an upcoming release. Therefore, it is being closed. If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened. This was fixed in the current release of RHEL AV. |
Description of problem: libgcrypt isn't updated with qemu-kvm Version-Release number of selected component (if applicable): qemu-kvm-5.0.0-0.module+el8.3.0+6620+5d5e1420.x86_64 libgcrypt-1.8.3-4.el8.x86_64 How reproducible: 100% Steps to Reproduce: 1.Check current version of qemu-kvm and libgcrypt # rpm -q qemu-kvm libgcrypt qemu-kvm-4.2.0-19.module+el8.3.0+6478+69f490bb.x86_64 libgcrypt-1.8.3-4.el8.x86_64 2.Configure correct repo to update qemu-kvm to latest version # yum update qemu-kvm -y .... Upgraded: qemu-img-15:5.0.0-0.module+el8.3.0+6620+5d5e1420.x86_64 qemu-kvm-15:5.0.0-0.module+el8.3.0+6620+5d5e1420.x86_64 qemu-kvm-block-curl-15:5.0.0-0.module+el8.3.0+6620+5d5e1420.x86_64 qemu-kvm-block-gluster-15:5.0.0-0.module+el8.3.0+6620+5d5e1420.x86_64 qemu-kvm-block-iscsi-15:5.0.0-0.module+el8.3.0+6620+5d5e1420.x86_64 qemu-kvm-block-rbd-15:5.0.0-0.module+el8.3.0+6620+5d5e1420.x86_64 qemu-kvm-block-ssh-15:5.0.0-0.module+el8.3.0+6620+5d5e1420.x86_64 qemu-kvm-common-15:5.0.0-0.module+el8.3.0+6620+5d5e1420.x86_64 qemu-kvm-core-15:5.0.0-0.module+el8.3.0+6620+5d5e1420.x86_64 3.Check version of qemu-kvm and libgcrypt again, we can see libgcrypt isn't updated with qemu-kvm # rpm -q qemu-kvm libgcrypt qemu-kvm-5.0.0-0.module+el8.3.0+6620+5d5e1420.x86_64 libgcrypt-1.8.3-4.el8.x86_64 4.Try to convert a guest by virt-v2v, but v2v conversion is failed with qemu-img error # virt-v2v -ic vpx://root.198.169/data/10.73.199.217/?no_verify=1 -it vddk -io vddk-libdir=/root/vmware-vix-disklib-distrib -io vddk-thumbprint=B5:52:1F:B4:21:09:45:24:51:32:56:F6:63:6A:93:5D:54:08:2D:78 esx7.0-win2019-x86_64 -ip /home/passwd -v -x ..... [ 1.7] Creating an overlay to protect the source from being modified qemu-img 'create' '-q' '-f' 'qcow2' '-b' 'nbd:unix:/tmp/v2vnbdkit.qQsFy0/nbdkit1.sock:exportname=/' '-o' 'compat=1.1,backing_fmt=raw' '/var/tmp/v2vovl214467.qcow2' qemu-img: Unable to initialize gcrypt virt-v2v: error: qemu-img command failed, see earlier errors ..... 5.Update libgcrypt to latest version # yum update libgcrypt -y .... Upgraded: libgcrypt-1.8.5-3.el8.x86_64 6.Convert a guest by virt-v2v again, the conversion can finish successfully # virt-v2v -ic vpx://root.198.169/data/10.73.199.217/?no_verify=1 -it vddk -io vddk-libdir=/root/vmware-vix-disklib-distrib -io vddk-thumbprint=B5:52:1F:B4:21:09:45:24:51:32:56:F6:63:6A:93:5D:54:08:2D:78 esx7.0-win2019-x86_64 -ip /home/passwd [ 0.2] Opening the source -i libvirt -ic vpx://root.198.169:443/data/10.73.199.217/?no_verify=1 esx7.0-win2019-x86_64 -it vddk -io vddk-libdir=/root/vmware-vix-disklib-distrib -io vddk-thumbprint=B5:52:1F:B4:21:09:45:24:51:32:56:F6:63:6A:93:5D:54:08:2D:78 [ 1.7] Creating an overlay to protect the source from being modified [ 2.7] Opening the overlay [ 9.1] Inspecting the overlay [ 15.7] Checking for sufficient free disk space in the guest [ 15.7] Estimating space required on target for each disk [ 15.7] Converting Windows Server 2019 Standard to run on KVM virt-v2v: warning: /usr/share/virt-tools/pnp_wait.exe is missing. Firstboot scripts may conflict with PnP. virt-v2v: warning: there is no QXL driver for this version of Windows (10.0 x86_64). virt-v2v looks for this driver in /usr/share/virtio-win/virtio-win.iso The guest will be configured to use a basic VGA display driver. virt-v2v: This guest has virtio drivers installed. [ 32.8] Mapping filesystem data to avoid copying unused and blank areas [ 33.8] Closing the overlay [ 34.1] Assigning disks to buses [ 34.1] Checking if the guest needs BIOS or UEFI to boot [ 34.1] Initializing the target -o libvirt -os default [ 34.2] Copying disk 1/1 to /var/lib/libvirt/images/esx7.0-win2019-x86_64-sda (raw) (100.00/100%) [ 511.1] Creating output metadata [ 512.3] Finishing off Actual results: As above description Expected results: libgcrypt should be updated with qemu-kvm Additional info: