It doesn’t appear to be an outdated version of glibc… it’s the same version that you have now.
The difference seems to be that it’s trying to install an i686 version of glibc, when you already have the 64 bit (x86_64) version installed.
That likely means that you have some i386/i686 packages on your system that are generating dependencies for 32 bit packages. And your repository likely isn’t setup to install 32 bit software.
That can be a tricky problem to solve, but there’s some details on how to hunt down those issues in the doc section here titled “Why Is 32bit Perl installed on my 64bit CentOS System”:
This means I have no 32 bit packages installed, correct?
Also note that on the CentOS forum it seems this guy is saying that the Virtualmin repo is to blame for the problem (look at post #6 in the discussion)
This means I have no 32 bit packages installed, correct?
It would seem so, that’s correct.
Also note that on the CentOS forum it seems this guy is saying that the Virtualmin repo is to blame for the problem (look at post #6 in the discussion)
I’m unfortunately unable to reproduce the problem you’re seeing.
Using a standard CentOS 6 64 bit system, installed with the install.sh script, I performed an install of the httpd-devel package with no problems.
I didn’t receive any errors, and it didn’t attempt to install any 32 bit packages, as it’s trying to do on your system.
That suggests to me that the httpd-devel package isn’t the culprit… that there’s likely some other package installed on your system that is incorrectly generating a dependency for the wrong architecture.
I’ve seen that occur in the past when there’s a 32 bit package installed… but that doesn’t appear to be the case in your situation.
Two thoughts I have are –
You could try running a “yum clean all”, just to make sure there’s no problem with the yum cache. That seems rather unlikely, but it’s quick and simple to verify that
What output do you get if you run the command “uname -a”? It wouldn’t hurt to make sure you’re currently using a 64 bit kernel.
Hitting exactly the same issue with clean 6.3 CentOS and Virtualmin built with install script.
uname -a
Linux host.mysite.com 2.6.32-279.5.2.el6.x86_64 #1 SMP Fri Aug 24 01:07:11 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
I don’t know if this is related too, but I can’t install neither Varnish
yum install varnish
Loaded plugins: fastestmirror, presto, priorities
Loading mirror speeds from cached hostfile
* base: mirror.raystedman.net
* epel: mirrors.kernel.org
* extras: mirrors.kernel.org
* rpmforge: mirror.hmc.edu
* updates: centos.mirror.facebook.net
1788 packages excluded due to repository priority protections
Setting up Install Process
Resolving Dependencies
--> Running transaction check
---> Package varnish.x86_64 0:3.0.3-1.el5.centos will be installed
--> Processing Dependency: varnish-libs = 3.0.3-1.el5.centos for package: varnish-3.0.3-1.el5.centos.x86_64
--> Processing Dependency: gcc for package: varnish-3.0.3-1.el5.centos.x86_64
--> Processing Dependency: libvarnishapi.so.1(LIBVARNISHAPI_1.0)(64bit) for package: varnish-3.0.3-1.el5.centos.x86_64
--> Processing Dependency: libvarnishapi.so.1()(64bit) for package: varnish-3.0.3-1.el5.centos.x86_64
--> Running transaction check
---> Package gcc.x86_64 0:4.4.6-4.el6 will be installed
--> Processing Dependency: libgomp = 4.4.6-4.el6 for package: gcc-4.4.6-4.el6.x86_64
--> Processing Dependency: cpp = 4.4.6-4.el6 for package: gcc-4.4.6-4.el6.x86_64
--> Processing Dependency: glibc-devel >= 2.2.90-12 for package: gcc-4.4.6-4.el6.x86_64
--> Processing Dependency: cloog-ppl >= 0.15 for package: gcc-4.4.6-4.el6.x86_64
--> Processing Dependency: libgomp.so.1()(64bit) for package: gcc-4.4.6-4.el6.x86_64
---> Package varnish-libs.x86_64 0:3.0.3-1.el5.centos will be installed
--> Running transaction check
---> Package cloog-ppl.x86_64 0:0.15.7-1.2.el6 will be installed
--> Processing Dependency: libppl_c.so.2()(64bit) for package: cloog-ppl-0.15.7-1.2.el6.x86_64
--> Processing Dependency: libppl.so.7()(64bit) for package: cloog-ppl-0.15.7-1.2.el6.x86_64
---> Package cpp.x86_64 0:4.4.6-4.el6 will be installed
--> Processing Dependency: libmpfr.so.1()(64bit) for package: cpp-4.4.6-4.el6.x86_64
---> Package glibc-devel.x86_64 0:2.12-1.80.el6 will be installed
--> Processing Dependency: glibc-headers = 2.12-1.80.el6 for package: glibc-devel-2.12-1.80.el6.x86_64
--> Processing Dependency: glibc = 2.12-1.80.el6 for package: glibc-devel-2.12-1.80.el6.x86_64
--> Processing Dependency: glibc-headers for package: glibc-devel-2.12-1.80.el6.x86_64
---> Package libgomp.x86_64 0:4.4.6-4.el6 will be installed
--> Running transaction check
---> Package glibc.i686 0:2.12-1.80.el6 will be installed
--> Processing Dependency: glibc-common = 2.12-1.80.el6 for package: glibc-2.12-1.80.el6.i686
--> Processing Dependency: libfreebl3.so(NSSRAWHASH_3.12.3) for package: glibc-2.12-1.80.el6.i686
--> Processing Dependency: libfreebl3.so for package: glibc-2.12-1.80.el6.i686
---> Package glibc-headers.x86_64 0:2.12-1.80.el6 will be installed
--> Processing Dependency: kernel-headers >= 2.2.1 for package: glibc-headers-2.12-1.80.el6.x86_64
--> Processing Dependency: kernel-headers for package: glibc-headers-2.12-1.80.el6.x86_64
---> Package mpfr.x86_64 0:2.4.1-6.el6 will be installed
---> Package ppl.x86_64 0:0.10.2-11.el6 will be installed
--> Running transaction check
---> Package glibc.i686 0:2.12-1.80.el6 will be installed
--> Processing Dependency: glibc-common = 2.12-1.80.el6 for package: glibc-2.12-1.80.el6.i686
---> Package kernel-headers.x86_64 0:2.6.32-279.el6 will be installed
---> Package nss-softokn-freebl.i686 0:3.12.9-11.el6 will be installed
--> Finished Dependency Resolution
Error: Package: glibc-2.12-1.80.el6.i686 (base)
Requires: glibc-common = 2.12-1.80.el6
Installed: glibc-common-2.12-1.80.el6_3.5.x86_64 (@updates)
glibc-common = 2.12-1.80.el6_3.5
Available: glibc-common-2.12-1.80.el6.x86_64 (base)
glibc-common = 2.12-1.80.el6
You could try using --skip-broken to work around the problem
You could try running: rpm -Va --nofiles --nodigest
or Memcached
yum install php php-pecl-memcached
Loaded plugins: fastestmirror, presto, priorities
Loading mirror speeds from cached hostfile
* base: mirror.raystedman.net
* epel: mirrors.kernel.org
* extras: mirrors.kernel.org
* rpmforge: mirror.hmc.edu
* updates: centos.mirror.facebook.net
1788 packages excluded due to repository priority protections
Setting up Install Process
Package matching php-5.3.3-3.el6_2.8.x86_64 already installed. Checking for update.
Resolving Dependencies
--> Running transaction check
---> Package php-pecl-memcached.x86_64 0:1.0.0-1.el5 will be installed
--> Processing Dependency: php-zend-abi = 20050922 for package: php-pecl-memcached-1.0.0-1.el5.x86_64
--> Processing Dependency: libmemcached.so.2(libmemcached_2)(64bit) for package: php-pecl-memcached-1.0.0-1.el5.x86_64
--> Processing Dependency: libmemcached.so.2()(64bit) for package: php-pecl-memcached-1.0.0-1.el5.x86_64
--> Running transaction check
---> Package libmemcached.x86_64 0:0.31-1.1.el6 will be installed
---> Package php-pecl-memcached.x86_64 0:1.0.0-1.el5 will be installed
--> Processing Dependency: php-zend-abi = 20050922 for package: php-pecl-memcached-1.0.0-1.el5.x86_64
--> Finished Dependency Resolution
Error: Package: php-pecl-memcached-1.0.0-1.el5.x86_64 (epel)
Requires: php-zend-abi = 20050922
Installed: php-common-5.3.3-14.el6_3.x86_64 (@updates)
php-zend-abi = 20090626
Available: php-common-5.3.3-3.el6_2.8.x86_64 (base)
php-zend-abi = 20090626
You could try using --skip-broken to work around the problem
You could try running: rpm -Va --nofiles --nodigest
which is very much unpleasant, because my customers has already migrated his website to the server (so I can’t revert to the earlier version of Virtualmin) and no cache tool can be configured now.
Eddie, if you have resolved the issue, could you please share your way?
Eric, could you please tell me how to be in this situation. I am ready to proceed to with formatting my hard disk and installation of Virtualmin once again, but I am afraid will find myself in the same situation again.
The current installation has been performed on a clean CentOS 6.3 server and with install.sh script. My repolist is as follows:
updates: centos.mirror.facebook.net
1788 packages excluded due to repository priority protections
repo id repo name status
base CentOS-6 - Base 6,346
epel Extra Packages for Enterprise Linux 5 - x86_64 6,085+1,064
extras CentOS-6 - Extras 4
rpmforge RHEL 6 - RPMforge.net - dag 4,356+78
updates CentOS-6 - Updates 0+646
varnish-3.0 Varnish 3.0 for Enterprise Linux 5 - x86_64 44
virtualmin Red Hat Enterprise 6 - x86_64 - Virtualmin 74
virtualmin-universal Virtualmin Distribution Neutral 188+1
repolist: 17,097
#additional packages that may be useful
[extras]
name=CentOS-$releasever - Extras
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=extras
#baseurl=http://mirror.centos.org/centos/$releasever/extras/$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6
#additional packages that extend functionality of existing packages
[centosplus]
name=CentOS-$releasever - Plus
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=centosplus
#baseurl=http://mirror.centos.org/centos/$releasever/centosplus/$basearch/
gpgcheck=1
enabled=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6
#additional packages that may be useful
[extras]
name=CentOS-$releasever - Extras
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=extras
#baseurl=http://mirror.centos.org/centos/$releasever/extras/$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6
priority=3
#additional packages that extend functionality of existing packages
[centosplus]
name=CentOS-$releasever - Plus
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=centosplus
#baseurl=http://mirror.centos.org/centos/$releasever/centosplus/$basearch/
gpgcheck=1
enabled=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6
priority=3
Eric, could you please tell me how to be in this situation. I am ready to proceed to with formatting my hard disk and installation of Virtualmin once again, but I am afraid will find myself in the same situation again.
Yeah, sorting out dependency issues can be a tricky one… I unfortunately don’t know what to tell you to do to fix what you’re seeing.
All I can offer is that we don’t typically see those sorts of issues except when third party repositories are in use.
I really wish I could offer you more advice, I just don’t have much experience with the combination of repositories and software you’re working on setting up there.
I’ll offer that if you ever did find yourself with a freshly installed distribution – where possible, I’d highly recommend not enabling any third party repos.
And then, if there’s a particular app you really need – to not enable the entire third party repo, but to only install the app you need from that particular repository.
yngens, i havent solved the problem. sorry it took me so long to reply, i’ve been on vacation where net access is extremely difficult (which can be a blessing sometimes:)
eric, not using other repos is sometimes, as in my case, impossible. the other repo (asl) tells me the same thing “do not use other repos”. people need to realize that just isnt possible in some cases. in my case, I either have a secure server (asl) or an easy to manage server (virtualmin) (nevermind the guy at centOS forums who told me to use only the CentOS repo). sorry, but i want both and it should be possible to have both. this issue reminds me of windows “DLL hell”. in fact, from my limited end user understanding, it is the same thing.
I cannot do a fresh install. i would like to clean up what I have, where do I seek help!? I am willing to pay for a virtualmin sub if that’s what it requires.
I hope you enjoyed your vacation! Being without the Net can indeed be enjoyable
I completely understand your predicament. I’m not at all saying it’s wrong to want to use ASL, and I’m sure it’s an awesome product.
Our predicament at Virtualmin is just that using multiple third-party RPM repositories really can cause conflicts, since some packages aren’t designed to work together.
We’re unfortunately not familiar with how to resolve the issues you’re seeing, as we’re not familiar with the packages provided in the repositories in question. Although I’d like to think that it could work, it’s possible it won’t.
Different repositories have different goals, and we know of a number packages in third party repositories that simply can’t be installed together, as the packages in them require conflicting dependencies.
Sorting all that out is going to require someone with expertise in RPM-based systems, who can sit down and work through the various errors you’re getting while trying to merge those repositories.
If you don’t have someone on your team who feels comfortable doing that, you may need to hire someone who can assist you with that. One example of how to do that would be to post a note in the Jobs forum here.
Sorry that we can’t be of more help! But the problems you’re trying to solve can be remarkably tricky, and there’s no guarantee that packages in different third-party repositories can work together :-/