Bug 727828 - rhn_check fails when applying errata for an installed package
Summary: rhn_check fails when applying errata for an installed package
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Spacewalk
Classification: Community
Component: Clients
Version: 1.6
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Jan Pazdziora
QA Contact: Red Hat Satellite QA List
URL:
Whiteboard:
Depends On:
Blocks: space16
TreeView+ depends on / blocked
 
Reported: 2011-08-03 10:58 UTC by Jiří Mikulka
Modified: 2014-10-06 13:46 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-12-22 16:49:12 UTC


Attachments (Terms of Use)

Description Jiří Mikulka 2011-08-03 10:58:50 UTC
Description of problem:
rhn_check failes when applying errata for an installed package.

Version-Release number of selected component (if applicable):
server/client: Fedora 14 x86_64
rhn_check: rhn-check-1.6.3-1.fc14.noarch

How reproducible:
always 

Steps to Reproduce:
1. create new channel in Spacewalk
2. register new client to this new channel
3. build few versions of one package
4. install lowest version of the package
4. create errata for this package
5. apply errata by rhn_check -> fails
  
Actual results:
The old version of the package is removed but the new version is not installed (there is no version of the package on the system).
rhn_check returns:
D: Sending back response ((6,), 'Error while executing packages action: empty transaction', {})

Expected results:
After applying errata the old version of the package is removed and replaced by the new version package specified in errata.

Additional info:
D: check_action {'action': "<?xml version='1.0'?>\n<methodCall>\n<methodName>errata.update</methodName>\n<params>\n<param>\n<value><array><data>\n<value><int>424</int></value>\n</data></array></value>\n</param>\n</params>\n</methodCall>\n", 'version': 2, 'id': 826}
updateLoginInfo() login info
D: login(forceUpdate=True) invoked
logging into up2date server
D: rpcServer: Calling XMLRPC up2date.login
D: writeCachedLogin() invoked
D: Wrote pickled loginInfo at  1312365959.38  with expiration of  1312369559.38  seconds.
successfully retrieved authentication token from up2date server
D: logininfo: {'X-RHN-Server-Id': 1000010152, 'X-RHN-Auth-Server-Time': '1312365959.37', 'X-RHN-Auth': 'c5Mhz1iWEYJXyjY8ca75Dg==', 'X-RHN-Auth-Channels': [['test-x86_64-0', '20110803060229', '1', '1']], 'X-RHN-Auth-User-Id': '', 'X-RHN-Auth-Expire-Offset': '3600.0'}
D: handle_action {'action': "<?xml version='1.0'?>\n<methodCall>\n<methodName>errata.update</methodName>\n<params>\n<param>\n<value><array><data>\n<value><int>424</int></value>\n</data></array></value>\n</param>\n</params>\n</methodCall>\n", 'version': 2, 'id': 826}
D: handle_action actionid = 826, version = 2
D: do_call errata.update ([424],) {'cache_only': None}
Zavedeny zásuvné moduly: langpacks, presto, refresh-packagekit, rhnplugin
Adding cs_CZ to language list
D: rpcServer: Calling XMLRPC errata.getErrataInfo
D: Called update [['foo', '0.3', '3', '', 'x86_64']]
D: Sending back response ((6,), 'Error while executing packages action: empty transaction', {})
D: do_call packages.checkNeedUpdate ('rhnsd=1',) {}
D: local action status:  (0, 'rpm database not modified since last update (or package list recently updated)', {})
D: rpcServer: Calling XMLRPC registration.welcome_message

Comment 2 Šimon Lukašík 2011-08-03 14:44:33 UTC
This is a regression against Spacewalk nightly from 2011-07-31.

Comment 3 Jan Pazdziora 2011-08-04 14:18:24 UTC
The empty transaction error reporting was introduced by commit 15e1dca13350ae3e9a0eb8fbf52287db1d59ddd3, for bug 666545.

Comment 4 Šimon Lukašík 2011-08-04 15:29:17 UTC
The empty transaction-error-check is correct. In fact, it revealed the
underlying problem that the transaction was empty.

Even when you revert 15e1dca13350ae3e9a0eb8fbf52287db1d59ddd3 locally,
the package from the erratum won't get installed (!)

The cause of problem lies between: 6f6d7fa3dba02...301b5e92d84c1

Comment 5 Jiří Mikulka 2011-08-08 07:44:38 UTC
I tried this again with today's (2011-08-07) Spacewalk nightly and it
appears to be fixed. Feel free to close.

Comment 6 Jan Pazdziora 2011-08-08 08:08:53 UTC
Moving ON_QA, thanks.

Comment 7 Yury V. Zaytsev 2011-08-24 08:05:04 UTC
Hi!

I am getting exactly this message:

Error while executing packages action: empty transaction [[6]]

in RHN / RHEL 6. Is your update going to fix this problem or I shall open another bug / support ticket?

Thanks!

Comment 8 Jan Pazdziora 2011-08-28 21:37:54 UTC
(In reply to comment #7)
> Hi!
> 
> I am getting exactly this message:
> 
> Error while executing packages action: empty transaction [[6]]
> 
> in RHN / RHEL 6. Is your update going to fix this problem or I shall open
> another bug / support ticket?
> 
> Thanks!

What does

# rpm -qa | grep rhn | sort

return on your system?

Comment 9 Yury V. Zaytsev 2011-08-28 21:51:15 UTC
Hi!

(In reply to comment #8)
> 
> What does
> 
> # rpm -qa | grep rhn | sort
> 
> return on your system?

[zaytsev@puppet ~]$ rpm -qa | grep rhn | sort
rhn-check-1.0.0-61.el6.noarch
rhn-client-tools-1.0.0-61.el6.noarch
rhnlib-2.5.22-10.el6.noarch
rhnsd-4.9.3-2.el6.x86_64
rhn-setup-1.0.0-61.el6.noarch
rhn-virtualization-common-5.4.14-4.el6sat.noarch
rhn-virtualization-host-5.4.14-4.el6sat.noarch
yum-rhn-plugin-0.9.1-26.el6_1.1.noarch

FYI, I have opened a support Case 00522843 with the connection to this problem, which is yet unresolved.

Thanks!

Comment 10 Jan Pazdziora 2011-08-28 22:12:15 UTC
(In reply to comment #9)
> 
> [zaytsev@puppet ~]$ rpm -qa | grep rhn | sort
> rhn-check-1.0.0-61.el6.noarch
> rhn-client-tools-1.0.0-61.el6.noarch
> rhnlib-2.5.22-10.el6.noarch
> rhnsd-4.9.3-2.el6.x86_64
> rhn-setup-1.0.0-61.el6.noarch
> rhn-virtualization-common-5.4.14-4.el6sat.noarch
> rhn-virtualization-host-5.4.14-4.el6sat.noarch
> yum-rhn-plugin-0.9.1-26.el6_1.1.noarch

Thanks. That means that you use RHEL packages, not Spacewalk nightly packages. So any fixes noted here (Spacewalk the upstream project) have no direct/automatic relation to packages/fixes in RHEL.

> FYI, I have opened a support Case 00522843 with the connection to this problem,
> which is yet unresolved.

Thanks you, that was the correct way to do.

Comment 11 dave 2011-08-31 15:36:19 UTC
I am experiencing the same issues with RHEL packages. I also have a support case opened: 00524328.

I have found that if I add the verbose option to the rhn_check command, it updates the packages with no "empty transaction" message. The only rhn update I can find in the recent history is RHBA-2011:1198-1, however I think it's a bit early to make the conclusion that it was this update that hosed my servers up.


On second thought, that update was applied on 2011Aug29, the very next update failed, and continued to fail until I added the triple verbose option. rhn_check -vvv.


I do not believe this to be a result of nightly spacewalk builds, but the yum-rhn-plugin bug fix.

Thanks,
Dave

Comment 12 Yury V. Zaytsev 2011-08-31 15:50:44 UTC
FYI, I have followed the advice of the support representative:

> [*] Clean the yum cache
> 
> ----------------------------------
> # yum clean all
> ----------------------------------
> 
> [*] Re-create the cache for yum
> 
> ----------------------------------
> # yum makecache
> ----------------------------------
> 
> [*] Sync the profile with RHN which will provide the package update information of the system to RHN
> 
> ----------------------------------
> # rhn-profile-sync
> ----------------------------------
> 
> [*] Disable and Re-enable the Auto-Errata Update from RHN system profile.

and when I re-scheduled the updates, they were properly picked up.

There were no other updates since then, so I can't tell whether it's gone for good or not, but at least, it helped temporarily to a certain extent.

Comment 13 dave 2011-09-01 13:05:03 UTC
Just FYI - RH Support was able to reproduce this issue in their test environment against both RHN Hosted and Satellite. The issue appears to be with the latest yum-rhn-plugin at the client end.


My ticket is still opened and I will update this bug as I have updates.

Comment 14 Yury V. Zaytsev 2011-09-01 13:12:00 UTC
My ticket is still open as well, but I was told they were not able to reproduce it so far. Glad there is some progress on this issue! Please keep me posted.

Yet, does this actually have to do with this bug, or it belongs somewhere else?

Comment 15 Jan Pazdziora 2011-09-01 13:29:33 UTC
(In reply to comment #14)
> 
> Yet, does this actually have to do with this bug, or it belongs somewhere else?

There is no link between this Spacewalk bugzilla and any fix for software in RHEL.

Comment 16 dave 2011-09-01 13:36:45 UTC
From my open support case:

 Humbe, Ashish
 Hello,Thanks for the update, As per the details that you have provided I am able to reproduce this issue against RHN hosted as well as against RHN satellite. The issue is at client end with the latest yum-rhn-plugin package. We will investigate more on this mean time as a workaround you can use rhn_check -vvv . Will keep you posted with further updates. Thanks & Regards,Ashish Humbe. 

8/31/2011 
7:19 PM EDT Comment ID: a0aA0000005eanQIAQ  Humbe, Ashish
 Hi Dave,Thanks for sharing your observations,I am testing this issue with latest yum-rhn-plugin on my test system, i will keep you posted. Thanks & Regards,Ashish Humbe.

Comment 17 Christopher Hill 2011-09-19 15:48:02 UTC
I am getting the error 'Error while executing packages action: empty
transaction' on a system which has Auto Apply Errata Updates set on RHN, even with yum-rhn-plugin 0.5.4-22.el5_7.2 installed (released 12/9/11).

Is this related?

Comment 18 Yury V. Zaytsev 2011-09-19 16:10:22 UTC
I was told by a support representative that the problem on RHEL 5 should be fixed by the update that you mentioned, which is tied to the bug #736058, which I can not access:

https://rhn.redhat.com/errata/RHBA-2011-1281.html

The solution for RHEL 6 is pending. As bug #736058 can't be reopened please file a support ticket with RH.

Comment 19 Christopher Hill 2011-09-22 09:41:08 UTC
Left it a few more days, and the problem seems to have resolved itself now.

Comment 20 Yury V. Zaytsev 2011-09-22 09:47:41 UTC
For me it happens spontaneously, that is the updates fail to apply randomly, and sometimes when I reschedule the same updates, they get applied...

Comment 21 Hugh Pearse 2011-10-21 09:26:22 UTC
bump, this bug has not yet been fixed

Comment 22 Yury V. Zaytsev 2011-10-21 09:32:46 UTC
(In reply to comment #21)
> bump, this bug has not yet been fixed

Please open the support request with RH.

My support rep. claims that he can not reproduce it on his systems (it's been 2 months already), but there seems to be a workaround of downgrading to an earlier version of yum-rhn-plugin, which applies the updates correctly but has a problem with creating bogus empty folders (which I can survive)...

Comment 23 Hugh Pearse 2011-10-21 09:46:32 UTC
I tried downgrading to the previous version and it did not work:

yum downgrade yum-rhn-plugin-1.4.15-1.fc14.noarch.rpm
yum clean all
rm -rf /var/cache/yum/*
yum makecache
rhn-profile-sync
rhn_check -vvvv

output:
D: Dependencies Resolved
D: Downloading Packages:
D: Sending back response ((6,), 'Error while executing packages action: Error Downloading Packages:\n  aalib-libs-1.4.0-0.19.rc5.fc15.x86_64: failure: aalib-libs-1.4.0-0.19.rc5.fc15.x86_64.rpm from fedora: [Errno 256] No more mirrors to try.\n  gpm-libs-1.20.6-16.fc15.x86_64: failure: gpm-libs-1.20.6-16.fc15.x86_64.rpm from fedora: [Errno 256] No more mirrors to try.\n', {})

Comment 24 Yury V. Zaytsev 2011-10-21 11:49:59 UTC
That's not the right version. What worked for me was:

yum downgrade yum-rhn-plugin-0.9.1-7.el6.noarch

(you should of course versionlock yum-rhn-plugin as well)

Also, your message is quite different and obviously you are using Fedora, so this discussion was completely irrelevant to your case.

Comment 25 Jan Pazdziora 2011-10-21 12:10:35 UTC
(In reply to comment #24)
> 
> Also, your message is quite different and obviously you are using Fedora, so
> this discussion was completely irrelevant to your case.

It is not really relevant because the "No more mirrors to try." shows some sort of network problem.

However, the fact that it's being reproduced on Fedora 14 is completely fine and valid. This report is a report for a problem in Spacewalk client packages on Fedora 14. We consider the problem to be addressed in Spacewalk nightly yum repositories and the Spacewalk 1.6 release will contain fixed packages.

If you are using RHEL and you are using stock RHEL client packages, this bugzilla is *not* a place to request a resolution, and continuing discussion here just confuses people (including some commenters) and sets expectations wrong. The fix which will be part of Spacewalk 1.6 will not automatically be part of any RHEL (sub)release or errata.

Comment 26 Yury V. Zaytsev 2011-10-21 12:18:33 UTC
(In reply to comment #25)
> (In reply to comment #24)
> > 
> > Also, your message is quite different and obviously you are using Fedora, so
> > this discussion was completely irrelevant to your case.
> 
> It is not really relevant because the "No more mirrors to try." shows some sort
> of network problem.

This is what I was alluding to.

> If you are using RHEL and you are using stock RHEL client packages, this
> bugzilla is *not* a place to request a resolution, and continuing discussion
> here just confuses people (including some commenters) and sets expectations
> wrong. The fix which will be part of Spacewalk 1.6 will not automatically be
> part of any RHEL (sub)release or errata.

Is it possible to install this fixed version of yum-rhn-plugin from Spacewalk 1.6 on RHEL6 instead of the faulty default yum-rhn-plugin?

Comment 27 Milan Zázrivec 2011-12-22 16:49:12 UTC
Spacewalk 1.6 has been released.


Note You need to log in before you can comment on or make changes to this bug.