This is a continuation of the thread: "yum update fails: CentOS 5.2".
I installed a fresh Centos 5.2 and ran yum update.
It ran correctly, except for these issues:
1. As previously mentioned, after deciding what it is going to do, It doesn't ask if its ok. But if I type y<enter> it reports: Is this ok [y/N]: Downloading Packages:
2. During the long period it is downloading files, it doesn't print anything, giving the impression that nothing is happening. Watching the lights, and using WireShark and ARIN, I determined that it was downloading from the Rochester Institute of Technology. I decided that was good. During the install phase, the expected logging appeared.
3. When it said it was finished, it didn't exit the yum process; I did it with CRTL-C .
Mike.
On Mon, Jan 12, 2009 at 8:19 PM, Mike -- EMAIL IGNORED m_d_berger_1900@yahoo.com wrote:
This is a continuation of the thread: "yum update fails: CentOS 5.2".
I installed a fresh Centos 5.2 and ran yum update.
It ran correctly, except for these issues:
Okay, a few things to get out of the way first
What's the output of the following commands?
uname -a rpm -Va python* yum* sqlite* rpm -qa python*
How much ram do you have in the box? Have you installed any packages from 3rd party repositories?
On Mon, 12 Jan 2009 20:25:06 -0500, Jim Perrin wrote:
On Mon, Jan 12, 2009 at 8:19 PM, Mike -- EMAIL IGNORED m_d_berger_1900@yahoo.com wrote:
This is a continuation of the thread: "yum update fails: CentOS 5.2".
I installed a fresh Centos 5.2 and ran yum update.
It ran correctly, except for these issues:
Okay, a few things to get out of the way first
What's the output of the following commands?
uname -a rpm -Va python* yum* sqlite* rpm -qa python*
How much ram do you have in the box? Have you installed any packages from 3rd party repositories?
[root@mbrc21 ~]# uname -a Linux mbrc21 2.6.18-92.1.22.el5 #1 SMP Tue Dec 16 12:03:43 EST 2008 i686 athlon i386 GNU/Linux [root@mbrc21 ~]# rpm -Va python* yum* sqlite* [root@mbrc21 ~]# rpm -qa python* python-ldap-2.2.0-2.1 python-devel-2.4.3-21.el5 python-numeric-23.7-2.2.2 python-2.4.3-21.el5 python-iniparse-0.2.3-4.el5 python-elementtree-1.2.6-5 python-sqlite-1.1.7-1.2.1 python-urlgrabber-3.1.0-2 [root@mbrc21 ~]#
As you can see, the second command got no response.
From top:
Mem: 1035288k total
Packages from 3rd party repositories: not yet, but will soon install some.
Thanks for your help. Mike.
Bugs in yum update
please stop crying "bug" just because you have a problem! - you did not hit a bug AFAYK - you don't know if the problem is with yum update
Your symptoms make me think that you may have some package not installed. Something unrelated to yum, but related to shell, formatting, output ... Can't tell you what it could be.
I installed a fresh Centos 5.2
that means exactly what?
Kai
On Tue, 13 Jan 2009 09:31:20 +0100, Kai Schaetzl wrote:
[...]
I installed a fresh Centos 5.2
that means exactly what?
Kai
I have a DVD image of CentOS 5.2 downloaded a few months ago. It is installed on an ftp server on a nearby machine. I booted the netinstall disk and did a complete install, removing all partitions, and reformatting the hard drive.
Mike.
In article gkgq6u$5fj$1@ger.gmane.org, Mike -- EMAIL IGNORED m_d_berger_1900@yahoo.com wrote:
This is a continuation of the thread: "yum update fails: CentOS 5.2".
I installed a fresh Centos 5.2 and ran yum update.
It ran correctly, except for these issues:
As previously mentioned, after deciding what it is going to do, It doesn't ask if its ok. But if I type y<enter> it reports: Is this ok [y/N]: Downloading Packages:
During the long period it is downloading files, it doesn't print anything, giving the impression that nothing is happening. Watching the lights, and using WireShark and ARIN, I determined that it was downloading from the Rochester Institute of Technology. I decided that was good. During the install phase, the expected logging appeared.
This suggests that yum is not flushing output, possibly because it doesn't think it's stdio is on a tty.
1. Were you running yum update locally on the console, or remotely via a network connection of some kind, e.g. ssh? If you do it as a direct command to ssh (ssh myhost yum update) you might get those symptoms, unless you also give -t to ssh: ssh -t myhost yum update
2. If you were on the console, were you piping the output of yum through something else like tee? e.g. yum update | tee mylogfile If so, you might again get the same symptoms. If you want to capture the output of the session, use the script command:
# script mylogfile Script started, file is mylogfile # yum update # exit Script done, file is mylogfile #
If neither of the above is applicable, please explain exactly what you did, step by step, including what you might consider insignificant.
Cheers Tony
On Tue, 13 Jan 2009 11:18:37 +0000, Tony Mountifield wrote:
[...]
This suggests that yum is not flushing output, possibly because it doesn't think it's stdio is on a tty.
- Were you running yum update locally on the console, or remotely via a
network connection of some kind, e.g. ssh? If you do it as a direct command to ssh (ssh myhost yum update) you might get those symptoms, unless you also give -t to ssh: ssh -t myhost yum update
- If you were on the console, were you piping the output of yum through
something else like tee? e.g. yum update | tee mylogfile If so, you might again get the same symptoms. If you want to capture the output of the session, use the script command:
# script mylogfile Script started, file is mylogfile # yum update # exit Script done, file is mylogfile #
If neither of the above is applicable, please explain exactly what you did, step by step, including what you might consider insignificant.
Cheers Tony
On the local console, I did: yum update 2>&1 | tee log so, as you say, that might account for the problem. But it is not clear to me why this would be so. I'll try the script suggestion.
FWIW, the missing output did not appear in the log file.
Thanks, Mike.
On Tue, 2009-01-13 at 15:00 +0000, Mike -- EMAIL IGNORED wrote:
On Tue, 13 Jan 2009 11:18:37 +0000, Tony Mountifield wrote:
[...]
This suggests that yum is not flushing output, possibly because it doesn't think it's stdio is on a tty.
- Were you running yum update locally on the console, or remotely via a
network connection of some kind, e.g. ssh? If you do it as a direct command to ssh (ssh myhost yum update) you might get those symptoms, unless you also give -t to ssh: ssh -t myhost yum update
- If you were on the console, were you piping the output of yum through
something else like tee? e.g. yum update | tee mylogfile If so, you might again get the same symptoms. If you want to capture the output of the session, use the script command:
# script mylogfile Script started, file is mylogfile # yum update # exit Script done, file is mylogfile #
If neither of the above is applicable, please explain exactly what you did, step by step, including what you might consider insignificant.
Cheers Tony
On the local console, I did: yum update 2>&1 | tee log so, as you say, that might account for the problem. But it is not clear to me why this would be so. I'll try the script suggestion.
It's because _normal_ terminal output is terminated by a new line character and the prompt "... this OK" is _not_. So tee, expecting newlines as one of the things it can act upon, dutifully waits for the new line character. Also, it is common programming practice to issue prompts on stderr (or some other file descriptor not being stdin, stdout or stderr) so that stdout can be captured while the stderr will still appear upon a "console".
When you redirected stderr, with 2>&1 (btw, &> is shorthand for that) you effectively "buffered" the prompt while tee awaited a new line character.
FWIW, the missing output did not appear in the log file.
Thanks, Mike.
I know that doesn't help do what you want, but I thought the explanation might be useful to you.
<snip sig stuff>
On Tue, Jan 13, 2009 at 10:36:03AM -0500, William L. Maltby wrote:
When you redirected stderr, with 2>&1 (btw, &> is shorthand for that)
&> is a csh-ism and also in bash. It's not correct in other sh-like shells, so don't use it if you want to do portable programming. In particular don't use it in profile.d (Fedora 10, I'm looking at you!) ecause people using ksh (for example) as their shell will get errors.
On Tue, 2009-01-13 at 10:40 -0500, Stephen Harris wrote:
On Tue, Jan 13, 2009 at 10:36:03AM -0500, William L. Maltby wrote:
When you redirected stderr, with 2>&1 (btw, &> is shorthand for that)
&> is a csh-ism and also in bash. It's not correct in other sh-like shells, so don't use it if you want to do portable programming. In particular don't use it in profile.d (Fedora 10, I'm looking at you!) ecause people using ksh (for example) as their shell will get errors.
On top of that, I inadvertently ignored the fact that stdout was being piped. In that case the "shorthand" does not do what is wanted. It is really only appropriate when sending the two outputs to a file.
-
Jim Perrin -
Kai Schaetzl -
Mike -- EMAIL IGNORED -
Stephen Harris -
tony＠softins.clara.co.uk -
William L. Maltby