Red Hat Bugzilla – Bug 456532
Systems: Profiles do not utilize package architecture
Last modified: 2010-12-16 11:43:06 EST
Description of problem:
Systems -> Stored Profile -> Packages & System -> Software -> Profile
Package profiles do not include the package architecture information. As a
result, if an i386 package is removed from an x86_64 client and the users
performs a profile comparison, they will see that the package is missing;
however, performing a sync from the profile to reinstall it on the client
results in the x86_64 package being installed. (Note: package arch information
is not received from the server during rhn_check)
From initial analysis, impacts to schema and UI are anticipated.
Steps to Reproduce:
1. select Systems
2. select an x86_64 system
3. select Software -> Packages -> Profiles
4. Create System Profile
5. remove an i386 package (e.g. libjpeg) from the client -> (Note: you might
want to install one before creating the profile above)
6. select System -> Software -> Packages -> Profile -> Compare to compare the
profile previously created to the system
7. you should see the package that was removed as a "difference" between the
profile and the system... select the package and perform "Sync Packages"
8. on the client, perform rhn_check -vvv at the appropriate time to have the
package re-installed on the client
- The profile that gets created (in 4) and then the comparison (in 6) do not
account for package architecture. It is neither stored in the DB nor displayed
to the user.
- The package that is resynced to the client (in 8) will be the x86_64 version
of the package (assuming that both an i386 & x86_64 exist) vs the i386 version
that was previously installed
- When creating a profile, we should have the ability to store the architecture
of the packages that are associated with the system; otherwise, we are not
accurately reflecting the differences when comparing profiles.
- When performing the profile comparisons, we should display to the user details
on the architecture so that they can see if there is such a difference that exists.
https://fedorahosted.org/spacewalk/wiki/MultiArchEnhancements - Refer to wiki
page for more details on this issue. This page contains proposed solution;
however, since the solution details can change as the issue is further
investigated, it is not being included in the bug report.
Modifications made to system stored profiles to support arch. This included changes such as the following:
- ported the following pages to java:
- added package_arch_id to rhnServerProfilePackage
- profile creation (systems/details/packages/profiles/Create.do) updated to
- profile comparisons (systems/details/packages/profiles/CompareProfiles.do &
systems/details/packages/profiles/CompareSystems.do) updated to include arch
in comparison and show in comparison results
- syncing (rhn/systems/details/packages/profiles/SyncSystems.do &
systems/details/packages/profiles/SyncProfiles.do) updated to include arch id
in the action that is scheduled and then picked up by rhn_check
- Systems -> Stored Profiles (profiles/List.do) new java pg replacing list.pxt
- Systems -> Stored Profiles -> Profile (profiles/Details.do) new java pg
- Systems -> Stored Profiles -> Profile -> Packages (profiles/PackageList.do)
new java page to replace package-list.pxt. The new page includes listing of
- Systems ->Stored Profiles -> Profile -> Delete Profile (profiles/Delete.do)
new java page to replace delete.pxt
Git commits related to this bz include:
verified with spacewalk-java-0.4.14-1.el5, spacewalk-schema-0.4.15-1.el5
verified Systems->StoredProfile - content looks good
verified System->Software->Profiles->Compare profile w/no diff expected
verified System->Software->Profiles->Compare profile w/ diff expected
verified System->Software->Profiles->Compare profile-> Sync Pkgs
verified System->Software->Profiles->Compare systems w/diff expected
verified System->Software->Profiles->Compare systems-> Sync Pkgs
attempting to delete the Stored Profile is generating an ISE. This BZ will be moved to verified and a separate BZ (480233) has been created to track this failure. Using this approach, since this BZ (456532) addressed many issues related to stored profiles.
It seems that the architecture information in stored profiles is only avaliable for stored profiles taken on EL5 clients or newer, but not on EL4 clients?
1. registering a el4.7 (in my case) desktop client to spacewalk and putting it into el4.7 base channel.
2. creating a stored profile (system -> software -> packages -> profiles -> create profile) like "profile basic"
3. installing some additional packages
4. creating a stored profile again like "profile additional packages"
5. synching the client to the basic profile works fine, cause the rhn_check on the client has only to remove packages.
6. But then! synching the system to "profile additional" will fail after the click on "schedule" button because the stored profile has no architecture information - so in the column "channel" there is "none". I understand it like the package e.g. "gedit.i386" is in the channel 4.7 i386, but the package "gedit" with no architecture information is in no channel, so not findable, so synch is not possible.
hope it's easy to reproduce, if not just ask me :P
If you have undefined architecture information in the softwre list of a rhel4.x client use the latest up2date package.
In rhel4.8 a working up2date version is already integrated (up2date-4.8.1-33.el4.i386 works fine)
Attention! If you get the spacewalk-client tools from
REMOVE!! the up2date version (up2date-4.6.2-7.el4.1.i386.rpm) from the client-tools package
It has the architecture bug not fixed and does not send the architecture information to the spacewalk platform.
And by some strage reasons, up2date-4.6.2-7.el4.1.i386.rpm is shown as update for
up2date-4.8.1-33.el4.i386 when the client is attached into spacewalk and has client-tools channel available. "Updating" to 4.6.2... will mess your architecture information again.
hope someone saves his time with that hint :P