Hi guys:
I saw the pelthora of threads where people had trouble moving to 4.4. So I'm chicken now and I was trying to wait for the dust to settle, I suppose it has and its been long enough I'm nervous about not upgrading. I need to do a a production server that is located in a data center far away so even more than normal I want a smooth upgrade.
Can someone tell the what the concensous was on the best way to do the upgrade and avoid problems. From my notes I got:
yum upgrade python-sqlite yum upgrade sqllite yum upgrade yum yum clean all yum update
But at least one guy said his box was still hosed with duplicates and a broken bind after that.
What's the method to upgrade 4.3-> 4.4 with the highest change of sucess?
Thanks very much for the help.
Scott
techlist wrote:
Can someone tell the what the concensous was on the best way to do the upgrade and avoid problems. From my notes I got:
yum upgrade python-sqlite yum upgrade sqllite yum upgrade yum yum clean all yum update
But at least one guy said his box was still hosed with duplicates and a broken bind after that.
What's the method to upgrade 4.3-> 4.4 with the highest change of sucess?
That procedure should be fine. The broken bind thing happens when people have the caching nameserver installed. I always delete it if the machine needs to run as a nameserver.
Cheers,
On Sun, 24 Sep 2006, chrism@imntv.com wrote:
techlist wrote:
Can someone tell the what the concensous was on the best way to do the upgrade and avoid problems. From my notes I got:
yum upgrade python-sqlite yum upgrade sqllite yum upgrade yum yum clean all yum update
But at least one guy said his box was still hosed with duplicates and a broken bind after that.
What's the method to upgrade 4.3-> 4.4 with the highest change of sucess?
That procedure should be fine. The broken bind thing happens when people have the caching nameserver installed. I always delete it if the machine needs to run as a nameserver.
That is not true. The broken bind thing happens if you have bind installed. I have no caching-nameservers installed here and every one of them broke on upgrade. The fix is to simply make the keys in /etc/rned.key and /etc/rndc.conf the same. There is an upstream bug open on this and a fix will be available someday. :-(
Regards,
Tom:
techlist wrote:
Can someone tell the what the concensous was on the best way to do the upgrade and avoid problems. From my notes I got:
yum upgrade python-sqlite yum upgrade sqllite yum upgrade yum yum clean all yum update
But at least one guy said his box was still hosed with duplicates and a broken bind after that.
What's the method to upgrade 4.3-> 4.4 with the highest change of sucess?
That procedure should be fine. The broken bind thing happens when people have the caching nameserver installed. I always delete it if the machine needs to run as a nameserver.
That is not true. The broken bind thing happens if you have bind installed. I have no caching-nameservers installed here and every one of them broke on upgrade. The fix is to simply make the keys in /etc/rned.key and /etc/rndc.conf the same. There is an upstream bug open on this and a fix will be available someday. :-(
Excellent, I do run bind, and I am familiar with the rndc key. So the procedure that should work properly for 4.3 to 4.4 update is:
yum upgrade python-sqlite yum upgrade sqllite yum upgrade yum yum clean all yum update massage bind rndc keys/files as required so keys match.
You, or anyone else kow of anything else I need to watch for?
Thanks guys, Scott
techlist06 spake the following on 9/25/2006 2:51 PM:
Tom:
techlist wrote:
Can someone tell the what the concensous was on the best way to do the upgrade and avoid problems. From my notes I got:
yum upgrade python-sqlite yum upgrade sqllite yum upgrade yum yum clean all yum update
But at least one guy said his box was still hosed with duplicates and a broken bind after that.
What's the method to upgrade 4.3-> 4.4 with the highest change of sucess?
That procedure should be fine. The broken bind thing happens when people have the caching nameserver installed. I always delete it if the machine needs to run as a nameserver.
That is not true. The broken bind thing happens if you have bind installed. I have no caching-nameservers installed here and every one of them broke on upgrade. The fix is to simply make the keys in /etc/rned.key and /etc/rndc.conf the same. There is an upstream bug open on this and a fix will be available someday. :-(
Excellent, I do run bind, and I am familiar with the rndc key. So the procedure that should work properly for 4.3 to 4.4 update is:
yum upgrade python-sqlite yum upgrade sqllite yum upgrade yum yum clean all yum update massage bind rndc keys/files as required so keys match.
You, or anyone else kow of anything else I need to watch for?
Thanks guys, Scott
Besides fire and explosions! Sorry, that is for Dell laptops. ;-)
That is the recommended steps, but I would put the first three on one line like; yum update yum sqlite python-sqlite just in case of a dependency problem.
Scott Silva wrote:
techlist06 spake the following on 9/25/2006 2:51 PM:
Besides fire and explosions! Sorry, that is for Dell laptops. ;-)
That is the recommended steps, but I would put the first three on one line like; yum update yum sqlite python-sqlite just in case of a dependency problem.
Definitely on *one line*. I tried running them separately, and after 'yum update sqlite ' the other updates would not run. yum froze looking for the local cache. To overcome this I had to do: rpm -e yum sqlite python-sqlite then I download the 4.3 versions of each of these rpms, and installed them, Then: yum update yum sqlite python-sqlite and finally: yum update (The above procedure was outlined on http://forums.serverbeach.com/showthread.php?t=6605)
On 9/24/06, techlist techlist06@msws.org wrote:
Can someone tell the what the concensous was on the best way to do the upgrade and avoid problems. From my notes I got:
yum upgrade python-sqlite yum upgrade sqllite yum upgrade yum yum clean all yum update
I just went through exactly that series and got the futex hang in cleanup anyway. On the other hand, on a different machine (used by only one person and not a server, so less important) I simply did "yum upgrade" and had no trouble.
The other suggestion that's been on the list that I *didn't* try (because I wanted to avoid multiple reboots) was:
rm /var/lib/rpm/__db* shutdown -r now yum upgrade python-sqlite sqlite yum yum clean all yum upgrade shutdown -r now
To recover from the futex hang on my first pass, I did
rpm -qa --qf "%{NAME}*.%{arch}.rpm\n" | sort | uniq -d | fgrep -v gpgkey | xargs -i find /var/cache/yum -name {} | sort -u > /tmp/reinstall
This produces a list of the packages that failed to clean up properly. Edit /tmp/reinstall for sanity, then run
rpm -Uvh --force `cat /tmp/reinstall`
Then run "updatedb" and do a "locate" on rpmnew and rpmsave to look for files that may need manual attention. (William Maltby's suggestion.)
On Sun, 2006-09-24 at 10:41 -0500, techlist wrote:
What's the method to upgrade 4.3-> 4.4 with the highest change of sucess?
I know this is like a month late and probably not much help but my server that's running CentOS started at 4.0 installed by CD but then has been upgraded to 4.1, 4.2, 4.3, 4.4 all through yum. No problems that I have found.
On Wed, 2006-10-11 at 19:55 -0400, Joe Klemmer wrote:
On Sun, 2006-09-24 at 10:41 -0500, techlist wrote:
What's the method to upgrade 4.3-> 4.4 with the highest change of sucess?
I know this is like a month late and probably not much help but my server that's running CentOS started at 4.0 installed by CD but then has been upgraded to 4.1, 4.2, 4.3, 4.4 all through yum. No problems that I have found.
It's not to late to say that ... and it is the way that the vast majority of Updates go. I updated more that 100 machines and only had 3 issues with DNS because for some reason the rndc.key and rndc.conf files were moved to be an rpmnew file :( ... that happened with upstream product upgrades too.
One thing to keep in perspective when looking at the issues on the mailing list is this ... there are more than a million CentOS machines in the Wild ... (we estimate about 1.5 million based on updates) so the vast majority of machines upgraded OK.