On Fri, 2006-08-11 at 10:38 -0400, Horst H. von Brand wrote:
Gerry Tool gstool@earthlink.net wrote:
I was performing a yum update in FC5 when the system froze. On reboot, I executed yum update again and it updated a partial list of the packages that were listed in the first attempt. However, one of the packages in the original list, but not the second list was firefox, updating to 1.5.0.6. After the update, my firefox is still at 1.5.0.4. I have tried several things to get it to update, all unsuccessfully, including yum clean all followed by another update attempt, and downloading the package and using rpm. That fails due to dependencies which apparently were also in the interrupted update.
I've had to kill -KILL (no reaction to -HUP and -TERM) yum for various reasons, and sometimes it gets messed up in that it claims there are /no/ updates available (when there clearly are lots of them). Manually deleting the files in the local staging areas clears this up when a "yum clean all" doesn't:
primary.xml.gz primary.xml.gz.sqlite cachecookie repomd.xml
I'm quite sure this is way overkill, but it works...
Hmmm, yum has quite a lot to do and it can often take some time. As a result, it isn't unheard of for a crash (or similar) while yum is doing it's work.
I can't help but wonder if yum doesn't need some sort of auditing that would allow yum to recover cleanly from these sorts of situations.
Yum seems to follow a clean line of events.
1. Download information about updates 2. Download update rpms
(at this point a failure in yum isn't likely to cause any issues, restart yum and it should pick up where it left off. The only thing I have seen is that yum doesn't realize that the package currently being downloaded isn't all there and as a result it fails. Maybe it needs to check the shasum of packages that are already cached to see if they are complete.)
3. Figure out the best order to install updates 4. Install updates 5. Remove older packages 6. Ta Da.
I know this is a little vague, but if this rough view of how it works is close enough, then a list of things that need to be done during the critical install/remove stage could be made and then verified as they are completed. By doing this, yum could realize that it failed to complete an update last time it was run and attempt to resume at the point when it failed.
Does this sound like something that should be BZ'ed as a enhancement?
Or maybe I'm on crack ;-]
R..