[Spacewalk-list] Possible BUG: Requested packages have already been installed on CentOS 5 clients

Jan Hutař jhutar at redhat.com
Wed Jan 27 06:39:52 UTC 2016


Thank you,
I have reported this BZ:

  Bug 1302198 - remote package upgrade saying newer package is installed, but it is not
  https://bugzilla.redhat.com/show_bug.cgi?id=1302198

Please as a workaround use remote command with something like
`yum -y upgrade openssl-0.9.8e-37.el5_11` which should work for now.

Thank you again,
Jan



On Tue, 26 Jan 2016 21:59:18 +0000 "Coffman, Anthony J"
<Tony.Coffman at snapon.com> wrote:

> Here is the output for the manual compare and the rhn_check
> --vv run with the additional output included.
> https://paste.fedoraproject.org/315076/
> 
> Here is the output for the rpm queries.
> https://paste.fedoraproject.org/315080/
> 
> Regards,
> --Tony
> 
> 
> -----Original Message-----
> From: Jan Hutař [mailto:jhutar at redhat.com] 
> Sent: Tuesday, January 26, 2016 4:10 PM
> To: Coffman, Anthony J <Tony.Coffman at snapon.com>
> Cc: spacewalk-list at redhat.com
> Subject: Re: [Spacewalk-list] Possible BUG: Requested packages
> have already been installed on CentOS 5 clients
> 
> Thank you.
> 
> So far i have found something strange, but looks like only you
> are hitting the issue. Could you please try this (on the
> client which is failing to install the packages):
> 
> # python
> Python 2.4.3 (#1, Oct 23 2012, 22:02:41) [GCC 4.1.2 20080704
> (Red Hat 4.1.2-54)] on linux2 Type "help", "copyright",
> "credits" or "license" for more information.
> >>> import yum.packages
> >>> current = yum.packages.PackageEVR(None, '0.9.8e',
> >>> '36.0.1.el5_11') new = yum.packages.PackageEVR(None,
> >>> '0.9.8e', '37.el5_11') current.compare(new)
> -1
> >>> new = yum.packages.PackageEVR('', '0.9.8e', '37.el5_11')
> >>> current.compare(new)
> 1
> 
> This is output I got on system with:
> 
> # rpm -q yum-rhn-plugin rpm rpm-python yum
> yum-rhn-plugin-0.5.4.1-7.el5
> rpm-4.4.2.3-36.el5_11
> rpm-python-4.4.2.3-36.el5_11
> yum-3.2.22-40.el5
> 
> (I know you have different yum-rhn-plugin version, but maybe
> that is not important in this case)
> 
> After that, please add these 4 lines which will provide more
> output to the /usr/share/rhn/actions/packages.py file after
> row 346:
> 
> --- usr/share/rhn/actions/packages.py.ORIG	2016-01-26
> 22:01:10.002192351 +0100 +++
> usr/share/rhn/actions/packages.py	2016-01-26
> 22:04:56.623616475 +0100 @@ -344,6 +344,10 @@ 
>          found = False
>          for pkg in pkgs:
> +            current = pkg.returnEVR()
> +            print "Current:", current.epoch, current.version,
> current.release
> +            print "Candidate:", evr.epoch, evr.version,
> evr.release
> +            print "Comparasion:", current.compare(evr)
>              if pkg.returnEVR().compare(evr) == 0:
>                  log.log_debug('Package %s already installed' \
>                      % _yum_package_tup(package))
> 
> and regenerate `rhn_check -vv` output. Note I have not tried
> this, so I'm not 100% sure it will work, so backup the file
> first please.
> 
> And one more thing to be sure packages are OK:
> 
> rpm -qp --qf="%{EPOCH}:%{VERSION}-%{RELEASE}.%{ARCH}"
> openssl-0.9.8e-37.el5_11.i686.rpm rpm -qp --qf="%{EPOCH}:%
> {VERSION}-%{RELEASE}.%{ARCH}"
> openssl-0.9.8e-36.0.1.el5_11.i686.rpm
> 
> or if you have them installed:
> 
> rpm -q --qf="%{EPOCH}:%{VERSION}-%{RELEASE}.%{ARCH}"
> openssl-0.9.8e-37.el5_11.i686 rpm -q --qf="%{EPOCH}:%
> {VERSION}-%{RELEASE}.%{ARCH}" openssl-0.9.8e-36.0.1.el5_11.i686
> 
> Regards,
> Jan
> 
> 
> 
> On Tue, 26 Jan 2016 17:18:44 +0000 "Coffman, Anthony J"
> <Tony.Coffman at snapon.com> wrote:
> 
> > Thanks for having a look.
> > 
> > I should have also mentioned that a yum install or yum
> > update does successfully install the same package(s) (from
> > the same Spacewalk repos)
> > 
> > Here's the rhn -vv output during an attempted update of
> > openssl.
> > 
> > https://paste.fedoraproject.org/314962/
> > 
> > Here't the package list (rpm -qa | sort)
> > 
> > https://paste.fedoraproject.org/314963/
> > 
> > It does this if I try to update any package or groups of
> > packages via scheduled action.
> > 
> > Regards,
> > --Tony
> > 
> > 
> > 
> > -----Original Message-----
> > From: Jan Hutař [mailto:jhutar at redhat.com]
> > Sent: Monday, January 25, 2016 2:47 PM
> > To: spacewalk-list at redhat.com
> > Cc: Coffman, Anthony J <Tony.Coffman at snapon.com>
> > Subject: Re: [Spacewalk-list] Possible BUG: Requested
> > packages have already been installed on CentOS 5 clients
> > 
> > On Mon, 18 Jan 2016 15:14:54 +0000 "Coffman, Anthony J"
> > <Tony.Coffman at snapon.com> wrote:
> > 
> > > I ran into this one yesterday unexpectedly.
> > > 
> > > It seems there may be a bug in the SW 2.4 client that
> > > seems to only affect EL5 clients.  I tested this on CentOS
> > > 5 i386 but not on x86_64 yet.  I haven't seen it on EL6,
> > > EL7, or SuSE.
> > > 
> > > When you scheduled a package install/update action, you
> > > get this back
> > > 
> > > Client execution returned "Requested packages already
> > > installed" (code
> > > 0)
> > > 
> > > The 0 return code makes it look successful but no package
> > > changes are made.   Because of the change to spread out
> > > errata cache processing over time you can easily be fooled
> > > into thinking that you have successfully applied updates
> > > when in reality nothing was actually applied.
> > > 
> > > The requested packages are not actually already installed.
> > > 
> > > I rolled one test system back to the 2.3 client manually
> > > and it does fix the issue.
> > > 
> > > Has anybody else run into this problem?
> > > 
> > > --Tony
> > 
> > As a first step, could you please run rhn_check on the
> > client with "-vv" option and sent the full output? Also `rpm
> > -qa | sort` might be handy.
> > 
> > Regards,
> > Jan
> > 
> > 
> > 
> > -- 
> > Jan Hutar     Systems Management QA
> > jhutar at redhat.com     Red Hat, Inc.
> 
> 
> -- 
> Jan Hutar     Systems Management QA
> jhutar at redhat.com     Red Hat, Inc.


-- 
Jan Hutar     Systems Management QA
jhutar at redhat.com     Red Hat, Inc.




More information about the Spacewalk-list mailing list