Description of problem: I've a Spacewalk server 0.8 stable installed on CentOS 5.4 i386, with over 200 workstations CentOS 5.3-5.4 i386 and x86_64. I'd like to upgrade packages with SSM, but: - if I try to upgrade a package with both i386 and x86_64 rpms in one or more workstations CentOS x86_64 with SSM, it upgrades only the FIRST rpm (x86_64 or i386) - if I try to upgrade two packages, it upgrades only the FIRST rpm of the first packages and the SECOND rpm (i386 or x86_64) of the second packages - if I try to upgrade three packages, it upgrades only the FIRST rpm of the first package, the SECOND rpm (i386 or x86_64) of the second package and the SECOND rpm (i386 or x86_64) of the third package - if I try to upgrade four packages, it upgrades only the FIRST rpm of the first package, the SECOND rpm (i386 or x86_64) of the second package, the SECOND rpm (i386 or x86_64) of the third package and the SECOND rpm (i386 or x86_64) of the fourth package - if I try to upgrade five packages, the behavior is the same, the SECOND rpm (i386 or x86_64) of the fifth package, on so on ... Of course, upgrade fails. If I try to upgrade the same packages on the same workstation, without SSM, it works Version-Release number of selected component (if applicable): 0.8 stable How reproducible: 100% Steps to Reproduce: 1. Select one or more out-of-date CentOS x86_64 workstations and press Manage 2. in SSM choose Upgrade 3. select one or more packages with i386 and x86_64 rpms (for example xmlrunner or whatever else) 4. Press Update Selected Packages Actual results: upgrade fails Expected results: upgrade works Additional info: I 've the same problem on 0.7 stable
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.
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.