Bug 589027
Summary: | Unexpected packages are installed during update applied to a group | ||
---|---|---|---|
Product: | Red Hat Satellite 5 | Reporter: | Peter Bieringer <pb> |
Component: | Server | Assignee: | Milan Zázrivec <mzazrivec> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | Red Hat Satellite QA List <satqe-list> |
Severity: | high | Docs Contact: | |
Priority: | high | ||
Version: | 530 | CC: | cperry, tao, vgaikwad |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2010-07-14 06:16:44 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Peter Bieringer
2010-05-05 07:32:37 UTC
The problem is reproducable, here the scenario: System A: tzdata installed System B: tzdata & tzdata-java installed RHN Satellite: spacewalk-*-0.5.28-54 System A: # yum remove tzdata-java (remove leftover) # yum downgrade tzdata System B: # yum downgrade tzdata-java tzdata Satellite: Systems -> System Group -> Select Group containing both systems -> work with group -> Packages -> Upgrade existing packages -> Select tzdata (Amount of systems = 2) and tzdata-java (Amount of systems = 1) -> Upgrade selected packages -> Approve list: System A tzdata-2010i-1.el5-i386 System B tzdata-2010i-1.el5-i386 tzdata-java-2010i-1.el5-i386 -> Confirm Check up2date logs: System A: [Wed May 5 07:34:32 2010] up2date Updating package profile [Wed May 5 07:35:01 2010] up2date Adding packages to package profile: ['tzdata-2010f-10.el5'] [Wed May 5 07:35:01 2010] up2date Removing packages from package profile: ['tzdata-2010i-1.el5'] [Wed May 5 07:35:01 2010] up2date Updating package profile [Wed May 5 07:37:13 2010] up2date updateLoginInfo() login info [Wed May 5 07:37:13 2010] up2date logging into up2date server [Wed May 5 07:37:13 2010] up2date successfully retrieved authentication token from up2date server [Wed May 5 07:37:20 2010] up2date Adding packages to package profile: ['tzdata-java-2010i-1.el5', 'tzdata-2010i-1.el5'] <---!!!!!! WHY tzdata-java ALSO ???? [Wed May 5 07:37:20 2010] up2date Removing packages from package profile: [] [Wed May 5 07:37:20 2010] up2date Updating package profile [Wed May 5 07:37:21 2010] up2date Updating package profile System B: [Wed May 5 07:35:33 2010] up2date successfully retrieved authentication token from up2date server [Wed May 5 07:36:02 2010] up2date Adding packages to package profile: ['tzdata-2010f-10.el5', 'tzdata-java-2010f-10.el5'] [Wed May 5 07:36:02 2010] up2date Removing packages from package profile: ['tzdata-2010i-1.el5', 'tzdata-java-2010i-1.el5'] [Wed May 5 07:36:02 2010] up2date Updating package profile [Wed May 5 07:37:13 2010] up2date updateLoginInfo() login info [Wed May 5 07:37:13 2010] up2date logging into up2date server [Wed May 5 07:37:13 2010] up2date successfully retrieved authentication token from up2date server [Wed May 5 07:37:19 2010] up2date Adding packages to package profile: ['tzdata-2010i-1.el5', 'tzdata-java-2010i-1.el5'] [Wed May 5 07:37:19 2010] up2date Removing packages from package profile: [] [Wed May 5 07:37:19 2010] up2date Updating package profile [Wed May 5 07:37:20 2010] up2date Updating package profile Here's the debug log of up2date from System A, looks like the XML action file is not created properly for this system or the update mechanism of the client is without condition, whether the package is already installed or not. [Wed May 5 07:47:40 2010] up2date D: check_action {'action': "<?xml version='1.0'?>\n<methodCall>\n<methodName>packages.update</methodName>\n<params>\n<param>\n<value><array><data>\n<value><array><data>\n<value><string>tzdat} [Wed May 5 07:47:40 2010] up2date updateLoginInfo() login info [Wed May 5 07:47:40 2010] up2date D: login(forceUpdate=True) invoked [Wed May 5 07:47:40 2010] up2date logging into up2date server [Wed May 5 07:47:40 2010] up2date D: writeCachedLogin() invoked [Wed May 5 07:47:40 2010] up2date D: Wrote pickled loginInfo at 1273045660.99 with expiration of 1273049260.99 seconds. [Wed May 5 07:47:40 2010] up2date successfully retrieved authentication token from up2date server [Wed May 5 07:47:40 2010] up2date D: logininfo: {'X-RHN-Server-Id': 1000010023, 'X-RHN-Auth-Server-Time': '1273045660.99', 'X-RHN-Auth': '***', 'X-RHN-Auth-Channels': [['rhel-i386-server-5', '20100504131} [Wed May 5 07:47:40 2010] up2date D: handle_action {'action': "<?xml version='1.0'?>\n<methodCall>\n<methodName>packages.update</methodName>\n<params>\n<param>\n<value><array><data>\n<value><array><data>\n<value><string>tzda} [Wed May 5 07:47:40 2010] up2date D: handle_action actionid = 15441, version = 2 [Wed May 5 07:47:40 2010] up2date D: do_call packages.update ([['tzdata', '2010i', '1.el5', '', 'i386'], ['tzdata-java', '2010i', '1.el5', '', 'i386']],) [Wed May 5 07:47:41 2010] up2date D: Called update [['tzdata', '2010i', '1.el5', '', 'i386'], ['tzdata-java', '2010i', '1.el5', '', 'i386']] [Wed May 5 07:47:43 2010] up2date D: Dependencies Resolved [Wed May 5 07:47:43 2010] up2date D: Downloading Packages: [Wed May 5 07:47:44 2010] up2date D: Running Transaction Test [Wed May 5 07:47:44 2010] up2date D: Finished Transaction Test [Wed May 5 07:47:44 2010] up2date D: Transaction Test Succeeded [Wed May 5 07:47:44 2010] up2date D: Running Transaction [Wed May 5 07:47:45 2010] up2date Adding packages to package profile: ['tzdata-java-2010i-1.el5', 'tzdata-2010i-1.el5'] [Wed May 5 07:47:45 2010] up2date Removing packages from package profile: [] [Wed May 5 07:47:45 2010] up2date Updating package profile [Wed May 5 07:47:46 2010] up2date D: Sending back response (0, 'Update Succeeded', {}) [Wed May 5 07:47:47 2010] up2date D: do_call packages.checkNeedUpdate ('rhnsd=1',) [Wed May 5 07:47:47 2010] up2date D: Called refresh_rpmlist [Wed May 5 07:47:47 2010] up2date Updating package profile [Wed May 5 07:47:47 2010] up2date D: local action status: (0, 'rpmlist refreshed', {}) Just as a side note, this issue is independend of used client side software, it rises at least up using the RHEL 5.5 default RHN client tools and the ones from Spacewalk 0.8. Hi Peter Bieringer Could you please open a support ticket to associate and track next to this bug report. This will allow for Red Hat support to triage, confirm replication and help Engineering - sometimes providing a fix before we even start looking at the bug report. Regards, Cliff. Case was already opened after writing bz entry: Case# 2018786 I cannot reproduce the problem according to the scenario provided in comment #0 and comment #1. With latest Satellite 5.3.0, two RHEL 5.5 clients registered, the scenario with tzdata & tzdata-java works as expected. The only way I can achieve the results customer is reporting is when I do: 1. I have both tzdata, tzdata-java installed 2. downgrade tzdata 3. rpm -e tzdata-java - it is important to use rpm -e rather than yum remove: removing the package using rpm -e (unlike yum remove) won't update package profile on the server. 4. Schedule update on the server (although here server would see that both tzdata & tzdata-java need to be updated) 5. After the update is over, I can see updated tzdata-java is back It might be that the client systems in question do not have the package profile synced properly (rhn-profile-sync helps in these situations). Nonetheless, I'm unable to reproduce the problem. If anyone else is able to reproduce it (as comment #6 suggests), I'll certainly appreciate the input on it. Thanks Just note that I can't reproduce this anymore, too, testing with kernel/kernel-headers/kernel-devel and tzdata/tzdata-java Can it be that this issue was silently fixed in the 0.5.28-55 release, installed May 27 on my system? (In reply to comment #9) > Just note that I can't reproduce this anymore, too, testing with > kernel/kernel-headers/kernel-devel and tzdata/tzdata-java > > Can it be that this issue was silently fixed in the 0.5.28-55 release, > installed May 27 on my system? I've checked the changes in the code between those two versions and I found nothing obvious that could be causing the reported problem to go away. Nonetheless, the backend version I've been using for reproducing the problem is 0.5.28-55 as well. Closing based on previous comments. |