However, after running that script, Asterisk just crashes. Our system is as vanilla of an install as can be - but yet it can’t run this script. I then restore from backup to bring us back to a working 5.211.65-8 version with Asterisk working and then run the 5.211.65-14 script and the same occurs.
I know with this image, we had been updating FreePBX modules through Module Admin and system packages through the repositories. Is this not a safe practice, and should we only be updating through these scripts?
After running the update I can see Asterisk start, then stop. When I type
tail -n 10000 /var/log/asterisk/full | grep ERROR
I do not see anything specific indicating why Asterisk will not start. I tried running
The issue is Asterisk 11.11 has a bug where Asterisk fails to start if their is no ooh323.conf file. We have reported the bug to Digium and supplied a patch. We will have new RPMs shortly.
You shouldn’t use a non consecutive Upgrade Script (e.g. upgrading the FreePBX Distro 5.211.65-8 to 14 directly), you should apply consecutively each Upgrade Script starting with the next one (say 5.211.65-9) to the latest one (say 5.211.65-14) available (if you want to reach the current version) passing through -10, -11, -12 and -13.
Said that performing a YUM on a FreePBX Distro is potentially dangerous because Upgrade Scripts are made to do that for you (each Upgrade Script, when released, will update RPM packages of SHMZ OS and of various other components like FreePBX and Asterisk and will eventually perform automatically FreePBX Modules updates).
Will be useful for the Community if you provide relevant logs (full log, as example or /var/log/pbx/upgrade/5.211.65-9 log file if your system still has it).
I do know to run each script consecutively. But since running the script from 8 to 9 did not work, I figured I’d try the latest and see if there was an issue there as well. Tony’s response above seems to have fixed our issue, however.
Parnassus, I also had restored the system from backup so those logs are missing, but if I do have an issue again, I’ll post those logs here. I will notify our techs to not run yum update or module updates as these scripts should handle that for us.