2.6.1 101_centos6 ERROR: Unable to install sysadmin

Dear All,

I performed an update today using module Admin in response to the messages on the status screen informing me that new updates were available. I have always performed updates as soon as possible, usually without problems.

Today, however, I received the following message:
2.6.1 101_centos6
ERROR: Unable to install sysadmin. The sysadmin RPM you have installed is too old. Please update the sysadmin rpm via the command line, using yum install sysadmin
The following error(s) occured:

  • Failed to run installation scripts

Following this error, the entry on the Module Admin page now says: System Admin Schmoozecom.com Disabled; Pending upgrade to

I have followed instructions as far as my limited knowledge is able on another recent thread which suggested yum install lsof and then yum update sysadmin.

lsof installed without problems by the yum update failed with the following message:
~# yum update sysadmin
/usr/lib/yum-plugins/kmod.py:25: DeprecationWarning: the sets module is deprecated
from sets import Set, ImmutableSet
Loaded plugins: fastestmirror, kmod, refresh-packagekit
Loading mirror speeds from cached hostfile

yum install sysadmin results in:
~# yum install sysadmin
/usr/lib/yum-plugins/kmod.py:25: DeprecationWarning: the sets module is deprecated
from sets import Set, ImmutableSet
Loaded plugins: fastestmirror, kmod, refresh-packagekit
Loading mirror speeds from cached hostfile

I am no expert on linux and have reached the end of my abilities to try and fix this.

Any further help would be appreciated.

Kind regards,


Will be interesting to see which repositories your system has configured (post the result of: cat /etc/yum.repos.d/FreePBX.repo).
Eventually perfom (three commands below could be used to clear up the yum cache):

yum clean all
rpm --rebuilddb
yum repolist

and post the result of:

yum list sysadmin

Are you running FreePBX Distro (the distribution) or FreePBX was installed on a stock CentOS distribution? If so (FreePBX Distro), could you post the result of:

cat /etc/schmooze/pbx-version


uname -ar

This to help to better define your system.

Many thanks Parnassus for your guidance. Here is the output as requested:

cat /etc/yum.repos.d/FreePBX.repo
# FreePBX-Base.repo

If the mirrorlist= does not work for you, as a fall back you can try the

remarked out baseurl= line instead.

name=CentOS-$releasever - Base

#released updates
name=CentOS-$releasever - Updates

#additional packages that may be useful
name=CentOS-$releasever - Extras

#additional packages that extend functionality of existing packages
name=CentOS-$releasever - Plus

#Core PBX Packages

yum repolist
/usr/lib/yum-plugins/kmod.py:25: DeprecationWarning: the sets module is deprecat ed
from sets import Set, ImmutableSet
Loaded plugins: fastestmirror, kmod, refresh-packagekit
Determining fastest mirrors
epel/metalink | 15 kB 00:00

  • Webmin: download.webmin.com
  • epel: mirrors.servercentral.net
  • remi: rpms.famillecollet.com
  • rpmforge: mirror.team-cymru.org
    http://download.webmin.com/download/yum/repodata/repomd.xml: [Errno 14] PYCURL ERROR 7 - "couldn’t connect to host"
    Trying other mirror.
    Webmin | 951 B 00:00
    Webmin/primary | 20 kB 00:00
    Webmin 162/162
    base | 2.0 kB 00:00
    base/primary | 2.5 MB 00:01
    base 6294/6294
    epel | 4.2 kB 00:00
    epel/primary_db | 5.6 MB 00:03
    extras | 1.3 kB 00:00
    extras/primary | 2.8 kB 00:00
    extras 6/6
    google-chrome | 951 B 00:00
    google-chrome/primary | 1.9 kB 00:00
    google-chrome 3/3
    nikoforge | 1.3 kB 00:00
    nikoforge/primary | 3.8 kB 00:00
    nikoforge 8/8
    pbx | 1.3 kB 00:00
    pbx/primary | 39 kB 00:00
    pbx 121/121
    poptop-stable | 2.2 kB 00:00
    poptop-stable/primary_db | 5.4 kB 00:00
    pptp-stable | 2.2 kB 00:00
    pptp-stable/primary_db | 18 kB 00:00
    remi | 2.9 kB 00:00
    remi/primary_db | 581 kB 00:01
    repos.openvpn.net-CentOS6-snapshots | 951 B 00:00
    repos.openvpn.net-CentOS6-snapshots/primary | 3.9 kB 00:00
    repos.openvpn.net-CentOS6-snapshots 21/21
    repos.openvpn.net-Fedora16-snapshots | 951 B 00:00
    repos.openvpn.net-Fedora16-snapshots/primary | 4.0 kB 00:00
    repos.openvpn.net-Fedora16-snapshots 23/23
    rpmforge | 1.9 kB 00:00
    rpmforge/primary_db | 2.6 MB 00:01
    updates | 1.3 kB 00:00
    updates/primary | 719 kB 00:00
    updates 1092/1092
    repo id repo name status
    Webmin Webmin Distribution Neutral 162
    base CentOS-6 - Base 6,294
    epel Extra Packages for Enterprise Linux 6 - x86_64 9,806
    extras CentOS-6 - Extras 6
    google-chrome google-chrome 3
    nikoforge Nikoforge RHEL 6 8
    pbx pbx 121
    poptop-stable PoPToP stable repository for Red Hat Enterprise Linux 5
    pptp-stable PPTP Client stable repository for Red Hat Enterprise 24
    remi Les RPM de remi pour Enterprise Linux 6 - x86_64 1,248
    repos.openvpn.net-CentOS6-snapshots OpenVPN project yum repository 21
    repos.openvpn.net-Fedora16-snapshots OpenVPN project yum repository 23
    rpmforge RHEL 6 - RPMforge.net - dag 4,637
    updates CentOS-6 - Updates 1,092
    repolist: 23,450

yum list sysadmin
/usr/lib/yum-plugins/kmod.py:25: DeprecationWarning: the sets module is deprecated
from sets import Set, ImmutableSet
Loaded plugins: fastestmirror, kmod, refresh-packagekit
Loading mirror speeds from cached hostfile

I would mention that this was installed from a freepbx distro (asterisknow as I recall). However, I am at a loss to explain the lack of any output as follows:

cat /etc/schmooze/pbx-version
at: /etc/schmooze/pbx-version: No such file or directory
uname -ar
Linux pbx.check-flight.com 2.6.32-220.13.1.el6.x86_64 #1 SMP Tue Apr 17 23:56:34 BST 2012 x86_64 x86_64 x86_64 GNU/Linux

Very grateful for any further suggestions.

Kind regards,


Further to the above, I just found this:

cat /etc/asterisk/freepbxdistro-version

The module status and versions displayed on the Module Admin page are:
Asterisk CLI FreePBX Enabled
Backup & Restore Schmoozecom.com Enabled
Blacklist FreePBX Enabled
Bulk Phone Restart Schmoozecom.com Enabled
CallerID Lookup FreePBX Enabled
Custom Applications FreePBX Enabled
DUNDi Lookup Registry FreePBX Enabled
Feature Code Admin FreePBX Enabled
FreePBX ARI Framework FreePBX Enabled
FreePBX Framework FreePBX Enabled
FreePBX Localization Updates FreePBX Enabled
Java SSH FreePBX Enabled
Online Support FreePBX Enabled
Phonebook FreePBX Enabled
Phonebook Directory FreePBX Enabled
Recordings FreePBX Enabled

The failed module is as follows:
System Admin Schmoozecom.com Disabled; Pending upgrade to
Remaining modules:
iSymphony Enabled


Announcements FreePBX Enabled
Bulk DIDs Enabled
Bulk Extensions Schmoozecom.com Enabled
Call Flow Control FreePBX Enabled
Call Forward FreePBX Enabled
Call Recording FreePBX Enabled
Call Waiting FreePBX Enabled
Callback FreePBX Enabled
Conferences FreePBX Enabled
Core FreePBX Enabled
DISA FreePBX Enabled
Dictation FreePBX Enabled
Directory Schmoozecom.com Enabled
Do-Not-Disturb (DND) FreePBX Enabled
Follow Me FreePBX Enabled
IVR FreePBX Enabled
Info Services FreePBX Enabled
Languages FreePBX Enabled
Misc Applications FreePBX Enabled
Misc Destinations FreePBX Enabled
Paging and Intercom FreePBX Enabled
Parking Lot FreePBX Enabled
Queue Priorities FreePBX Enabled
Queues FreePBX Enabled
Ring Groups FreePBX Enabled
Set CallerID Schmoozecom.com Enabled
Time Conditions FreePBX Enabled
Voicemail Blasting FreePBX Enabled


Custom Contexts Not Installed (Locally available)
Extension Routes Schmoozecom.com Enabled
SIPSTATION Schmoozecom.com Enabled


Asterisk Info FreePBX Enabled
Asterisk Logfiles Schmooze Com. Inc. Enabled
CDR Reports FreePBX Enabled
PHP Info FreePBX Enabled
Print Extensions Bandwidth.com Enabled
System Dashboard FreePBX Enabled
Weak Password Detection Schmoozecom.com Enabled


Asterisk API FreePBX Enabled
Asterisk IAX Settings Bandwidth.com Enabled
Asterisk SIP Settings schmoozecom.com Enabled
Camp-On FreePBX Enabled
Extension Settings Mikael Carlsson Enabled
Fax Configuration Schmoozecom.com Enabled
Music on Hold FreePBX Enabled
PHPAGI Config FreePBX Enabled
PIN Sets FreePBX Enabled
Route Congestion Messages Bandwidth.com Enabled
Speed Dial Functions FreePBX Enabled
Voicemail FreePBX Enabled

What a mix Mex!

I don’t want to suggest you to run down the bad track (better than leaving you on the dirty one!) but if your system is really (with a mix of other things judging by the repositories that yum checks) a 1.1009.210.62-1 is definitely EoL (see it here, 6th row on the list) and issues like your one could be more and more frequent in the future (I may be wrong but a solution could be: freeze your system avoiding any FreePBX Modules update!).

There was a discussion on that matter (because it’s not only matter of having an updated FreePBX but also an updated Operating System)…but I’m too newbie to say the last word. Developers should.

On the Wiki it’s clearly stated that for that EoL version were provided consecutive update shell scripts (starting from the 6th one) to upgrade it up to (new, for that time) FreePBX Distro 2.210.62 track and then, from that one to FreePBX Distro 3.211.63 track (applying just latest script here) and then, again, finally to the latest one FreePBX Distro 4.211.64 reaching the very latest minor update FreePBX Distro 4.211.64-7. Sure a lot of work.

Really I don’t know if the result of the above procedure (if eventually you can do it without any pressure on your neck and hoping to end it positively) is (or is not) worth the whole effort (or the troubles you could face).

I’m basically a purist so if I were you I’d avoid this long journey (full of uncertain) and I would go with a fresh FreePBX Distro 4.211.64-7 64 bit install from ISO (forgetting to restore: AFAIK it’s not possible to restore between so different FreePBX Distro versions).

I would do that on a new dedicated (truly dedicated, leaving it with quite standard default repositories) hardware while the existing one runs as it is running now and then, at proper time, I would migrate users to the new one once extensions, inbound, outbound routes and all other important stuff you deployed over the years have been properly recreated.

I don’t know, at this point, if there a solution to fix your issue and keep things going as usual (EoL system) avoiding to upgrade your whole system to a more recent track of FreePBX Distro.

You need to upgrade your Distro to either 3.211.63 or 4.211.64 releases

Hi Tony,

Just to show my inexperience in such matters, since installing the distro (which I now understand is out of date), I have religiously followed each and every upgrade through the Module Admin pages.

Do I understand correctly that this is not actually updating FreePBX as might be expected?

How do I upgrade the distro as you suggest?

Kind regards,

Andy Woolford

Thanks for your comments Parnassus.

I’m not sure I followed all of that because I am more of a “user” than a “programmer”. Basically if it says “click here” then I do as I’m told, but don’t necessarily understand why.

As far as I knew, I was keeping the system updated to the latest version through the module admin pages. It seems, however, that there are some underlying bits of code lurking in the Centos OS which are not being updated as I might have expected.

If windows can keep itself up to date, I fail to understand why Linux (which everyone says is better), cannot?

The “mix mex” you refer to is because this box also acts as our main mx server running postfix and a few other bits and bobs to handle webmail and push notifications etc. It also has webmin as a friendly GUI for me to add new users to the MX server as and when required.

But heck, this is a 64-bit all singing / dancing thingy with loads of memory and a SSHD so it should be able to cook dinner and tell jokes as well as running FreePBX (which I understand should be able to run on a memory stick!)

I do understand your purist approach, which for a commercial environment is probably the way to go. But this is a private domestic system for me and a buddy, which we use for our own businesses and friends and family. My buddy owns the box and I try to keep it running as best I can. We have no desire (let alone the know-how) to reconfigure everything just to keep up with the latest updates.

I don’t mind implementing the distro updates on this machine if that will help, but I will need a step-by-step “how-to” idiot guide.

Many thanks again for your and Tony’s help and patience.

Kind regards,

Andy Woolford

That only updates FreePBX modules. It can not update the kernel, asterisk or any of the other 500 packages that make up your PBX.

Please see http://wiki.freepbx.org/display/FD/Updating+FreePBX+Official+Distro

Hi Andy, all is quite clear now.

As Tony pointed out Linux (intended not only as The Kernel but as the “cloud of applications and services” around it that forms A Linux Distribution…like CentOS…or like many others) should be updated (within each Distribution version) and then upgraded (between every new version that each Distribution release cyclically) to have a operating system up-to-date.

You need to have some sort of experience about that (maybe learning the history behind a Linux Distribution) so you will learn how complex things were managed to let users think they are simple.

The comparison with Microsoft is a no-go. Sorry.

When you use a Linux Distribution (really whatever) and you keep your system updated you’re keeping up-to-date all the installed packages with all their dependencies (Microsoft can’t do that: you have Java, you may have Office and Adobe and many other software applications…but you’re forced to manage them separately. Every non-Microsoft application has its update path/procedure. If any. Really it’s a no-go).

FreePBX Distro (The Distribution that sums up Asterisk, FreePBX and many others applications is and was based on CentOS): CentOS is an evolving Linux Distribution (naturally like many others) so if you updated FreePBX Modules from the GUI or via Linux command line this didn’t mean that you updated the operating system too, and it’s the main basic layer of components that make higher level applications to work.

More or less it’s like updating the Webmin you have and its modules without updating the operating system over which it runs: at some in the time this way to go will break because applications during theirs natural development need to have an updated operating system to match. This is due to fix security issues, to improve performance, to add capabilities and features. It’s a very natural approach.

My purist point of view has a valid reason: To specialize a System to limit its capability to generate issues that can interfere/propagate with/to other services (in your case you’re running a MX Server side by side to an Asterisk…the approach “one machine to rule them all” could be very economic but, sometimes, very problematic).

Specialize could mean many things (and many ways to do the same things)…from dedicating a machine (physical or virtual) to a specific task or by isolating some group of services to dedicated hardware because those services are functionally similar…running a “pristine” Distribution (whatever) let you to manage it easily (so avoid “mix mex”)…sometimes things could be done in a completely different and complex way (to achieve redundancy).

I know…all of this sounds too commercial but, in reality, it has to do more with a small/medium “Enterprise Grade” approach. Big ones do probably better.

Home users (Small Office Home Office users) could do things better than Small companies. It’s a matter of approach.

Stay foolish, stay hungry…stay update!

There have been many version of Windows End of Life with no easy migration path.

The Distro includes CentOS, it had a major upgrade from 5 to 6.

I think Andy now has enough tips and information to decide what best to do next.

I forgot to mention that not only practically every Linux Distribution has developed a proven migration/upgrade strategy/procedure (just look at Fedora with FedUp) but some others are starting to distribute (with various commitments in doing so) “rolling” Releases (CentOS too)…those are named “rolling” because there isn’t the need of any migration because the Distribution itself is continuously kept updated (some of them “living on the edge” some others, devoted to Server grade usage, a little bit more conservative): so the concept of “version” fall down.

So I will avoid to call Microsoft here. It’s a no go.

Dear Tony / Parnassus:

Well, I must thank you Parnassus for a most detailed and helpful reply. That must have taken you some time and I really appreciate the effort you put in to writing that.

I do understand a bit better now the issues. I just wish it was explained clearly when installing the original Distro, that keeping a linux system up to date is not just a matter of scratching the module admin page whenever it itches.

Even better, it would be nice (and I suppose this counts as a feature request), if the module admin page would automatically run one of those scripts Tony has kindly pointed me to whenever CentOS comes out with a new release. I suspect this is not so different in principle, (technically speaking as opposed to politically), to updating the various FreePBX modules.

That way, the modules and the underlying OS would better stay in synch.

Anyway, I shall now go and examine those scripts in more detail. Is it just a matter of running one after the other in sequence until I get up to the required version - or are there some gotchas? I do hope this won’t break anything (either on FreePBX or the MX servers).

Am I right to think there is no point backing up, because the backup modules are not reverse compatible?

Finally, do you know if I should begin with the update script which has the number following the version number my Distro is currently on, or the script with the same version number I am currently on?

Many thanks again.


Thanks Tony,

I’ve merged my reply to you with my other reply to Parnassus above.

Very grateful for your help.


Hi Andy, good questions your ones.

I’ve no generic valid answers (I can only tell you I did a step by step FreePBX Distro 3.211.63-5 to 4.211.64-7 upgrade procedure without issues but it worked on a very clean, basic and dedicated test system about which I wasn’t worried about too much…but actually, once I familiarized with it, it’s running really stable as a real dedicated production system).

Sorry if I insist on the “dedicated” (or “clean”) term but I personally think that there is a way of do things that let you then manage thing with the “divide et impera” way (…and history docet).

I’ll answer about the question “Should I begin with the update script which has the number following the version number my Distro is currently on, or the script with the same version number I am currently on?”: the next one.

If your system is 1.1009.210.62-1 the first update script to use should be 1.1009.210.62-2 and then, sequentially, script by script up to the last available 1.1010.62-5 for your Track 1 (considering reboots and checks in between…I add).

After that you could use (if you want) the script 2.210.62-1 o upgrade your system to Track 2 in a single step (your system will be upgraded to FreePBX Distro 2.210.62-1) and, once in Track 2, then you could repeat the whole process outlined above up to FreePBX Distro 2.210.62-7 minor version.

Once at the end of Track 2, the latest script proposed, the 2.210.62-100, will upgrade Track 2 to Track 3 directly to its intermediate minor version (FreePBX 3.211.63-7) and then you can follow your way to 4.211.64-7 in the quite same way outlined above: step by step up to 3.211.63-10 and then via the 3.211.63-100 upgrade script to upgrade your Track 3 to first minor version of Track 4.

Once in Track 4 the process will repeat from -1 to -7.

Always look at the -x number in the end to know what version your system is.

Really…a lot of work…that’s why I advised you to think about a dedicated fresh machine.

I don’t know how your system will react to such type of upgrade/update long procedure because, after all, not only your system is not dedicated but also it has a FreePBX framework yet updated (FreePBX 2.11) while the underlying operation system is not (so a good question would be: “What will happen if update scripts are applied strictly following their rules on a system that has a relevant misalignment between FreePBX framework and its modules and the rest of the operating system?”).

Probably update scripts will manage that scenario (for the FreePBX/FreePBX Distro part) because they should not force package/module update/upgrade when that is not needed/required but I don’t know what will happen to other packages (relevant to you and not for FreePBX Distro).

If you open a script you will read “This upgrade script is free to use for upgrading FreePBX Distro systems only but carries no guarantee on performance and is used at your own risk. This script carries NO WARRANTY.” and so it’s up to you (generally: is up to us) evaluate if this sort of agreement/statement is good or not for the system.

Keep an eye on the repositories you defined (backup them, see advice above) because, AFAIK, each update script will start the update process by erasing system’s ones in favour of a well defined set of FreePBX repositories, set that is necessary to perform the update process cleanly (that is clearly FreePBX Distro centric).

I think update scripts evolved in time…so, probably, latest ones tend to be more graceful (let me use this term) in regarding to system: they perform more system/FreePBX cross-checks before trying to do what they are programmed to do.

Regarding the automation of system upgrade/updates if your FreePBX has the “Sys Admin Pro” Module then you will be able to manage that (with e-mail remainders too).

Many thanks again.

I will follow the recipe… and hope the cake doesn’t sink when it comes out of the oven! Thanks for the step-by-step instructions. Exactly what I needed!

I might just make an ISO image of the existing disk before upgrading just in case… I have something called the “Ultimate Boot CD” which should have a utility to do that.

I really do appreciate you taking the time to explain it all to me so well.

Incidentally, I have received an email this evening:

[quote]Recommended in Documentation
Oct 24, 2013 • Go to Documentation



Tony Lewis
[strong]About FreePBX-Distro-4.211.64 Stable releases[/strong]

Below is an outline of the FreePBX Distro 4.211.64 codename “CallForward”, based on these main components:
• FreePBX 2.11
• CentOS 6.4
• Asterisk 1.8.x, 10.x or 11.x
System Impact
continue reading: http://wiki.freepbx.org/display/FD/FreePBX-Distro-4.211.64

I can only assume Tony Lewis has sent me this, (his name is in the header), but I don’t know why and I’m afraid this is a lot of information for me to digest. It would be helpful, perhaps, if Tony could let me know in a little more detail here what his thoughts are and what I should be looking for in all that documentation - perhaps a summary of the salient points.

I have just re-read the link from Tony and now it makes sense having read it again after reading what Parnassus wrote. Sorry for being dumb. It only applies to the track 4 upgrade though, so can I just confirm - I still need to go through all of the individual upgrades on each track before I get to track 4 right?

That is to say, I can’t just skip straight to 4.211.64-1 and then upgrade in sequence to 4.211.64-7 as described on the link?



Hi, I think you can’t (going straight to 4.211.64-1 from your actual Version/Minor Release).

AFAIK to me the update/upgrade path of your system (Track 1, CentOS 6.2) should be theoretically:

  • start with running 1.1009.210.62-2 (update script) and, step by step, go to 1.1010.210.62-5 then
  • run 2.210.62-1 (upgrade script) which takes the system to FreePBX Distro 2.210.62-1 (Track 2) then
  • start with running 2.210.62-2 (update script) and, step by step, go to 2.210.62-7 then
  • run 2.210.62-100 (upgrade script) which takes the system to FreePBX Distro 3.211.63-7 (Track 3) then
  • start with running 3.211.63-8 (update script) and, step by step, go to 3.211.63-10 then
  • run 3.211.63-100 (upgrade script) which takes the system to FreePBX Distro 4.211.64-1 (Track 4) then
  • start with running 4.211.64-2 (update script) and, step by step, go to 4.211.64-7 (actual).

As written, it’s a lot of work and you should start it when the system is not in use (this procedure, as said, is supposed to run flawlessly but - as I added before - it’s not granted at all: issues would pop up due to the nature of your running system, as you described it, and due to the fact you run through a lot of different Tracks).

Again, from my point of view I would much more worried about all other applications (in particular the MX part) that are actually running on that system, this is way I advised you to try with a fresh install on another very dedicated machine (your system is really making - among others things - “dark espresso coffee” today, wouldn’t you to end with a system that makes too milky “cappuccino”?).

Probably the FreePBX Module part (upgrade of FreePBX Modules via GUI or CLI) should be done at the very end (when the FreePBX Distro reports 4.211.64-7) and not in between during each upgrade/update single step (at least this is what I think apply some logic) but only Developers could say the last official word on that.

Regarding the Wiki: I think what was written on the <a href=http://wiki.freepbx.org/display/FD/FreePBX-Distro-4.211.64?focusedCommentId=18153535#comment-18153535>FreePBX Distro 4.211.64 here referenced (read the Comments written below that page too) should be considered usually (as a safe rule) valid for each previous Track.