13 to 14 Upgrade Fails on AWS

Hello All,

I have done several upgrades but in this case a fully updated 13 fails in the upgrade to 14 (multiple attempts).

I went through the standard procedure, click on the 13 to 14 button tells you to go to the site so you can manually upgrade.
Execute yum -y install http: //package1 .sangoma.net /distro-upgrade-1807-2 .sng7.noarch.rpm
then distro-upgrade
then reboot when ready.
After the reboot check back some time later to find that it’t not running.

Tried to manually start asterisk or reboot, no web gui, then check yup update but multiple things aren’t happy.
Tried --skip-broken again no luck.

Key errors I see are:

Error: php56w-common conflicts with php-common-5.4.16-46.el7.x86_64
Error: nodejs-docs conflicts with 2:nodejs-8.11.3-1.7.x86_64
Error: Package: 2:nodejs-devel-8.11.3-1.7.x86_64 (sng-pkgs)
Requires: nodejs(x86-64) = 8.11.3-1.7
Installed: 2:nodejs-8.11.3-1.7.x86_64 (installed)
nodejs(x86-64) = 2:8.11.3-1.7
Available: 1:nodejs-6.17.1-1.el7.x86_64 (sng-epel)
nodejs(x86-64) = 1:6.17.1-1.el7
Available: 2:nodejs-8.11.1-1.5.x86_64 (sng-pkgs)
nodejs(x86-64) = 2:8.11.1-1.5
Available: 2:nodejs-8.11.2-1.6.x86_64 (sng-pkgs)
nodejs(x86-64) = 2:8.11.2-1.6
You could try using --skip-broken to work around the problem

I can never get past this point.

I restored original version and did the same thing with the same result, so a couple of key quests are:

Is this a virtualization issue like those that can’t convert in windows?

Will a fresh freepbx 15 be able to restore a 14 full backup?

Appreciate any direction!


The failures you have experienced are not AWS specific at all. The in-place upgrade is far from a perfect process and any number of things can go wrong, as there is a full OS upgrade required as part of the move from v13 to v14. Not even we have been able to perfect it in our offering in all cases. We have observed about a 60% success rate…and the remaining 40% just seem incapable of upgrading in-place for any number of seemingly random reasons. The more “customized” your server is (APIs, 3rd party services, etc), the more likely the in-place upgrade is to fail…but we have even seen rather vanilla installs fail for various reasons.

For our offering, we also provide a migration method, but that’s because we have a v14 AMI on offer, so customers could just spin up a clean v14 and use the migration script to transform/transport all data and configs from the old v13 instance. If you really want v14, you’ll likely need to roll a new AMI using v14 and then use Sangoma’s migration scripts to bring everything over.


Yes, this tool will work to move from one “genuine” FreePBX version to another…source does NOT have to be non-FreePBX. We base our own inter-version migration scripts on it.

Finally…Yes, you are technically correct that if you fire up v15 you can now restore backups from older versions to it…but keep in mind that this is also not quite flawless yet since interversion restores are new to v15, so YMMV. If you DO encounter a bug in the v15 Restore process, you’ll want to check for and/or file a bug report with Sangoma so they can look into it. https://issues.freepbx.org

I hope that helps!

Mike from TheWebMachine Networks

Thank you!
I appreciate the insight and I’m glad to know the computer Gods are not jut picking on me :slight_smile:
Literally have done this a few times for one client and it’s time for another method.

Back a year ago, Tony Lewis told me that V13 to V14 on AWS is not supported and will not work. This was because AWS does not give you pre-boot access and this is required to do a v13 to v14 upgrade. We backup v13 on AWS, download to a local machine, restore the backup to a “virgin copy” of v13 on a local machine, upgrade local machine to v14, backup v14, upload the backup to a “virgin” v14 in the cloud, and restore the backup to the virgin v14. That said, V15 supports (per the documentation, not my known experience) backing up a V13 and restoring to a V15 directly - this would allow you to backup v13 and restore to a second machine that is running virgin v15.

Thanks for sharing!
All this helps to give us a direction rather than restoring 20 times and banging your head against the wall! ( it starts to hurt after a while )

As Sangoma’s AWS Partner, we used to get into those debates with Tony (and Andrew) all the time! haha We did, in fact, get the in-place upgrade from v13 to v14 working on the whole…you don’t need pre-boot access, just a better knowledge of the AWS boot process and how to leverage cloud-init to do your bidding. :wink:

The real sticking points moving from v13 to v14 are the OS upgrade (tricky but NOT impossible on AWS), and the massive amount of database changes between v13 and v14 (not much we can do about that). We’ve solved the OS upgrade in 99% of cases, but all it takes is one bad CDR/CEL or config DB entry to break parts of the migration process and leave you with a broken system as modules get borked, config gets corrupted or deleted, etc. That’s really where the “coin toss” comes in, even with an on-premise system.

That said, you probably are better off just giving v15 with a restore of your v13 data a try. The ability to restore backups from earlier versions is a HUGE boon for all of us and something we had been hoping for for literally years now. This should also mean much smoother upgrades to later versions in the future, barring OS upgrade headaches down the road.

Yes, I had several misses on clients physical boxes, and even our own internal had a few attempts before it worked… the amount of time waiting and not knowing whats going on may be some of the biggest frustration with the process.

I was upgrading from 13 to 14 a couple days ago and found several issues:

  1. GUI Interface wasn’t working due to Apache User and Group set to the default “apache” after upgrade. Fixed by changing User and Group to “asterisk” and restarting httpd
  2. AMPDBPASS was incorrect in several places. Fixed it by updating to the same pass as it was in the DB.
  3. Was getting this error in asterisk: manager.c:3548 authenticate: failed to authenticate as ‘admin’. Fixed by updating the pass for admin to the same everywhere needed.

Of course, I had to run ./post_upgrade to fix all other issues and I think after that I got it back to work.

P.S. BTW the server is in the cloud too and I did not have PHP issues.