I think the problem is on the metadata generation. When going on the channel details, I see this: Last Modified: 2012-07-10 23:00:12 GMT Last Repo Build: 2012-06-21 23:16:56 GMT Repo Cache Status: In Progress
And in the admin page: Channel Repodata: 2012-06-25 22:35:00 GMT RUNNING In the logs of taskomatic, here is what I could find: positoryWriter - Generating new repository metadata for channel 'rhel-6-server-x64'(sha1) 4928 packages, 834 errata INFO | jvm 1 | 2012/06/21 23:18:44 | Exception in thread "Thread-105830" java.lang.OutOfMemoryError: GC overhead limit exceeded INFO | jvm 1 | 2012/06/21 23:18:44 | at java.lang.reflect.Method.copy(Method.java:161) INFO | jvm 1 | 2012/06/21 23:18:44 | at java.lang.reflect.ReflectAccess.copyMethod(ReflectAccess.java:136) INFO | jvm 1 | 2012/06/21 23:18:44 | at sun.reflect.ReflectionFactory.copyMethod(ReflectionFactory.java:300) INFO | jvm 1 | 2012/06/21 23:18:44 | at java.lang.Class.copyMethods(Class.java:2765) INFO | jvm 1 | 2012/06/21 23:18:44 | at java.lang.Class.getMethods(Class.java:1427) INFO | jvm 1 | 2012/06/21 23:18:44 | at com.redhat.rhn.common.util.MethodUtil.callMethod(MethodUtil.java:114) INFO | jvm 1 | 2012/06/21 23:18:44 | at com.redhat.rhn.common.db.datasource.CachedStatement.addToObject(CachedStatement.java:751) INFO | jvm 1 | 2012/06/21 23:18:44 | at com.redhat.rhn.common.db.datasource.CachedStatement.processResultSet(CachedStatement.java:602) INFO | jvm 1 | 2012/06/21 23:18:44 | at com.redhat.rhn.common.db.datasource.CachedStatement.execute(CachedStatement.java:460) INFO | jvm 1 | 2012/06/21 23:18:44 | at com.redhat.rhn.common.db.datasource.CachedStatement.execute(CachedStatement.java:430) INFO | jvm 1 | 2012/06/21 23:18:44 | at com.redhat.rhn.common.db.datasource.CachedStatement.execute(CachedStatement.java:336) INFO | jvm 1 | 2012/06/21 23:18:44 | at com.redhat.rhn.common.db.datasource.CachedStatement.execute(CachedStatement.java:341) INFO | jvm 1 | 2012/06/21 23:18:44 | at com.redhat.rhn.common.db.datasource.CachedStatement.execute(CachedStatement.java:281) INFO | jvm 1 | 2012/06/21 23:18:44 | at com.redhat.rhn.common.db.datasource.SelectMode.execute(SelectMode.java:109) INFO | jvm 1 | 2012/06/21 23:18:44 | at com.redhat.rhn.manager.task.TaskManager.getChannelPackageDtos(TaskManager.java:50) INFO | jvm 1 | 2012/06/21 23:18:44 | at com.redhat.rhn.taskomatic.task.repomd.RpmRepositoryWriter.writeRepomdFiles(RpmRepositoryWriter.java:170) INFO | jvm 1 | 2012/06/21 23:18:44 | at com.redhat.rhn.taskomatic.task.repomd.ChannelRepodataWorker.run(ChannelRepodataWorker.java:104) INFO | jvm 1 | 2012/06/21 23:18:44 | at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:761) INFO | jvm 1 | 2012/06/21 23:18:44 | at java.lang.Thread.run(Thread.java:679) INFO | jvm 1 | 2012/06/21 23:19:01 How can I clean up this situation? By the way: on 21st of june, RHEL 6.3 was released! Taskomatic had to handle too much changes I guess Pierre /7/11 Michael Mraka <[email protected]>: > Pierre Casenove wrote: > % Hello list, > % My setup: Spacewalk 1.7 server. RHEL 6 Client with spacewalk 1.7 > % packages installed. > % My problem is that some erratas, imported by rhn-clone-errata are > % marked as needed in spacewalk UI, but fails to apply on my client with > % error code: > % Client execution returned "Error while executing packages action: > % empty transaction [[6]]" (code -1) > % > % The errata that fails to apply is: RHSA-2012:1054. This errata is > % associated to these packages: > % libtiff-3.9.4-6.el6_3-i686 > % libtiff-3.9.4-6.el6_3-x86_64 > % libtiff-devel-3.9.4-6.el6_3-i686 > % libtiff-devel-3.9.4-6.el6_3-x86_64 > % > % On my client, I have these packages already installed: > % > % ~ $ rpm -qa | grep libtiff > % libtiff-3.9.4-5.el6_2.x86_64 --> So the package should be updated > % > % ~$ yum update libtiff > % Loaded plugins: product-id, rhnplugin, security, subscription-manager > % Updating certificate-based repositories. > % Unable to read consumer identity > % Setting up Update Process > % No Packages marked for Update > > It looks like yum can't see new libtiff in any repository. > yum list libtiff --showduplicates > Aren't there stale metadata in yum's cache? > yum clean all > yum update libtiff > Or maybe something went wrong with yum metadata generation on the > spacewalk server (taskomatic failed?). > xmllint -format /var/cache/rhn/repodata/<channel_label>/primary.xml.gz | > grep libtiff-3.9.4-6.el6_3 > > % And finally, here is the trace when scheduling errata deployment and > % running rhn_check -vvvv > % > % D: rpcServer: Calling XMLRPC errata.getErrataInfo > % D: Called update[['libtiff', '3.9.4', '6.el6_3', '', 'x86_64']] > ... > % D: Sending back response((6,), 'Error while executing packages action: > % empty transaction', {}) > % > % Thanks in advance for your help, > % > % Pierre > > Regards, > > -- > Michael Mráka > Satellite Engineering, Red Hat > > _______________________________________________ > Spacewalk-list mailing list > [email protected] > https://www.redhat.com/mailman/listinfo/spacewalk-list _______________________________________________ Spacewalk-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/spacewalk-list
