Problem with glibc library on Distro upgrade

Hello,

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

How can I fix this?

FreePBX Distro 6.12.65-24

Thank you in advace,
esarant

I believe this is something with the FreePBX repo since the current glibc is from Centos Repo and the update is from FreePBX repo.

Just to update, this also happening to another installation of FreePBX distro upgraded from 5 to 6 track (current version 6.12.65-24)

A few people have reported this but I have not been able to replicate it on any of our machines.

Just to say that this is also affecting my installations :frowning:

[root@pbx ~]# 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

Your machine is confused. It’s trying to upgrade an i686 arch package with an x86_64 package.

Is your machine 64 bit, or 32 bit?

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

[root@pbx ~]# cat /etc/schmooze-release
SHMZ release 6.5 (Final)

Linux pbx.fido.net 2.6.32-431.el6.x86_64 #1 SMP Fri Nov 22 03:15:09 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

Now just has a single repo which is the Schmooze repo

fyi the fix to this seems to be

yum remove glibc-2.12-1.132.el6_5.4.i686

which removes sysadmin and incron as well as glibc i686

You then do a yum install sysadmin and and a yum update to update glibc, and all seems to be back to normal

2 Likes

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:

[root@pbx ~]# 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.

Your help is greatly appreciated!

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?) :smile: I’m pretty sure I reverted the snapshot before anyone noticed. :wink:

This is probably meaningful:

[root@pbx ~]# yum list installed | grep glibc
glibc.x86_64            2.12-1.132.el6_5.4 @updates
glibc-common.x86_64     2.12-1.132.el6_5.4 @updates
glibc-common.x86_64     2.12-1.149.shmz65.1.1
glibc-devel.x86_64      2.12-1.132.el6_5.4 @updates
glibc-headers.x86_64    2.12-1.132.el6_5.4 @updates

OK, this totally worked:

yum remove glibc-common-2.12-1.149.shmz65.1.1.x86_64

This explicitly removed “glibc-common-2.12-1.149.shmz65.1.1.x86_64” but no dependencies or any other packages.

I then ran “yum update” which installed the following packages:

glibc-2.12-1.149.shmz65.1.1.x86_64.rpm
glibc-common-2.12-1.149.shmz65.1.1.x86_64.rpm
glibc-devel-2.12-1.149.shmz65.1.1.x86_64.rpm
glibc-headers-2.12-1.149.shmz65.1.1.x86_64.rpm
libopenr2-1.3.3-1.shmz65.1.4.x86_64.rpm
sysadmin-2.7.0-202.shmz65.1.18.noarch.rpm

Now I get this:

[root@pbx ~]# yum list installed | grep glibc
glibc.x86_64            2.12-1.149.shmz65.1.1
glibc-common.x86_64     2.12-1.149.shmz65.1.1
glibc-devel.x86_64      2.12-1.149.shmz65.1.1
glibc-headers.x86_64    2.12-1.149.shmz65.1.1

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.

1 Like

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.

Anyhow, I downloaded and installed http://upgrades.freepbxdistro.org/stable/6.12.65/upgrade-6.12.65-25.sh and the script ran without incident. My system now shows 6.12.65-25.

Should I write this off as a one-time thing, or is the problem with running the automatic updater in the sysadmin module likely a permanent issue?

My problems were solved on all of my FreePBX distro after @tonyclewis added the 32bit RPMS to the 64bit repo 4days ago.

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.

Thanks for the reply Tony! If that’s the case, why did my problem start early last week, and I was still unable to automatically fix it even yesterday? I’m not trying to cast aspersions towards you or the other fine folks at Sangoma; (née Schmooze) You guys do a tremendous job developing and maintaining a truly phenomenal product, which I love and regularly proselytize. I’m just trying to better understand the inner workings of the package manager. I admit that I don’t fully understand what the problem was, and why my actions above fixed the problem. That bothers me a little. :smile:

Thanks again!