Spacewalk / Red Hat Satellite / SUSE Manager package action fails: "empty transaction [[6]]"

calendar May 5, 2014 · 2 min read · red-hat-satellite spacewalk suse-manager  ·
Share on: linkedin copy

It is possible that the following error message is displayed on client systems when software packages are distributed using Spacewalk, Red Hat Satellite or SUSE Manager:

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

This issue rests on the database of the management suite. After a while (or after a database schemata update) the cached packages information of the particular client systems are invalid. Already installed updates are provided - of course installing them fails.

I had this effect multiple times in combination with Spacewalk and Red Hat Satellite. I hadn't hat this issue with SUSE Manager but I'm not using this software productively anyway. Bascially this guide manual will also work for SUSE Manager.

A approach to solve the issue is to update the Client profile:

1# rhn-profile-sync -v

If this fails (which mostly happened for me) another approach is to delete the RHN caches on the management system. To do this it is necessary to stop the services and delete a directory:

1satellite # rhn-satellite stop
2susemgr_spacewalk # spacewalk-service stop
3# rm -rf /var/cache/rhn/*

Beyond that it is necessary to temporarily change a variable in the RHN configuration file before starting the service.

1# vi /etc/rhn/rhn.conf
2...
3#fix incorrect repodata - DON'T forget to reset to 1!
4user_db_repodata=0
5
6ESC ZZ
7
8satellite # rhn-satellite start
9susemgr_spacewalk # spacewalk-service start

Updating the cache can take up to one hour. In the meantime it is possible that the package managers of registered client systems are reporting errors like that:

1# yum update
2...
3cannot retrive repository metadata (repod.xml) for repository: xyz

Afterwards the RHN configuration file is altered again:

1# vi /etc/rhn/rhn.conf
2...
3#fix incorrect repodata - DON'T forget to reset to 1!
4user_db_repodata=1
5
6ESC ZZ

It might be necessary to update the profile of the particular registered client systems to report the correct updates:

1# rhn-profile-sync -v

In my case the appropriate correct patches were displayed afterwards. 🙂

Translations: