Bug 1792370
| Summary: | libstoragemgmt prevents `dnf groupinstall base` | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | Jaroslav Mracek <jmracek> | ||||||
| Component: | libstoragemgmt | Assignee: | Tony Asleson <tasleson> | ||||||
| Status: | CLOSED ERRATA | QA Contact: | ChanghuiZhong <czhong> | ||||||
| Severity: | unspecified | Docs Contact: | |||||||
| Priority: | medium | ||||||||
| Version: | 8.0 | CC: | czhong, dgallowa, dmach, james.antill, swm-qe, tasleson | ||||||
| Target Milestone: | rc | Keywords: | Triaged | ||||||
| Target Release: | 8.4 | Flags: | pm-rhel:
mirror+
|
||||||
| Hardware: | Unspecified | ||||||||
| OS: | Unspecified | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | 1782899 | Environment: | |||||||
| Last Closed: | 2021-05-18 14:56:36 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: | |||||||||
| Bug Depends On: | |||||||||
| Bug Blocks: | 1782899 | ||||||||
| Attachments: |
|
||||||||
Hello,Tony I reproduced this bug with RHEL-8.1 and libstoragemgmt 1.8.1-2.el8 log: (119/120): libstoragemgmt-1.8.1-2.el8.x86_64.rpm 2.8 MB/s | 266 kB 00:00 (120/120): rhnsd-5.0.35-3.module+el8+2599+aa6b86f9.x86_64.rpm 43 kB/s | 51 kB 00:01 ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Total 1.3 MB/s | 49 MB 00:38 Running transaction check Transaction check succeeded. Running transaction test The downloaded packages were saved in cache until the next successful transaction. You can remove cached packages by executing 'dnf clean packages'. Error: Transaction check error: file /usr/lib/tmpfiles.d/libstoragemgmt.conf conflicts between attempted installs of libstoragemgmt-1.6.2-9.el8.i686 and libstoragemgmt-1.8.1-2.el8.x86_64 file /usr/share/doc/libstoragemgmt/NEWS conflicts between attempted installs of libstoragemgmt-1.6.2-9.el8.i686 and libstoragemgmt-1.8.1-2.el8.x86_64 file /usr/share/man/man1/lsmcli.1.gz conflicts between attempted installs of libstoragemgmt-1.6.2-9.el8.i686 and libstoragemgmt-1.8.1-2.el8.x86_64 file /usr/share/man/man1/lsmd.1.gz conflicts between attempted installs of libstoragemgmt-1.6.2-9.el8.i686 and libstoragemgmt-1.8.1-2.el8.x86_64 file /usr/share/man/man1/simc_lsmplugin.1.gz conflicts between attempted installs of libstoragemgmt-1.6.2-9.el8.i686 and libstoragemgmt-1.8.1-2.el8.x86_64 file /usr/share/man/man5/lsmd.conf.5.gz conflicts between attempted installs of libstoragemgmt-1.6.2-9.el8.i686 and libstoragemgmt-1.8.1-2.el8.x86_64 Error Summary ------------- [root@dell-per430-26 ~]# and also found with libstoragemgmt-1.8.3-1 log: (114/115): libstoragemgmt-1.8.3-1.el8.x86_64.rpm 9.7 MB/s | 283 kB 00:00 (115/115): rhnsd-5.0.35-3.module+el8+2599+aa6b86f9.x86_64.rpm 43 kB/s | 51 kB 00:01 ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ Total 1.9 MB/s | 51 MB 00:26 Running transaction check Transaction check succeeded. Running transaction test The downloaded packages were saved in cache until the next successful transaction. You can remove cached packages by executing 'dnf clean packages'. Error: Transaction test error: file /usr/lib/tmpfiles.d/libstoragemgmt.conf conflicts between attempted installs of libstoragemgmt-1.6.2-9.el8.i686 and libstoragemgmt-1.8.3-1.el8.x86_64 file /usr/share/doc/libstoragemgmt/NEWS conflicts between attempted installs of libstoragemgmt-1.6.2-9.el8.i686 and libstoragemgmt-1.8.3-1.el8.x86_64 file /usr/share/man/man1/lsmcli.1.gz conflicts between attempted installs of libstoragemgmt-1.6.2-9.el8.i686 and libstoragemgmt-1.8.3-1.el8.x86_64 file /usr/share/man/man1/lsmd.1.gz conflicts between attempted installs of libstoragemgmt-1.6.2-9.el8.i686 and libstoragemgmt-1.8.3-1.el8.x86_64 file /usr/share/man/man1/simc_lsmplugin.1.gz conflicts between attempted installs of libstoragemgmt-1.6.2-9.el8.i686 and libstoragemgmt-1.8.3-1.el8.x86_64 file /usr/share/man/man5/lsmd.conf.5.gz conflicts between attempted installs of libstoragemgmt-1.6.2-9.el8.i686 and libstoragemgmt-1.8.3-1.el8.x86_64 [root@hp-dl160g5-01 ~]# (113/114): libstoragemgmt-1.8.3-1.el8.x86_64.rpm 36 MB/s | 283 kB 00:00 (114/114): samba-client-libs-4.11.2-13.el8.x86_64.rpm 25 MB/s | 5.1 MB 00:00 ------------------------------------------------------------------------------------------------------------------------------------ Total 20 MB/s | 51 MB 00:02 Running transaction check Transaction check succeeded. Running transaction test The downloaded packages were saved in cache until the next successful transaction. You can remove cached packages by executing 'dnf clean packages'. Error: Transaction test error: file /usr/share/doc/libstoragemgmt/NEWS conflicts between attempted installs of libstoragemgmt-1.8.1-2.el8.i686 and libstoragemgmt-1.8.3-1.el8.x86_64 file /usr/share/man/man1/lsmcli.1.gz conflicts between attempted installs of libstoragemgmt-1.8.1-2.el8.i686 and libstoragemgmt-1.8.3-1.el8.x86_64 file /usr/share/man/man1/lsmd.1.gz conflicts between attempted installs of libstoragemgmt-1.8.1-2.el8.i686 and libstoragemgmt-1.8.3-1.el8.x86_64 file /usr/share/man/man1/simc_lsmplugin.1.gz conflicts between attempted installs of libstoragemgmt-1.8.1-2.el8.i686 and libstoragemgmt-1.8.3-1.el8.x86_64 file /usr/share/man/man5/lsmd.conf.5.gz conflicts between attempted installs of libstoragemgmt-1.8.1-2.el8.i686 and libstoragemgmt-1.8.3-1.el8.x86_64 [root@hp-dl160g5-01 ~]# this issue found with RHEL-8.1 (include 8.0repo and 8.1repo) ,RHEL-8.2(include 8.0repo and 8.2repo,8.1repo and 8.2repo) but when RHEL-8.1( only include 8.1repo) ,RHEL-8.2(only include 8.2repo) then 'dnf groupinstall base' can be executed successfully please have a look and check if my reproduction step is wrong Thanks Created attachment 1665584 [details]
reproduced with RHEL-8.1
Created attachment 1665585 [details]
reproduced with RHEL-8.2
(In reply to Jaroslav Mracek from comment #1) > The problem is in packaging of libstoragemgmt. > python3-libstoragemgmt-clibs.x86-64 requires `libstoragemgmt = 1.8.1-2.el8`, > but it should require `libstoragemgmt(x86-64) = 1.8.1-2.el8`. The following > patch for downstream spec will resolve it. > > diff --git a/libstoragemgmt.spec b/libstoragemgmt.spec > index 37dd22c..b15d35f 100644 > --- a/libstoragemgmt.spec > +++ b/libstoragemgmt.spec > @@ -70,7 +70,7 @@ support and open source plug-ins written in python 3. > %package -n python3-%{name}-clibs > Summary: Python 3 C extension module for %{name} > Group: System Environment/Libraries > -Requires: %{name} = %{version}-%{release} > +Requires: %{name}%{?_isa} = %{version}-%{release} > %{?python_provide:%python_provide python3-%{name}-clibs} > > %description -n python3-%{name}-clibs Jaroslav, I made the changes you suggested in this comment and 1 more as we have more than 1 python module with a clib, change I made is: diff --git a/libstoragemgmt.spec b/libstoragemgmt.spec index 37dd22c..74fdc20 100644 --- a/libstoragemgmt.spec +++ b/libstoragemgmt.spec @@ -2,7 +2,7 @@ Name: libstoragemgmt Version: 1.8.1 -Release: 3%{?dist} +Release: 4%{?dist} Summary: Storage array management library Group: System Environment/Libraries License: LGPLv2+ @@ -70,7 +70,7 @@ support and open source plug-ins written in python 3. %package -n python3-%{name}-clibs Summary: Python 3 C extension module for %{name} Group: System Environment/Libraries -Requires: %{name} = %{version}-%{release} +Requires: %{name}%{?_isa} = %{version}-%{release} %{?python_provide:%python_provide python3-%{name}-clibs} %description -n python3-%{name}-clibs @@ -178,7 +178,7 @@ The nfs-plugin package contains plug-in for local NFS exports support. %package nfs-plugin-clibs Summary: Python C extension module for %{name} NFS plugin Group: System Environment/Libraries -Requires: %{name} = %{version}-%{release} +Requires: %{name}%{?_isa} = %{version}-%{release} %description nfs-plugin-clibs The %{name}-nfs-plugin-clibs package contains python C extension for %{name} @@ -540,6 +540,9 @@ fi %{_mandir}/man1/local_lsmplugin.1* %changelog +* Thu Feb 13 2020 Tony Asleson <tasleson> - 1.8.1-4 +- Fix dnf groupinstall base (RHBZ #1792370) + * Wed Oct 30 2019 Tony Asleson <tasleson> - 1.8.1-3 - Correct rpm -V (RHBZ #1726209) which is included in 1.8.3-1. Do I make a mistake in this change for the dependency generation to work or is this still part of the bug that needs to be addressed with Bug #1782899 ? Thanks! Hello Tony Are there any new updates? do we have new version of lsm to fix this bug? Thanks (In reply to ChanghuiZhong from comment #8) > Hello Tony > > Are there any new updates? do we have new version of lsm to fix this bug? > > Thanks The issue is in NEEDINFO as I've believe I've done the requested spec file changes outlined in this issue and I'm waiting for a response. Bug #1782899 is addressing an issue relating to this too, thus it's correction may be needed in conjunction with this but not sure. It looks like a correct solution. The correct question would be whether the issue is still reproducible? No additional changes are required in DNF. The original issue is still opened because we are looking for solution that will tolerate packaging issues on DNF side, but it looks like that it is impossible. Please if I did not answered what you need, please don't hesitate to ask once again. Hi,all Thanks for the updated. But from the test results, libstoragemgmt-1.8.3-1 still can reproduce this issue. If it can be fixed, please re-publish new version, QE can verify again. Thanks The problem is in already release packages, but they cannot be removed from a distribution. python3-libstoragemgmt-clibs-0:1.6.2-9.el8.x86_64 python3-libstoragemgmt-clibs-0:1.8.1-2.el8.x86_64 The issue will disappear after upgrade of python3-libstoragemgmt-clibs into the latest version. Than the issue will be not present any more. I am sorry but I didn't touch anything. It was changed by reload. Nice feature of bugzilla. I would like to propose a different test conditions. Install python3-libstoragemgmt-clibs-0:1.8.1-3.el8.x86_64 and other related component from that build then try to reproduce the issue with 'dnf groupinstall base'. Hi,Jaroslav Mracek still can reproduce this issue with python3-libstoragemgmt-clibs-1.8.1-3.el8.x86_64 [root@dhcp-12-129 ~]# rpm -qa | grep libstoragemgmt python3-libstoragemgmt-1.8.1-3.el8.noarch libstoragemgmt-1.8.1-3.el8.x86_64 python3-libstoragemgmt-clibs-1.8.1-3.el8.x86_64 [root@dhcp-12-129 ~]# 'dnf groupinstall base' Total 618 kB/s | 74 MB 02:03 Running transaction check Transaction check succeeded. Running transaction test The downloaded packages were saved in cache until the next successful transaction. You can remove cached packages by executing 'dnf clean packages'. Error: Transaction test error: file /usr/share/doc/libstoragemgmt/NEWS conflicts between attempted installs of libstoragemgmt-1.8.1-3.el8.i686 and libstoragemgmt-1.8.3-1.el8.x86_64 file /usr/share/man/man1/lsmcli.1.gz conflicts between attempted installs of libstoragemgmt-1.8.1-3.el8.i686 and libstoragemgmt-1.8.3-1.el8.x86_64 file /usr/share/man/man1/lsmd.1.gz conflicts between attempted installs of libstoragemgmt-1.8.1-3.el8.i686 and libstoragemgmt-1.8.3-1.el8.x86_64 file /usr/share/man/man1/simc_lsmplugin.1.gz conflicts between attempted installs of libstoragemgmt-1.8.1-3.el8.i686 and libstoragemgmt-1.8.3-1.el8.x86_64 file /usr/share/man/man5/lsmd.conf.5.gz conflicts between attempted installs of libstoragemgmt-1.8.1-3.el8.i686 and libstoragemgmt-1.8.3-1.el8.x86_64 [root@dhcp-12-129 ~]# This issue only occurs when the OS has two different versions of the repo.(eg:'rhel8.1 and rhel8.2' ,even different versions of rhel8.2 repo) [beaker-BaseOS] name=beaker-BaseOS baseurl=http://download.eng.bos.redhat.com/rhel-8/rel-eng/RHEL-8/RHEL-8.2.0-20191219.0/compose/BaseOS/x86_64/os enabled=1 gpgcheck=0 skip_if_unavailable=1 [beaker-AppStream-8.2] name=beaker-AppStream-8.2 baseurl=http://download-node-02.eng.bos.redhat.com/rhel-8/rel-eng/RHEL-8/RHEL-8.2.0-20200310.0/compose/AppStream/x86_64/os/ enabled=1 gpgcheck=0 [beaker-BaseOS-8.2] name=beaker-BaseOS-8.2 baseurl=http://download-node-02.eng.bos.redhat.com/rhel-8/rel-eng/RHEL-8/RHEL-8.2.0-20200310.0/compose/BaseOS/x86_64/os/ enabled=1 gpgcheck=0 If only one repo exist, this issue will not occur. [beaker-BaseOS-8.2] name=beaker-BaseOS-8.2 baseurl=http://download-node-02.eng.bos.redhat.com/rhel-8/rel-eng/RHEL-8/RHEL-8.2.0-20200310.0/compose/BaseOS/x86_64/os/ enabled=1 gpgcheck=0 Hello,Tony https://errata.devel.redhat.com/advisory/47952 since today is the deadline to push errata,if we are not sure or cannot verified, https://bugzilla.redhat.com/show_bug.cgi?id=1741288 https://bugzilla.redhat.com/show_bug.cgi?id=1792370 we need remove this two bug from the errata do you have any good idea and suggestion? (In reply to ChanghuiZhong from comment #16) > Hello,Tony > > https://errata.devel.redhat.com/advisory/47952 > > since today is the deadline to push errata,if we are not sure or cannot > verified, > https://bugzilla.redhat.com/show_bug.cgi?id=1741288 > https://bugzilla.redhat.com/show_bug.cgi?id=1792370 > we need remove this two bug from the errata > > do you have any good idea and suggestion? As Jaroslav mentioned, this bug for dnf groupinstall base fixes this issue but it will only help releases that come after this release, thus we cannot demonstrate that bug corrects this issue at this time. (In reply to Tony Asleson from comment #17) > (In reply to ChanghuiZhong from comment #16) > > Hello,Tony > > > > https://errata.devel.redhat.com/advisory/47952 > > > > since today is the deadline to push errata,if we are not sure or cannot > > verified, > > https://bugzilla.redhat.com/show_bug.cgi?id=1741288 > > https://bugzilla.redhat.com/show_bug.cgi?id=1792370 > > we need remove this two bug from the errata > > > > do you have any good idea and suggestion? > > As Jaroslav mentioned, this bug for dnf groupinstall base fixes this issue > but it will only help releases that come after this release, thus we cannot > demonstrate that bug corrects this issue at this time. so how do we deal with this bug? can we move to "verified" first? because this issue does not occur under normal situation, this issue only occurs if there are different repos in the OS. and as you said this fix patch only help releases that come after this release. (In reply to Tony Asleson from comment #17) > (In reply to ChanghuiZhong from comment #16) > > Hello,Tony > > > > https://errata.devel.redhat.com/advisory/47952 > > > > since today is the deadline to push errata,if we are not sure or cannot > > verified, > > https://bugzilla.redhat.com/show_bug.cgi?id=1741288 > > https://bugzilla.redhat.com/show_bug.cgi?id=1792370 > > we need remove this two bug from the errata > > > > do you have any good idea and suggestion? > > As Jaroslav mentioned, this bug for dnf groupinstall base fixes this issue > but it will only help releases that come after this release, thus we cannot > demonstrate that bug corrects this issue at this time. so how do we deal with this bug? can we move to "verified" first? because this issue does not occur under normal situation, this issue only occurs if there are different repos in the OS. and as you said this fix patch only help releases that come after this release. (In reply to ChanghuiZhong from comment #19) > so how do we deal with this bug? > can we move to "verified" first? > because this issue does not occur under normal situation, this issue only > occurs if there are different repos in the OS. > and as you said this fix patch only help releases that come after this > release. If we require positive confirmation that it's corrected before we release a fix for it we will never be able to post a fix for it, thus it will be perpetually broken. In my opinion we should go forward with what we have as it's the only course of action to correct the problem. Furthermore, there is a mitigation available that allows users to get past this issue if they run into it. I believe our best course of action is to move forward with the issue. Confirm that libstoragemgmt-1.8.6-1.el8 has fixed this issue. [root@storageqe-24 ~]# rpm -qa | grep libstoragemgmt python3-libstoragemgmt-clibs-1.6.2-9.el8.x86_64 libstoragemgmt-1.6.2-9.el8.x86_64 python3-libstoragemgmt-1.6.2-9.el8.noarch [root@storageqe-24 ~]# dnf groupinstall base [root@storageqe-24 ~]# rpm -qa | grep libstoragemgmt python3-libstoragemgmt-1.8.6-1.el8.noarch python3-libstoragemgmt-clibs-1.8.6-1.el8.x86_64 libstoragemgmt-1.8.6-1.el8.x86_64 Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (libstoragemgmt bug fix and enhancement update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2021:1629 |
The problem is in packaging of libstoragemgmt. python3-libstoragemgmt-clibs.x86-64 requires `libstoragemgmt = 1.8.1-2.el8`, but it should require `libstoragemgmt(x86-64) = 1.8.1-2.el8`. The following patch for downstream spec will resolve it. diff --git a/libstoragemgmt.spec b/libstoragemgmt.spec index 37dd22c..b15d35f 100644 --- a/libstoragemgmt.spec +++ b/libstoragemgmt.spec @@ -70,7 +70,7 @@ support and open source plug-ins written in python 3. %package -n python3-%{name}-clibs Summary: Python 3 C extension module for %{name} Group: System Environment/Libraries -Requires: %{name} = %{version}-%{release} +Requires: %{name}%{?_isa} = %{version}-%{release} %{?python_provide:%python_provide python3-%{name}-clibs} %description -n python3-%{name}-clibs