[Spacewalk-list] RHEL4 rollbacks missing packages that exist

[Cliff Perry]

On 12/15/2011 09:54 AM, Jason M. Nielsen wrote:
> I have a base 4.8 channel with several child channels. One of the child
> channels contains the 4.3 release.
> 
> The test server is 4.3. I up2date to 4.8 without issue.
> 
> The 4.3 child channel appears to be fine regarding a repocache etc.
> 
> If I attempt a rollback Spacewalk never claims any packages are missing
> during the task creation. Approximately an hour into the rollback though
> the task fails claiming about 20 packages are missing that it needs.
> 
> These packages are not missing and show up in SW searches without issue.
> Additionally it doesnt complain about the approximately 700 other
> packages that exist in the same channel so I can only assume it finds them.
> 
> I have tested rollbacks on RHEL5 fairly extensively and by in large have
> been fully successful so I do not think my configuration nor methods are
> incorrect.
> 
> Anyone seen this before and/or have a fix?  I have rummaged around
> through logs but cant seem to find any reason it should think these
> packages are missing.
> 
> This is the only really descriptive message I get:
> 
> Client execution returned "Failed: Some of the packages requested are
> not available. Missing-Packages: [['Canna-libs', '3.7p3', '7.EL4', '',
> 'i386'], ['FreeWnn-libs', '1.10pl020', '5', '1', 'i386'], ['GConf2',
> '2.8.1', '1', '', 'i386'], ['apr', '0.9.4', '24.5', '', 'i386'],
> ['aspell', '0.50.5', '3.fc3', '12', 'i386'], ['audiofile', '0.2.6', '1',
> '1', 'i386'], ['audit-libs', '1.0.12', '1.EL4', '', 'i386'],
> ['bind-libs', '9.2.4', '2', '20', 'i386'], ['bluez-libs', '2.10', '2',
> '', 'i386'], ['boost', '1.32.0', '1.rhel4', '', 'i386'], ['bzip2-libs',
> '1.0.2', '13.EL4.3', '', 'i386'], ['compat-openldap', '2.1.30', '4', '',
> 'i386'], ['cracklib', '2.7', '29', '', 'i386'], ['cracklib-dicts',
> '2.7', '29', '', 'i386'], ['cups-libs', '1.1.22', '0.rc1.9.10', '1',
> 'i386'], ['curl', '7.12.1', '8.rhel4', '', 'i386'], ['cyrus-sasl',
> '2.1.19', '5.EL4', '', 'i386'], ['cyrus-sasl-gssapi', '2.1.19', '5.EL4',
> '', 'i386'], ['cyrus-sasl-md5', '2.1.19', '5.EL4', '', 'i386'],
> ['cyrus-sasl-ntlm', '2.1.19', '5.EL4', '', 'i386'], ['cyrus-sasl-plain',
> '2.1.19', '5." (code 41)
> 
> Thanks.
> 
> _______________________________________________
> Spacewalk-list mailing list
> Spacewalk-list at redhat.com
> https://www.redhat.com/mailman/listinfo/spacewalk-list

In short, mass rollback of 100's of packages is 'use at your own risk' -
due to bugs in RPM and/or up2date and/or yum/yum-rhn-plugin.

We have within the Red Hat Kbase for Satellite customers content setting
expectations that this is designed for small rpm transactions, excluding
critical packages such as kernel, glibc downgrades.

I do not have a fix, other than suggesting to try putting ALL the
content into the same channel and seeing if it helps.

Also, make sure your not downgrading up2date during the transaction to
an older version. Keep up2date as new as possible at all times.

But in the end you just may have hit a bug, I'm surprised if you have a
working and functional system at the end of such a mass downgrade of
packages.

Cliff