Hi all, I just ran into a problem. I was following the nifty procedure to upgrade a WhiteHat/RHEL3.x box to CentOS 3.6 and the update hung. It was in the process of updating MySQL server, and a post install scriptlet apparently failed. So I killed the process with a CTRL-C. However, upon trying to restart YUM, it says there is nothing left to, saying: Gathering header information file(s) from server(s) Server: CentOS-3 - Addons Server: CentOS-3 - Base Server: CentOS-3 - Extras Server: CentOS-3 - Updates Finding updated packages Downloading needed headers No Packages Available for Update No actions to take However, the MySQL server package was 121/172, so there should be 51 packages left. Unless the output to the screen was killed off, but the process continued? I have yet to reboot for fear something is in a very unstable state. Any ideas? Thanks, Ian
On Mon, 2006-03-13 at 09:43 -0800, iank at mac.com wrote:> Hi all, > > I just ran into a problem. I was following the nifty procedure to > upgrade a WhiteHat/RHEL3.x box to CentOS 3.6 and the update hung. It > was in the process of updating > MySQL server, and a post install scriptlet apparently failed. So I > killed the process > with a CTRL-C. However, upon trying to restart YUM, it says there is > nothing left to, > saying: > > Gathering header information file(s) from server(s) > Server: CentOS-3 - Addons > Server: CentOS-3 - Base > Server: CentOS-3 - Extras > Server: CentOS-3 - Updates > Finding updated packages > Downloading needed headers > No Packages Available for Update > No actions to take > > However, the MySQL server package was 121/172, so there should be 51 > packages > left. Unless the output to the screen was killed off, but the process > continued? > > I have yet to reboot for fear something is in a very unstable state. > > Any ideas? > > Thanks, > > Iantry: yum clean and then yum upgrade -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: <http://lists.centos.org/pipermail/centos/attachments/20060313/bc014cb5/attachment.sig>
Johnny Hughes wrote: > > try: > yum clean > > and then > > yum upgrade Thanks Johnny. I forgot to mention that I have already tried: yum clean yum clean all rebuilding the RPM database clearing out all of the headers/header.info under /var/cache/yum It still claims nothing needs to be done. BTW, sorry if this reply hoses threading. I'm in an in-between state right now, in the midst of switching jobs. So, my mail list memberships are being received in one place, but sent from another. Thanks again, Ian
Thanks Johnny. Well, here is some good news (I hope). I was able to scroll back on the console, and it looks like all of the RPMs were installed, but it is the actual post-install scripts that were interrupted. I checked the list of what was installed vs. the list of what was dowloaded/needed, and they match. So, any ideas on how to complete the post-install process? Ian
OK, I got it solved. Thank goodness for a screen that scrolls back a long way!! I was able to pull the install order from the console output (note to self, sending a copy of the console messages to a file would be a good thing). From there I was able to determine what was left off, and the proper order run through. Probably the best method would be to do the following: *Work backwards from the last RPM downloaded. *Since the rpm name might be truncated, do a "rpm -qa | grep rpm name" *You should see 2 versions, the old one and the new one (since the install process itself completed). *Do a "rpm -e --justdb newer rpm name" *Continue through until you reach the transaction that failed. *Do a "yum update rpm name" from that point back down the list in the correct order of the downloads. This will back out just the rpm database entry, and allow you run the yum transaction correctly, including all pre/post/postun scripts. Some thoughts: Once you back out all the database entries, you could probably just run "yum update" which should catch everything that you need. I didn't back things out in the reverse order, but worked from the stopping point on. In hindsight, this is probably what led to a few dependency issues which required the --nodeps flag. A script might work out nicely, but I wanted to watch each transaction for problems. Thanks, Ian