I am facing a problem with glibc librady. I upgraded a FreePBX Distro from 5 track to 6 track. Everything is ok expect the part that yum update does not run and I get the following error:
yum update
Loaded plugins: fastestmirror, kmod
Loading mirror speeds from cached hostfile
Setting up Update Process
Resolving Dependencies
--> Running transaction check
---> Package glibc.x86_64 0:2.12-1.132.el6_5.4 will be updated
---> Package glibc.x86_64 0:2.12-1.149.shmz65.1.1 will be an update
---> Package glibc-common.x86_64 0:2.12-1.132.el6_5.4 will be updated
--> Processing Dependency: glibc-common = 2.12-1.132.el6_5.4 for package: glibc-2.12-1.132.el6_5.4.i686
---> Package glibc-common.x86_64 0:2.12-1.149.shmz65.1.1 will be an update
---> Package glibc-devel.x86_64 0:2.12-1.132.el6_5.4 will be updated
---> Package glibc-devel.x86_64 0:2.12-1.149.shmz65.1.1 will be an update
---> Package glibc-headers.x86_64 0:2.12-1.132.el6_5.4 will be updated
---> Package glibc-headers.x86_64 0:2.12-1.149.shmz65.1.1 will be an update
--> Finished Dependency Resolution
Error: Package: glibc-2.12-1.132.el6_5.4.i686 (@updates)
Requires: glibc-common = 2.12-1.132.el6_5.4
Removing: glibc-common-2.12-1.132.el6_5.4.x86_64 (@updates)
glibc-common = 2.12-1.132.el6_5.4
Updated By: glibc-common-2.12-1.149.shmz65.1.1.x86_64 (pbx)
glibc-common = 2.12-1.149.shmz65.1.1
Available: glibc-common-2.12-1.132.el6.x86_64 (base)
glibc-common = 2.12-1.132.el6
Available: glibc-common-2.12-1.132.el6_5.1.x86_64 (updates)
glibc-common = 2.12-1.132.el6_5.1
Available: glibc-common-2.12-1.132.el6_5.2.x86_64 (updates)
glibc-common = 2.12-1.132.el6_5.2
Available: glibc-common-2.12-1.132.el6_5.3.x86_64 (updates)
glibc-common = 2.12-1.132.el6_5.3
You could try using --skip-broken to work around the problem
Just to say that this is also affecting my installations
[[email protected] ~]# yum update
Loaded plugins: auto-update-debuginfo, fastestmirror, kmod
Loading mirror speeds from cached hostfile
Setting up Update Process
Resolving Dependencies
–> Running transaction check
—> Package glibc.x86_64 0:2.12-1.132.el6_5.4 will be updated
—> Package glibc.x86_64 0:2.12-1.149.shmz65.1.1 will be an update
—> Package glibc-common.x86_64 0:2.12-1.132.el6_5.4 will be updated
–> Processing Dependency: glibc-common = 2.12-1.132.el6_5.4 for package: glibc-2.12-1.132.el6_5.4.i686
—> Package glibc-common.x86_64 0:2.12-1.149.shmz65.1.1 will be an update
—> Package glibc-devel.x86_64 0:2.12-1.132.el6_5.4 will be updated
—> Package glibc-devel.x86_64 0:2.12-1.149.shmz65.1.1 will be an update
—> Package glibc-headers.x86_64 0:2.12-1.132.el6_5.4 will be updated
—> Package glibc-headers.x86_64 0:2.12-1.149.shmz65.1.1 will be an update
–> Finished Dependency Resolution
Error: Package: glibc-2.12-1.132.el6_5.4.i686 (@updates)
Requires: glibc-common = 2.12-1.132.el6_5.4
Removing: glibc-common-2.12-1.132.el6_5.4.x86_64 (@updates)
glibc-common = 2.12-1.132.el6_5.4
Updated By: glibc-common-2.12-1.149.shmz65.1.1.x86_64 (updates)
glibc-common = 2.12-1.149.shmz65.1.1
Available: glibc-common-2.12-1.132.el6.x86_64 (base)
glibc-common = 2.12-1.132.el6
Available: glibc-common-2.12-1.132.el6_5.1.x86_64 (updates)
glibc-common = 2.12-1.132.el6_5.1
Available: glibc-common-2.12-1.132.el6_5.2.x86_64 (updates)
glibc-common = 2.12-1.132.el6_5.2
Available: glibc-common-2.12-1.132.el6_5.3.x86_64 (updates)
glibc-common = 2.12-1.132.el6_5.3
You could try using --skip-broken to work around the problem
You could try running: rpm -Va --nofiles --nodigest
All of them are x86_64 built as CentOS 6.x (64 bit) boxes … and then upgraded / adopted as Schmooze boxes (converted a year or so back using the “supported” (recommended?) method
OK so it did not start out as a real Distro. You converted it some how?? Anyways I added the 32bit RPMs to our 64bit repos to solve this moving forward for users who have a 64bit machine with 32bit glibc installed.
I’m having the exact same issue. As I recall, I think that I, too, set this up originally as a CentOS machine, but ran the “conversion” script very early on. Below is the output of my update attempt:
[[email protected] ~]# yum update --skip-broken
Loaded plugins: fastestmirror, kmod
Loading mirror speeds from cached hostfile
Setting up Update Process
Resolving Dependencies
--> Running transaction check
---> Package glibc.x86_64 0:2.12-1.132.el6_5.4 will be updated
--> Processing Dependency: glibc = 2.12-1.132.el6_5.4 for package: glibc-common-2.12-1.132.el6_5.4.x86_64
---> Package glibc.x86_64 0:2.12-1.149.shmz65.1.1 will be an update
---> Package glibc-devel.x86_64 0:2.12-1.132.el6_5.4 will be updated
---> Package glibc-devel.x86_64 0:2.12-1.149.shmz65.1.1 will be an update
---> Package glibc-headers.x86_64 0:2.12-1.132.el6_5.4 will be updated
---> Package glibc-headers.x86_64 0:2.12-1.149.shmz65.1.1 will be an update
---> Package libopenr2.x86_64 0:1.3.2-5_centos6 will be updated
---> Package libopenr2.x86_64 0:1.3.3-1.shmz65.1.4 will be an update
---> Package sysadmin.noarch 0:2.7.0-201.shmz65.1.16 will be updated
---> Package sysadmin.noarch 0:2.7.0-202.shmz65.1.18 will be an update
--> Running transaction check
---> Package glibc.i686 0:2.12-1.132.el6_5.4 will be installed
--> Processing Dependency: libfreebl3.so(NSSRAWHASH_3.12.3) for package: glibc-2.12-1.132.el6_5.4.i686
--> Processing Dependency: libfreebl3.so for package: glibc-2.12-1.132.el6_5.4.i686
---> Package glibc.x86_64 0:2.12-1.132.el6_5.4 will be updated
--> Running transaction check
---> Package nss-softokn-freebl.i686 0:3.14.3-12.el6_5 will be installed
--> Finished Dependency Resolution
Error: Multilib version problems found. This often means that the root
cause is something else and multilib version checking is just
pointing out that there is a problem. Eg.:
1. You have an upgrade for glibc which is missing some
dependency that another package requires. Yum is trying to
solve this by installing an older version of glibc of the
different architecture. If you exclude the bad architecture
yum will tell you what the root cause is (which package
requires what). You can try redoing the upgrade with
--exclude glibc.otherarch ... this should give you an error
message showing the root cause of the problem.
2. You have multiple architectures of glibc installed, but
yum can only see an upgrade for one of those arcitectures.
If you don't want/need both architectures anymore then you
can remove the one with the missing update and everything
will work.
3. You have duplicate versions of glibc installed already.
You can use "yum check" to get yum show these errors.
...you can also use --setopt=protected_multilib=false to remove
this checking, however this is almost never the correct thing to
do as something else is very likely to go wrong (often causing
much more problems).
Protected multilib versions: glibc-2.12-1.132.el6_5.4.i686 != glibc-2.12-1.149.shmz65.1.1.x86_64
** Found 2 pre-existing rpmdb problem(s), 'yum check' output follows:
glibc-common-2.12-1.149.shmz65.1.1.x86_64 is a duplicate with glibc-common-2.12-1.132.el6_5.4.x86_64
glibc-common-2.12-1.149.shmz65.1.1.x86_64 has missing requires of glibc = ('0', '2.12', '1.149.shmz65.1.1')
So, from the error above, it appears that glibc-2.12-1.149.shmz65.1.1.x86_64 is trying to update glibc-2.12-1.132.el6_5.4.i686, which I understand to be problematic.
I tried several different attempts to use yum to remove different packages, but every one of them resulted in a wall of text warning me of the dangers of uninstalling glibc. (which I completely appreciate.)
Is there a safer way to remove the just the offending version of glibc, then immediately install the good version? Removing glibc breaks yum, so that certainly wouldn’t do it. I didn’t try very hard to coax yum into removing any packages, for obvious reasons.
Incidentally, “yum remove glibc-2.12-1.132.el6_5.4.i686” mentioned above, produces “Package(s) glibc-2.12-1.132.el6_5.4.i686 available, but not installed.” Attempting to use yum to remove “glibc-2.12-1.132.el6_5.4.x86_64” results in some stern warnings about dependencies. (Mentioned above)
I got brave, took a VM snapshot, and while most everyone was at lunch, ran: “rpm --erase --nodeps glibc-2.12-1.132.el6_5.4.x86_64” which, as I suspected, resulted in a script error, as well as completely breaking every aspect of the system, including yum. (which I suspected would happen - thank goodness for shapshots, amirite?) I’m pretty sure I reverted the snapshot before anyone noticed.
which looks to be a little more normal. Also, yum update runs normally now, without any errors. Hopefully, this is applicable to anyone else out there with the same problem.
Removing the offending glibc install did remove sysadmin, which was automatically re-installed on the first “yum update,” but did not seem to touch the incrond package. Mine is incron-0.5.9-2.el6.rf.x86_64, if that’s relevant to anyone.
I took a look through, and noticed that my system hadn’t yet been updated to 6.12.65-25. I looked at the release notes for -25, and noticed that the second item was “Update glibc”
This can’t be a coincidence…
So I went to the sysadmin module, and despite being released almost two weeks ago, it hasn’t yet updated. (It missed two update cycles.) I tried to manually update the system, but I clicked on the button, and it did nothing. I tried reloading and AMPORTAL restart, but it was no good. (I stopped short of rebooting, because this is during production hours, I’m not going to poke that bear…) When I clicked the “Update” button in sysadmin, freepbx.log spit out this message:
[2015-Feb-26 15:10:00] [PHP-NOTICE] (/var/www/html/admin/libraries/view.functions.php:57) - Undefined variable: amp_conf
[2015-Feb-26 15:10:00] [PHP-WARNING] (/var/www/html/admin/modules/cxpanel/brand.php:3) - file_get_contents(/etc/schmooze/operator-panel-brand): failed to open stream: No such file or directory
[2015-Feb-26 15:10:00] [WARNING] (libraries/modulefunctions.legacy.php:7) - Depreciated Function module_getinfo detected in /var/www/html/admin/modules/cxpanel/functions.inc.php on line 48
[2015-Feb-26 15:10:00] [PHP-NOTICE] (/var/www/html/admin/modules/sysadmin/functions.inc/updates.php:133) - fopen(): Content-type not specified assuming application/x-www-form-urlencoded
[2015-Feb-26 15:10:01] [PHP-NOTICE] (/var/www/html/admin/modules/sysadmin/functions.inc/updates.php:133) - fopen(): Content-type not specified assuming application/x-www-form-urlencoded
[2015-Feb-26 15:10:02] [PHP-NOTICE] (/var/www/html/admin/libraries/view.functions.php:57) - Undefined variable: amp_conf
[2015-Feb-26 15:10:02] [PHP-NOTICE] (/var/www/html/admin/libraries/view.functions.php:406) - Undefined variable: mod_version_tag
[2015-Feb-26 15:10:02] [PHP-NOTICE] (/var/www/html/admin/libraries/view.functions.php:57) - Undefined variable: amp_conf
[2015-Feb-26 15:10:02] [PHP-NOTICE] (/var/www/html/admin/libraries/view.functions.php:57) - Undefined variable: amp_conf
Not sure if that’s a smoking gun, but thought it might be relevant.
Sorry guys thought I updated this thread. Yes I added the 32bit Packages to the 64bit repos even though that is just crazy enough people who converted their CentOS machines to FreePBX Distro were having issues.
I’m pretty sure I reverted the snapshot before anyone noticed. 