Description of problem:
If there is a database issue (UNDO_TBS full, DATA_TBS full, network down), file can get renamed but the new path is not stored in database.
Then, errors similar to
RHN 28350 2009/09/10 14:04:22 +02:00: ('Package not found',
will appear in /var/log/httpd/error_log during yum operation.
Version-Release number of selected component (if applicable):
Satellite pre-5.3.0, upgraded to 5.3.0.
It's hard to reproduce in deterministic fashion.
Steps to Reproduce:
1. Run the /usr/bin/updated-packages during Satellite upgrade to 5.3, and kill the database in the middle.
2. But: see Additional info for alternative test plan.
Then, yum will fail for one or more packages.
The /usr/bin/update-packages should be self-healing.
We've seen the same problem when after a complete upgrade to Satellite 5.3.0, the database was restored from backup and schema upgrade rerun. Running update-packages with --debug then produces Missing Path message for every package.
The script should realize that the file was already renamed.
Taking for now.
Fix to just use the file found on the final location committed to Spacewalk master: 82afbb68ef1af1f87ba2a9e9466f14e67fbb053b.
Additional fix (to the previous fix) in Spacewalk master: c95a6b21b9d41d3dbfa80a52e956142120763026.
We shall read from the new file, even if we did not rename; Spacewalk master: 9f9f5476724c48bb87d52e5d9bcefbbfd91a2c39.
satellite.git, SATELLITE-5.3: 18585b473f0e69af1704d2557c1aa946ff4a30a1
rhn-upgrade-220.127.116.11-1.el4sat & rhn-upgrade-18.104.22.168-1.el5sat
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.