I'm wondering about yum update vs. yum upgrade. The man page says use upgrade (actually the obsoletes flag which is set in upgrade and not update) when doing something like a linux 8.0 to linux 9 upgrade. Something we can't do with CentOS, i.e. 3 to 4. So, is it better to use update or upgrade when going from 4.3 to 4.4? Doesn't RedHat call these "Quarterly Updates" and not "Quarterly Upgrades"?
And, it seems that the folks having trouble were doing yum upgrade. I'm wondering if anyone is experiencing the same difficulties when doing yum update?
And --obsoletes.... seems like the man page for yum really doesn't say much about what this actually does.. but it sounds like something I don't want to use... sounds like it leaves obsoletes laying around?
from man page
"upgrade Is the same as the update command with the --obsoletes flag set."
"If the --obsoletes flag is present yum will include package obsoletes in its calculations - this makes it better for distro-version changes, for example: upgrading from somelinux 8.0 to somelinux 9."
" yum list obsoletes [regexp1] [...] List the packages installed on the system that are obsoleted by packages in any yum repository listed in the config file."
Could this be what's causing the conflicts with sqlite?
And if update vs. upgrade doesn't make any difference (from my first question).. Has a 'clear' direction for painless updating emerged?
Best, John Hinton
John Hinton wrote:
I'm wondering about yum update vs. yum upgrade. The man page says use upgrade (actually the obsoletes flag which is set in upgrade and not update) when doing something like a linux 8.0 to linux 9 upgrade. Something we can't do with CentOS, i.e. 3 to 4. So, is it better to use update or upgrade when going from 4.3 to 4.4? Doesn't RedHat call these "Quarterly Updates" and not "Quarterly Upgrades"?
on yum-2.4.x the --obsoletes flag is enabled by default anyway, so in effect what you get from update or from upgrade is about the same thing.
And, it seems that the folks having trouble were doing yum upgrade. I'm wondering if anyone is experiencing the same difficulties when doing yum update?
look at the thread again, its only when someone does an update for only sqlite that they have an issue, a 'yum update yum; yum update' has worked fine for me
Could this be what's causing the conflicts with sqlite?
no.
And if update vs. upgrade doesn't make any difference (from my first question).. Has a 'clear' direction for painless updating emerged?
yes : yum update yum sqlite python-sqlite ; yum update
Karanbir Singh napsal(a):
look at the thread again, its only when someone does an update for only sqlite that they have an issue, a 'yum update yum; yum update' has worked fine for me
I agree too, 'yum update yum; yum update' worked for me to perfectly and I dare to say it's preferred method when yum is within packages to be updated.
yes : yum update yum sqlite python-sqlite ; yum update
First thing that came to me had been 'yum update yum' should resolved dependency and install sqlite and python-sqlite too. But it's just the hint. David
On 9/1/06, Karanbir Singh mail-lists@karan.org wrote:
look at the thread again, its only when someone does an update for only sqlite that they have an issue, a 'yum update yum; yum update' has worked fine for me
chroot'd named quit running about 05:00 yesterday morning. wouldn't restart due to permission problems.
rgds/ldv
Larry Vaden wrote:
On 9/1/06, Karanbir Singh mail-lists@karan.org wrote:
look at the thread again, its only when someone does an update for only sqlite that they have an issue, a 'yum update yum; yum update' has worked fine for me
chroot'd named quit running about 05:00 yesterday morning. wouldn't restart due to permission problems.
have you opened a bug report for this ?
On 9/1/06, Karanbir Singh mail-lists@karan.org wrote:
Larry Vaden wrote:
On 9/1/06, Karanbir Singh mail-lists@karan.org wrote:
look at the thread again, its only when someone does an update for only sqlite that they have an issue, a 'yum update yum; yum update' has worked fine for me
chroot'd named quit running about 05:00 yesterday morning. wouldn't restart due to permission problems.
have you opened a bug report for this ?
There was something similar mentioned by others 08/13 regarding a change released 08/11. I'm not sure why we weren't impacted until yesterday ~ 05:00.
rgds/ldv
On Fri, 2006-09-01 at 05:02 -0500, Larry Vaden wrote:
On 9/1/06, Karanbir Singh mail-lists@karan.org wrote:
Larry Vaden wrote:
On 9/1/06, Karanbir Singh mail-lists@karan.org wrote:
look at the thread again, its only when someone does an update for only sqlite that they have an issue, a 'yum update yum; yum update' has worked fine for me
chroot'd named quit running about 05:00 yesterday morning. wouldn't restart due to permission problems.
have you opened a bug report for this ?
There was something similar mentioned by others 08/13 regarding a change released 08/11. I'm not sure why we weren't impacted until yesterday ~ 05:00.
You were affected yesterday ... Because ... it was an update for 4.4.
RH released 4.4 on 8/10
CentOS released the security updates included for 4.4 on 8/23 (bind was a bugfix update and not a security update ... it was not released on 8/23).
CentOS released the full 4.4 update set on 8/29, and since bind was a bugfix updates and not secuirty update, that is when it was released.
It is the CentOS goal to have the update set releases out 2 weeks after the update ... however due to a showstopper bug in 3.8 (the rescue CD would not work, and still does not work in the upstream product) we had to delay it's update and fix the problem. That delay caused a corresponding delay in releasing CentOS-4.4 since we can only release one major update set at a time due bandwidth considerations.
So, CentOS-4.4 was released 8/29 ... and that was 5 days past our 14 day goal.
THAT is why you saw the problem yesterday :)
On 9/1/06, Johnny Hughes mailing-lists@hughesjr.com wrote:
On Fri, 2006-09-01 at 05:02 -0500, Larry Vaden wrote:
On 9/1/06, Karanbir Singh mail-lists@karan.org wrote:
Larry Vaden wrote:
On 9/1/06, Karanbir Singh mail-lists@karan.org wrote:
look at the thread again, its only when someone does an update for only sqlite that they have an issue, a 'yum update yum; yum update' has worked fine for me
chroot'd named quit running about 05:00 yesterday morning. wouldn't restart due to permission problems.
have you opened a bug report for this ?
There was something similar mentioned by others 08/13 regarding a change released 08/11. I'm not sure why we weren't impacted until yesterday ~ 05:00.
You were affected yesterday ... Because ... it was an update for 4.4.
RH released 4.4 on 8/10
CentOS released the security updates included for 4.4 on 8/23 (bind was a bugfix update and not a security update ... it was not released on 8/23).
CentOS released the full 4.4 update set on 8/29, and since bind was a bugfix updates and not secuirty update, that is when it was released.
It is the CentOS goal to have the update set releases out 2 weeks after the update ... however due to a showstopper bug in 3.8 (the rescue CD would not work, and still does not work in the upstream product) we had to delay it's update and fix the problem. That delay caused a corresponding delay in releasing CentOS-4.4 since we can only release one major update set at a time due bandwidth considerations.
So, CentOS-4.4 was released 8/29 ... and that was 5 days past our 14 day goal.
THAT is why you saw the problem yesterday :)
Thanks for your explanation. I tried two or three differenct solutions without result, so because it was a production server (ns2), I resorted to changing the permissions.
What is the correct solution?
rgds/ldv
log entries:
Aug 31 05:42:08 ns2 named[1988]: shutting down: flushing changes Aug 31 05:42:08 ns2 named[1988]: stopping command channel on 127.0.0.1#953 Aug 31 05:42:08 ns2 named: succeeded Aug 31 05:42:09 ns2 named[1988]: exiting Aug 31 05:42:11 ns2 named[12127]: starting BIND 9.2.4 -u named -t /var/named/chroot Aug 31 05:42:11 ns2 named[12127]: using 1 CPU Aug 31 05:42:11 ns2 named: named startup succeeded Aug 31 05:42:11 ns2 named[12127]: loading configuration from '/etc/named.conf' Aug 31 05:42:11 ns2 named[12127]: no IPv6 interfaces found Aug 31 05:42:11 ns2 named[12127]: listening on IPv4 interface lo, 127.0.0.1#53 Aug 31 05:42:11 ns2 named[12127]: listening on IPv4 interface eth0, 209.151.96.66#53 Aug 31 05:42:11 ns2 named[12127]: zone version.bind/CH: has 0 SOA records Aug 31 05:42:11 ns2 named[12127]: zone version.bind/CH: has no NS records Aug 31 05:42:11 ns2 named[12127]: view.c:347: REQUIRE((&view->references)->refs > 0) failed Aug 31 05:42:11 ns2 named[12127]: exiting (due to assertion failure) Aug 31 05:44:32 ns2 named: failed Aug 31 05:44:34 ns2 named[12742]: starting BIND 9.2.4 -u named -t /var/named/chroot Aug 31 05:44:34 ns2 named[12742]: using 2 CPUs Aug 31 05:44:34 ns2 named[12742]: loading configuration from '/etc/named.conf' Aug 31 05:44:35 ns2 named[12742]: no IPv6 interfaces found Aug 31 05:44:35 ns2 named[12742]: listening on IPv4 interface lo, 127.0.0.1#53 Aug 31 05:44:35 ns2 named[12742]: listening on IPv4 interface eth0, 209.151.96.66#53 Aug 31 05:44:35 ns2 named[12742]: command channel listening on 127.0.0.1#953 Aug 31 05:44:35 ns2 named[12742]: couldn't open pid file 'named.pid': File exists Aug 31 05:44:35 ns2 named[12742]: exiting (due to early fatal error) Aug 31 05:44:35 ns2 named: named startup failed Aug 31 15:52:21 ns2 named: failed Aug 31 15:52:23 ns2 named[13133]: starting BIND 9.2.4 -u named -t /var/named/chroot Aug 31 15:52:23 ns2 named[13133]: using 2 CPUs Aug 31 15:52:23 ns2 named[13133]: loading configuration from '/etc/named.conf' Aug 31 15:52:23 ns2 named[13133]: no IPv6 interfaces found Aug 31 15:52:23 ns2 named[13133]: listening on IPv4 interface lo, 127.0.0.1#53 Aug 31 15:52:23 ns2 named[13133]: listening on IPv4 interface eth0, 209.151.96.66#53 Aug 31 15:52:23 ns2 named[13133]: command channel listening on 127.0.0.1#953 Aug 31 15:52:23 ns2 named[13133]: couldn't open pid file 'named.pid': File exists Aug 31 15:52:23 ns2 named[13133]: exiting (due to early fatal error) Aug 31 15:52:23 ns2 named: named startup failed Aug 31 15:54:05 ns2 named: failed Aug 31 15:54:07 ns2 named[13165]: starting BIND 9.2.4 -u named -t /var/named/chroot Aug 31 15:54:07 ns2 named[13165]: using 2 CPUs Aug 31 15:54:07 ns2 named[13165]: loading configuration from '/etc/named.conf' Aug 31 15:54:07 ns2 named[13165]: no IPv6 interfaces found Aug 31 15:54:07 ns2 named[13165]: listening on IPv4 interface lo, 127.0.0.1#53 Aug 31 15:54:07 ns2 named[13165]: listening on IPv4 interface eth0, 209.151.96.66#53 Aug 31 15:54:07 ns2 named[13165]: command channel listening on 127.0.0.1#953 Aug 31 15:54:07 ns2 named[13165]: couldn't open pid file 'named.pid': Permission denied Aug 31 15:54:07 ns2 named[13165]: exiting (due to early fatal error) Aug 31 15:54:07 ns2 named: named startup failed Aug 31 16:08:17 ns2 named: failed Aug 31 16:08:20 ns2 named: failed Aug 31 16:08:20 ns2 named: /etc/rndc.key:24: 'options' redefined near 'options' Aug 31 16:11:25 ns2 named: failed Aug 31 16:11:27 ns2 named[13250]: starting BIND 9.2.4 -u named -t /var/named/chroot Aug 31 16:11:27 ns2 named[13250]: using 2 CPUs Aug 31 16:11:27 ns2 named[13250]: loading configuration from '/etc/named.conf' Aug 31 16:11:27 ns2 named[13250]: no IPv6 interfaces found Aug 31 16:11:27 ns2 named[13250]: listening on IPv4 interface lo, 127.0.0.1#53 Aug 31 16:11:27 ns2 named[13250]: listening on IPv4 interface eth0, 209.151.96.66#53 Aug 31 16:11:27 ns2 named[13250]: command channel listening on 127.0.0.1#953 Aug 31 16:11:27 ns2 named[13250]: couldn't open pid file 'named.pid': Permission denied Aug 31 16:11:27 ns2 named[13250]: exiting (due to early fatal error) Aug 31 16:11:27 ns2 named: named startup failed Aug 31 16:27:49 ns2 named[13329]: starting BIND 9.2.4 -u named -t /var/named/chroot Aug 31 16:27:49 ns2 named[13329]: using 2 CPUs Aug 31 16:27:49 ns2 named[13329]: loading configuration from '/etc/named.conf' Aug 31 16:27:49 ns2 named[13329]: no IPv6 interfaces found Aug 31 16:27:49 ns2 named[13329]: listening on IPv4 interface lo, 127.0.0.1#53 Aug 31 16:27:49 ns2 named[13329]: listening on IPv4 interface eth0, 209.151.96.66#53 Aug 31 16:27:49 ns2 named[13329]: /etc/rndc.key:1: configuring key 'rndckey': bad base64 encoding Aug 31 16:27:49 ns2 named[13329]: loading configuration: bad base64 encoding Aug 31 16:27:49 ns2 named[13329]: exiting (due to fatal error) Aug 31 16:27:49 ns2 named: named startup failed Aug 31 16:31:42 ns2 named[13361]: starting BIND 9.2.4 -u named -t /var/named/chroot Aug 31 16:31:42 ns2 named[13361]: using 2 CPUs Aug 31 16:31:42 ns2 named[13361]: loading configuration from '/etc/named.conf' Aug 31 16:31:42 ns2 named[13361]: no IPv6 interfaces found Aug 31 16:31:42 ns2 named[13361]: listening on IPv4 interface lo, 127.0.0.1#53 Aug 31 16:31:42 ns2 named[13361]: listening on IPv4 interface eth0, 209.151.96.66#53 Aug 31 16:31:42 ns2 named[13361]: command channel listening on 127.0.0.1#953 Aug 31 16:31:42 ns2 named[13361]: couldn't open pid file 'named.pid': Permission denied Aug 31 16:31:42 ns2 named[13361]: exiting (due to early fatal error) Aug 31 16:31:42 ns2 named: named startup failed Aug 31 16:45:28 ns2 named[13403]: starting BIND 9.2.4 -u named -t /var/named/chroot Aug 31 16:45:28 ns2 named[13403]: using 2 CPUs Aug 31 16:45:28 ns2 named[13403]: loading configuration from '/etc/named.conf' Aug 31 16:45:28 ns2 named[13403]: no IPv6 interfaces found Aug 31 16:45:28 ns2 named[13403]: listening on IPv4 interface lo, 127.0.0.1#53 Aug 31 16:45:28 ns2 named[13403]: listening on IPv4 interface eth0, 209.151.96.66#53 Aug 31 16:45:28 ns2 named[13403]: command channel listening on 127.0.0.1#953 Aug 31 16:45:38 ns2 named[13403]: running Aug 31 16:45:38 ns2 named: named startup succeeded
Johnny Hughes spake the following on 9/1/2006 3:50 AM:
On Fri, 2006-09-01 at 05:02 -0500, Larry Vaden wrote:
On 9/1/06, Karanbir Singh mail-lists@karan.org wrote:
Larry Vaden wrote:
On 9/1/06, Karanbir Singh mail-lists@karan.org wrote:
look at the thread again, its only when someone does an update for only sqlite that they have an issue, a 'yum update yum; yum update' has worked fine for me
chroot'd named quit running about 05:00 yesterday morning. wouldn't restart due to permission problems.
have you opened a bug report for this ?
There was something similar mentioned by others 08/13 regarding a change released 08/11. I'm not sure why we weren't impacted until yesterday ~ 05:00.
You were affected yesterday ... Because ... it was an update for 4.4.
RH released 4.4 on 8/10
CentOS released the security updates included for 4.4 on 8/23 (bind was a bugfix update and not a security update ... it was not released on 8/23).
CentOS released the full 4.4 update set on 8/29, and since bind was a bugfix updates and not secuirty update, that is when it was released.
It is the CentOS goal to have the update set releases out 2 weeks after the update ... however due to a showstopper bug in 3.8 (the rescue CD would not work, and still does not work in the upstream product) we had to delay it's update and fix the problem. That delay caused a corresponding delay in releasing CentOS-4.4 since we can only release one major update set at a time due bandwidth considerations.
So, CentOS-4.4 was released 8/29 ... and that was 5 days past our 14 day goal.
THAT is why you saw the problem yesterday :)
So CentOS fixed a bug that upstream didn't even fix! You guys are great!! No wonder they don't mind the rebuilders. It seems to be a symbiotic relationship.
Larry Vaden spake the following on 9/1/2006 2:55 AM:
On 9/1/06, Karanbir Singh mail-lists@karan.org wrote:
look at the thread again, its only when someone does an update for only sqlite that they have an issue, a 'yum update yum; yum update' has worked fine for me
chroot'd named quit running about 05:00 yesterday morning. wouldn't restart due to permission problems.
rgds/ldv
Check to see if upgrade munged your rndc.key.
On 9/1/06, Scott Silva ssilva@sgvwater.com wrote:
Larry Vaden spake the following on 9/1/2006 2:55 AM:
On 9/1/06, Karanbir Singh mail-lists@karan.org wrote:
look at the thread again, its only when someone does an update for only sqlite that they have an issue, a 'yum update yum; yum update' has worked fine for me
chroot'd named quit running about 05:00 yesterday morning. wouldn't restart due to permission problems.
rgds/ldv
Check to see if upgrade munged your rndc.key.
After regeneration of a new key and its placement in the two necessary files, we had the permissions problem seen in the log excerpts.
rgds/ldv
-
David Hrbáč -
John Hinton -
Johnny Hughes -
Karanbir Singh -
Larry Vaden -
Scott Silva