Are the problems with yum in the Centos 4.3->>4.4 upgrade process due to a forked or obsolete version of yum? I briefly scanned <https://lists.dulug.duke.edu> and didn't see any problems, but did see some incidents regarding yum hangs reported about a year ago. regarding the current upgrade, Seth Vidal in <https://lists.dulug.duke.edu/pipermail/linux/2006-September/000569.html> wrote: <quote> You should be able to get all of these and more with: yum update Let us know what breaks, -sv </quote> No replies added to the thread indicating the folks at Duke aren't having problems with the update to Centos 4.4 whereas folks on the Centos list have reported quite a few problems. Kind regards, Larry Vaden Internet Texoma, Inc.
On Sun, 2006-09-17 at 08:10 -0500, Larry Vaden wrote:> Are the problems with yum in the Centos 4.3->>4.4 upgrade process due > to a forked or obsolete version of yum? > > I briefly scanned <https://lists.dulug.duke.edu> and didn't see any > problems, but did see some incidents regarding yum hangs reported > about a year ago. > > regarding the current upgrade, Seth Vidal in > <https://lists.dulug.duke.edu/pipermail/linux/2006-September/000569.html> > wrote: > > <quote> > You should be able to get all of these and more with: > yum update > > Let us know what breaks, > -sv > </quote> > > No replies added to the thread indicating the folks at Duke aren't > having problems with the update to Centos 4.4 whereas folks on the > Centos list have reported quite a few problems. >There are more than 1.5 million centos machines out there ... and we always have some issues on upgrade. Several of the issues attributed to 4.4 upgrade have since been reclassified ... that always happens as well. Almost all of the machines upgraded without any issues. This time the vast majority of issues were because python-sqlite has to be upgraded at the same time as sqlite ... and sometimes it doesn't happen soon enough on a full yum update. To work around that issue: yum update yum sqlite python-sqlite kernel Then do the rest of the upgrade. There is a futex issue that happens to some people (and has been happening since RH 5.x) ... to minimize that reboot prior to upgrade and remove the files __db.00* from /var/lib/rpm. Other than that, there was only 1 or 2 issues (Lamar Owen had a really strange one) ... those issues seemed unique to the machines involved or not predictable. Lamar's problem was particularly strange and I have never seen it before. This is not to minimize his (or any of the other issues), but they makeup < .1% of the upgrades performed. CentOS-4.4 is stable and should be used. -------------- 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/20060917/d93f934a/attachment-0002.sig>
On Sunday 17 September 2006 09:55, Johnny Hughes wrote:> Other than that, there was only 1 or 2 issues (Lamar Owen had a really > strange one) ... those issues seemed unique to the machines involved or > not predictable.Ok, more information on my issue. I'm in the process of upgrading another production nameserver, and I ran across this (I was going to update bind separately): [root at pachyderm ~]# rpm -q --requires bind /bin/bash [snip] libdns.so.16 libisc.so.7 libisccc.so.0 libisccfg.so.0 liblwres.so.1 [snip] [root at pachyderm ~]# rpm --provides -q bind-libs libdns.so.16 libisc.so.7 libisccc.so.0 libisccfg.so.0 liblwres.so.1 bind-libs = 20:9.2.4-2 [root at pachyderm ~]# yum update bind Setting up Update Process Setting up repositories Reading repository metadata in from local files Resolving Dependencies --> Populating transaction set with selected packages. Please wait. ---> Package bind.i386 20:9.2.4-16.EL4 set to be updated --> Running transaction check --> Processing Dependency: bind = 20:9.2.4-2 for package: bind-chroot --> Restarting Dependency Resolution with new changes. --> Populating transaction set with selected packages. Please wait. ---> Package bind-chroot.i386 20:9.2.4-16.EL4 set to be updated --> Running transaction check Dependencies Resolved ============================================================================ Package Arch Version Repository Size ============================================================================Updating: bind i386 20:9.2.4-16.EL4 base 579 k Updating for dependencies: bind-chroot i386 20:9.2.4-16.EL4 base 33 k Transaction Summary ============================================================================Install 0 Package(s) Update 2 Package(s) Remove 0 Package(s) Total download size: 613 k Is this ok [y/N]: n Exiting on user Command Complete! [root at pachyderm ~]# Why is bind-libs not being updated as a dependency? I verified that this is a dep in the later version; these getting out of sync caused my problem. Hmmm, the bind package isn't requiring the corresponding bind-libs package directly, apparently, just requiring the libs of the certain version (which apparently do not work properly). A full update should pull in the updated bind-libs, though. Could it be that the mirror that got used by the update for my particular box was in the process of syncing, and had metadata that didn't include bind-libs, or was out of sync in some way? I have seen that as an issue once or twice in the past. -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 (828)862-5554 www.pari.edu
Johnny Hughes wrote: <snip>> To work around that issue: > > yum update yum sqlite python-sqlite kernel > > Then do the rest of the upgrade. > > There is a futex issue that happens to some people (and has been > happening since RH 5.x) ... to minimize that reboot prior to upgrade and > remove the files __db.00* from /var/lib/rpm. >On a an ASUS A7N8X / Athlon 2600+ box that has historically been a tad ornery, this worked like a champ! When the smoke cleared, the only anomaly I found was that hald wasn't running. Thanks!