Bug 567562
| Summary: | upgrade packages with i386 and x86_64 rpms fails in SSM | ||
|---|---|---|---|
| Product: | [Community] Spacewalk | Reporter: | Marco Giunta <giun7a> |
| Component: | WebUI | Assignee: | Jan Pazdziora (Red Hat) <jpazdziora> |
| Status: | CLOSED INSUFFICIENT_DATA | QA Contact: | Red Hat Satellite QA List <satqe-list> |
| Severity: | high | Docs Contact: | |
| Priority: | high | ||
| Version: | 0.8 | CC: | christoph.maser, cperry, ege.turgay, jpazdziora |
| 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: | 2011-09-30 13:50:21 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: | |||
| Bug Depends On: | |||
| Bug Blocks: | 723481 | ||
|
Description
Marco Giunta
2010-02-23 09:42:18 UTC
Sounds more like WebUI issue. I'm not sure whether is it the same problem or I have a misunderstanding however here is a similar situation in my end. I've removed all of the i386 packages from the servers, when I check one server from spacewalk for upgrading the packages, It seems to have the correct x86_64 packages. When I go to System Groups from the webUI and select all the servers which have only x86_64 packages and go to packages/upgrade existing packages, it shows two entries for each package as apr-1.2.7-11.el5_3.1 x86_64 apr-1.2.7-11.el5_3.1 i386 This doesn't happen if you go to an individual server and list packages that will be upgraded. If it happens to select all of these packages and upgrade, obviously most of the files get a conflict and fail. I've added a screenshot if that helps here http://imagebin.ca/view/AUva-xRf.html I have a problem wich might be related to that. Spacewalk tells me that alls Systems are up to date wich is not true. It seems that for updates which are available in 32bit and 64bit randomly one of two updates is installed. Example of an "up to date system" # yum check-update Loaded plugins: priorities, rhnplugin 6 packages excluded due to repository priority protections cyrus-sasl.x86_64 2.1.22-5.el5_4.3 centos5-x86_64-updates cyrus-sasl-lib.i386 2.1.22-5.el5_4.3 centos5-x86_64-updates cyrus-sasl-plain.i386 2.1.22-5.el5_4.3 centos5-x86_64-updates gnutls.x86_64 1.4.1-3.el5_4.8 centos5-x86_64-updates nspr.x86_64 4.8.4-1.el5_4 centos5-x86_64-updates nss.i386 3.12.6-1.el5.centos centos5-x86_64-updates openssl.x86_64 0.9.8e-12.el5_4.6 centos5-x86_64-updates Is it possible to change this issue's priority to a higher state, as it is not possible to update the packages in a group of system if one is going through the package update procedure instead of applying ERRATA on the systems which I believe Spacewalk's one of core features. Removing all of the i386 packages from the repo and reimporting them seems to have solved my issue. this spacewalk instance was upgraded from 0.7 to 0.8 which might had some leftovers from the previous database maybe. So now, i386 packages only appear for those systems that have i386 installed whereas it was showing there were i386 updates for those servers don't have any i386 packages installed. Bumping the severity and adding to sat531-triage. Will hopefully take a look at this soon. Today i tested CentOS 5.4 -> 5.5 upgrade via Spacewalk. The result was this: Client execution returned "Error while executing packages action: Transaction Check Error: file /etc/dbus-1/system.conf from install of dbus-1.1.2-14.el5.i386 conflicts with file from package dbus-1.1.2-12.el5_4.1.x86_64 file /usr/share/man/man5/nss_ldap.5.gz from install of nss_ldap-253-25.el5.x86_64 conflicts with file from package nss_ldap-253-22.el5_4.i386 file /usr/share/man/man5/pam_krb5.5.gz from install of pam_krb5-2.2.14-15.i386 conflicts with file from package pam_krb5-2.2.14-10.x86_64 file /usr/share/man/man8/pam_krb5.8.gz from install of pam_krb5-2.2.14-15.i386 conflicts with file from package pam_krb5-2.2.14-10.x86_64 file /etc/rc.d/init.d/haldaemon from install of hal-0.5.8.1-59.el5.i386 conflicts with file from package hal-0.5.8.1-52.el5.x86_64 file /usr/share/hal/fdi/information/10freedesktop/20-video-quirk-pm-el5-ibm.fdi from install of hal-0.5.8.1-59.el5.i386 conflicts with file from package hal-0.5.8.1-52.el5.x86_64 file /usr/share/hal/fdi/information/10freedesktop/20-video-quirk-pm-el5-lenovo.fdi from " (code -1) This also seems related to 32bit vs 64bit spacewalk issues. Mass-moving to space13. We did not have time for this one during Spacewalk 1.4 time frame. Mass moving to Spacewalk 1.5. We did not have time for this one during Spacewalk 1.4 time frame. Mass moving to Spacewalk 1.5. Aligning under space16. We did multiple changes in the area of package selection and deployment in recent Spacewalk versions. Is this issue still present in Spacewalk 1.5? Currently I don't use spacewalk so I can not give you any feedback I still use spacewalk with minimal i386 packages, I might be able to try this next week and give some feedback. (In reply to comment #13) > We did multiple changes in the area of package selection and deployment in > recent Spacewalk versions. > > Is this issue still present in Spacewalk 1.5? I'm still using Spacewalk 1.4, so I'm not able to give you any feedback ... Closing with INSUFFICIENT_DATA with the assumption that this issue was fixed (at least) in Spacewalk 1.5. Please reopen with reproducer if the problem persists. |