I've updated CentOS 4.0 to 4.1 on several machines (some desktops, some servers). However on my laptop, update is failing with following error just after headers are downloaded:
--> Running transaction check --> Processing Dependency: glibc-common = 2.3.4-2 for package: glibc --> Finished Dependency Resolution Error: Missing Dependency: glibc-common = 2.3.4-2 is needed by package glibc
My CentOS.repo is a standard one, as distributed with CentOS. I don't have any additional repos defined on my laptop. I attempted to clear yum cache (rm -rf /var/cache/yum/*). Rerun yum update, and got the same error again.
Looking at the /var/cache/yum/base/headers, I see that yum downloaded headers for gblic-common, glibc-devel, and glibc-headers, but not for glibc. Seems as if yum did not considered base glibc package to be due for update. Running rpm -q glibc, shows that currently installed version of glibc is 2.3.4-2 (and all the other currently installed glibc packages are at the same version level).
I don't remember doing anything fancy on that laptop that could have triggered this problem. Basically, it was normal install (desktop+devel packages mostly), and after that it was regulary updated from cron.
Of course, as a workaround I could download glibc and related packages and update it by hand, and than rerun yum update to get all other updates from 4.1. But, I though it would be more fun if anybody could give me hint or two why yum failed to update this particular system.
On Mon, Jun 20, 2005 at 12:05:47AM -0500, Aleksandar Milivojevic enlightened us:
I've updated CentOS 4.0 to 4.1 on several machines (some desktops, some servers). However on my laptop, update is failing with following error just after headers are downloaded:
--> Running transaction check --> Processing Dependency: glibc-common = 2.3.4-2 for package: glibc --> Finished Dependency Resolution Error: Missing Dependency: glibc-common = 2.3.4-2 is needed by package glibc
My CentOS.repo is a standard one, as distributed with CentOS. I don't have any additional repos defined on my laptop. I attempted to clear yum cache (rm -rf /var/cache/yum/*). Rerun yum update, and got the same error again.
Looking at the /var/cache/yum/base/headers, I see that yum downloaded headers for gblic-common, glibc-devel, and glibc-headers, but not for glibc. Seems as if yum did not considered base glibc package to be due for update. Running rpm -q glibc, shows that currently installed version of glibc is 2.3.4-2 (and all the other currently installed glibc packages are at the same version level).
I don't remember doing anything fancy on that laptop that could have triggered this problem. Basically, it was normal install (desktop+devel packages mostly), and after that it was regulary updated from cron.
Of course, as a workaround I could download glibc and related packages and update it by hand, and than rerun yum update to get all other updates from 4.1. But, I though it would be more fun if anybody could give me hint or two why yum failed to update this particular system.
I had the same problem on a Pentium 166 machine. Is the laptop an i586 architecture? I am wondering if there is some exactarch weirdness going on with yum. I needed to get the machine up and running, so I did as you said and installed glibc and glibc-common by hand, then re-ran yum.
Matt
On Mon, 2005-06-20 at 07:22 -0400, Matt Hyclak wrote:
On Mon, Jun 20, 2005 at 12:05:47AM -0500, Aleksandar Milivojevic enlightened us:
I've updated CentOS 4.0 to 4.1 on several machines (some desktops, some servers). However on my laptop, update is failing with following error just after headers are downloaded:
--> Running transaction check --> Processing Dependency: glibc-common = 2.3.4-2 for package: glibc --> Finished Dependency Resolution Error: Missing Dependency: glibc-common = 2.3.4-2 is needed by package glibc
My CentOS.repo is a standard one, as distributed with CentOS. I don't have any additional repos defined on my laptop. I attempted to clear yum cache (rm -rf /var/cache/yum/*). Rerun yum update, and got the same error again.
Looking at the /var/cache/yum/base/headers, I see that yum downloaded headers for gblic-common, glibc-devel, and glibc-headers, but not for glibc. Seems as if yum did not considered base glibc package to be due for update. Running rpm -q glibc, shows that currently installed version of glibc is 2.3.4-2 (and all the other currently installed glibc packages are at the same version level).
I don't remember doing anything fancy on that laptop that could have triggered this problem. Basically, it was normal install (desktop+devel packages mostly), and after that it was regulary updated from cron.
Of course, as a workaround I could download glibc and related packages and update it by hand, and than rerun yum update to get all other updates from 4.1. But, I though it would be more fun if anybody could give me hint or two why yum failed to update this particular system.
I had the same problem on a Pentium 166 machine. Is the laptop an i586 architecture? I am wondering if there is some exactarch weirdness going on with yum. I needed to get the machine up and running, so I did as you said and installed glibc and glibc-common by hand, then re-ran yum.
Matt
There is a bug with work around solutions ... the glibc released by RH does not build on / for i586. Here is the bug:
http://bugs.centos.org/view.php?id=943
There is also a bug filed upstream and we continue to work on this issue.
Matt Hyclak wrote:
I had the same problem on a Pentium 166 machine. Is the laptop an i586 architecture? I am wondering if there is some exactarch weirdness going on with yum. I needed to get the machine up and running, so I did as you said and installed glibc and glibc-common by hand, then re-ran yum.
Yes, it is an Pentium MMX 233 (i586). All the other machines where update was successfull were i686.
On Mon, 2005-06-20 at 07:11 -0500, Aleksandar Milivojevic wrote:
Matt Hyclak wrote:
I had the same problem on a Pentium 166 machine. Is the laptop an i586 architecture? I am wondering if there is some exactarch weirdness going on with yum. I needed to get the machine up and running, so I did as you said and installed glibc and glibc-common by hand, then re-ran yum.
Yes, it is an Pentium MMX 233 (i586). All the other machines where update was successfull were i686. _______________________________________________
Please see my earlier post:
http://lists.centos.org/pipermail/centos/2005-June/007474.html
We will continue to support i586 as much as possible, but i586 is not supported by RHEL-4.
As I said, I have put in an upstream bug to try and have this corrected (it is a reproducible upstream error) ... and I am debugging the build issue as well.
Quoting Johnny Hughes mailing-lists@hughesjr.com:
Please see my earlier post:
http://lists.centos.org/pipermail/centos/2005-June/007474.html
We will continue to support i586 as much as possible, but i586 is not supported by RHEL-4.
As I said, I have put in an upstream bug to try and have this corrected (it is a reproducible upstream error) ... and I am debugging the build issue as well.
Thanks. I've read it just after sending my previous mail (and than had to go to work).
The problem with glibc is somewhat deeper and more complex. This is my understanding of things gathered from various sources over time (and parts may be inacurate, so if anybody can correct me, it would be splendid).
At various points in time Red Hat made some somewhat conflicting decisions. The first was that Red Hat distributions must have NPTL. For NPTL support, there are two components of system where it is implemented, kernel and glibc. Back then glibc supported NPTL only for i686. NPTL support was later backported to i586 and i486. Kernel should be fine with i486 and newer. There will never be i386 support for NPTL, since i386 lacks some assembly instructions needed to implement it effectively (NPTL i386 system would be unusably slow).
Then, Red Hat dropped i386 kernels, and continued to support i586 and i686 kernels only. However on the glibc side, i386 and i686 builds were used. This broke things badly in Fedora Core 2 for i586 machines for some packages that used Berkely DB library (most notably, Cyrus IMAPD was the most problematic package).
Now, I'm not sure if this part is urban legend or reality. Apperently they "fixed" it in Fedora Core 3. The fix was not i586 version of glibc (which would be logical, glibc is one of the few rare packages that might actually benefit from i586 instruction set, if nothing else than because of mandatory NPTL support for Red Hat distributions). What they did was to build i386 version of glibc with NPTL part using i486 instructions (at that point in time, glibc folks have already backported NPTL to i486 and i586).
Now, *if* i586 is supported architecture for distribution (are they shipping i586 kernel? what release notes for distro say?), then this should be considered as a bug. Either i386 version of glibc must be patched the same way it was allegedly patched on Fedora Core 3 (to use i486 instructions for NPTL support), or they finally need to give in and support i586 for glibc (optionally dropping i386 glibc, as they did with kernel some time ago).
What might be checked first is if FC3 NPTL fix for i386 glibc is reallity? Is it included with RHEL4 glibc?
---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
Quoting alex@milivojevic.org:
What might be checked first is if FC3 NPTL fix for i386 glibc is reallity? Is it included with RHEL4 glibc?
I just took a quick look at the RHEL4 glibc spec file. It contains lines:
%define nptlarches i386 i686 athlon x86_64 ia64 s390 s390x sparcv9 ppc ppc64
and then:
%ifarch %{nptlarches} %define enablekernelnptl 2.4.20 %ifarch i386 %define nptl_target_cpu i486 %define tls_subdir tls/i486 %else %define nptl_target_cpu %{_target_cpu} %define tls_subdir tls %endif %endif
So, I'd say just compile it for i386, and it should work correctly. It'll use i486 instructions for NPTL support. Some testing to see if NPTL is really working might be needed. That's apperently the way Red Hat is doing it, so CentOS should follow.
---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
On Mon, June 20, 2005 9:05 am, alex@milivojevic.org said:
Quoting alex@milivojevic.org:
What might be checked first is if FC3 NPTL fix for i386 glibc is reallity? Is it included with RHEL4 glibc?
I just took a quick look at the RHEL4 glibc spec file. It contains lines:
%define nptlarches i386 i686 athlon x86_64 ia64 s390 s390x sparcv9 ppc ppc64
and then:
%ifarch %{nptlarches} %define enablekernelnptl 2.4.20 %ifarch i386 %define nptl_target_cpu i486 %define tls_subdir tls/i486 %else %define nptl_target_cpu %{_target_cpu} %define tls_subdir tls %endif %endif
So, I'd say just compile it for i386, and it should work correctly. It'll use i486 instructions for NPTL support. Some testing to see if NPTL is really working might be needed. That's apperently the way Red Hat is doing it, so CentOS should follow.
RedHat doesn't support i586 support at all with CentOS-4 ... not via the kernel or glibc. CentOS (starting with version 3.3) built an i586 kernel.
CentOS-4 continued this support.
One way to support this would be to use the i386 version. Seems like what RH recommended on the upstream bug I submitted.
I can also modifiy the spec file to build an i586 glibc.
So the best thing to do at this point is probably to download and install the 4.0 glibc.i386 (glibc-2.3.4-2.i386.rpm) like this:
wget http://mirror.centos.org/centos/4.0/os/i386/CentOS/RPMS/glibc-2.3.4-2.i386.r...
rpm -Uvh --force glibc-2.3.4-2.i386.rpm
then do a normal upgrade to CentOS-4.1
yum update
On Mon, June 20, 2005 1:18 pm, Johnny Hughes said:
Quoting alex@milivojevic.org:
What might be checked first is if FC3 NPTL fix for i386 glibc is reallity? Is it included with RHEL4 glibc?
I just took a quick look at the RHEL4 glibc spec file. It contains lines:
%define nptlarches i386 i686 athlon x86_64 ia64 s390 s390x sparcv9 ppc ppc64
and then:
%ifarch %{nptlarches} %define enablekernelnptl 2.4.20 %ifarch i386 %define nptl_target_cpu i486 %define tls_subdir tls/i486 %else %define nptl_target_cpu %{_target_cpu} %define tls_subdir tls %endif %endif
So, I'd say just compile it for i386, and it should work correctly. It'll use i486 instructions for NPTL support. Some testing to see if NPTL is really working might be needed. That's apperently the way Red Hat is doing it, so CentOS should follow.
RedHat doesn't support i586 support at all with CentOS-4 ... not via the kernel or glibc. CentOS (starting with version 3.3) built an i586 kernel.
I meant with RHEL-4 :)
Johnny Hughes wrote:
So the best thing to do at this point is probably to download and install the 4.0 glibc.i386 (glibc-2.3.4-2.i386.rpm) like this:
wget http://mirror.centos.org/centos/4.0/os/i386/CentOS/RPMS/glibc-2.3.4-2.i386.r...
rpm -Uvh --force glibc-2.3.4-2.i386.rpm
Another posibility is to edit /etc/yum.conf, and change "exactarch=1" to "exactarch=0", and run "yum update glibc.i386". When it is done, edit /etc/yum.conf again, and undo the change (set "exactarch=1"). Run "yum update" to update the rest of the system.
Oh, and I'd like to thanks Bryan for extremely educative and informative mailings about i586. Well, at least to me, I still have two Intel Pentium MMX chips in working condition and powered on 24/7. One of them powering my laptop, and the other was happily running Apache, Sendmail and Cyrus IMAPD servers until about month or two ago (now being used as firewall) ;-)
-
Aleksandar Milivojevic -
alex＠milivojevic.org
-
Johnny Hughes -
Matt Hyclak