Just an amportal restart!
Andrew, where can I found a more accurate upgrade log file? The log files in var/logs/pbx/upgrade say nothing… I’d like to understand where is the issue in my freepbx during the upgrade procedure.
Can anyone help me to upgrade my production freepbx system with the latest script?
With an old copy of the script, I can easly Upgrade, but I’d like to use the more updated script.
Just a shot in the dark, for a few days there was a typo in the upgrade script. I posted about it in this thread.
@tlewis fixed it, but I continued to have the same problem. Then I realized that wget did not overwrite the script I already had, I guess b/c filenames were the same. So I had to delete the script with the typo in it first then re-download the script.
See if you somehow still have the script with the typo in it…
The latest Upgrade Script (from FreePBX Distro 5.211.65 to FreePBX Distro 6.12.65-13) has a timestamp of 25.07.2014 15:14, with the typo fixed by @tlewis (as wrote by @jcbdmd in the post above).
If the Upgrade Script name have had a timestamp would be easy to track down (or, at least, recognize) changes/differences to look for the newer one.
Below a meld (graphical diff) between two scripts that share the same name but were changed during the same day:
On the right the actual one I downloaded today, on the left one downloaded during 25 July 2014. You can see the corrected typo.
Sorry I can not time stamp them. If I did they would break our auto updating stuff.
finally I got the new upgrade script working!
endpoint manager & rest app was not installed at all on my freepbx. Actually I don’t use those modules so I thought it was a good practice to uninstall.
I installed those two module and, after that, the new update script works great
strange but true
You guys do an amazing job!
We used the script last night on our VPS instance and everything upgraded without a problem. According to the admin interface, we are running “Asterisk (Ver. 12.4.0)” and FreePBX “6.12.65-13” now.
I have a couple observations that may be of help to you. There is also a minor nuisance where you may be able to point me in the right direction.
The first observation might fall into the category of “user error” or “not supported”. The upgrade script was stored in a folder that had some white spaces in the path (our environment is “white space tolerant”). The script had a few error messages such as a “cd” to the folder of the script failed probably due to unquoted variables:
/var/lib/asterisk/bin/freepbx_engine: line 97: cd /PATH/INLY/TO/FIRST/WHITE/SPACE : No such file or directory
The script eventually ended after downloading a lot of items with these lines:
Untaring..Done Module framework successfully downloaded Module framework successfully installed An error has occurred updating to FreePBX 12
The second observation is, that the script did not prevent us from trying to upgrade from 5.211.65-9. It detected the version, indicated it was not sufficient, yet still continued:
Check to make sure this is a FreePBX Distro system before executing This appears to be a FreePBX Distro system as it has a Distro Version of 5.211.65-9 Make sure this is version 5.211.65-14 or greater before executing This appears to be FreePBX Distro version 184.108.40.206 so we can now upgrade you to the 6.12.65 track as version 6.12.65-13 ...
So we went into the admin interface, upgraded to 5.21.65-15, and reran the script with no errors.
Somewhere along the upgrade path from 5.211.65-9 … 5.211.65-15 … 6.12.65-13, the Superfecta image files mentioned in other posts got screwed up. They became symbolic links to themselves (such as /var/www/html/admin/assets/superfecta/images/bottom.gif --> /var/www/html/admin/assets/superfecta/images/bottom.gif) and the script had warnings such as
find: `/var/www/html/admin/assets/superfecta/images/bottom.gif': Too many levels of symbolic links
We simple removed the symbolic links and retrieved the image files from backup and everything is fine.
Now to the minor nuisance. Crontab has an entry to execute “/usr/sbin/sysadmin_update_system -a” once every minute. I am not sure whether that was there before the update or not. In any case, the program prints to stdout which leads cron to send us an email every minute now with the program output:
Array ( [status] => error [data] => SimpleXMLElement Object (  => This system is up to date. ) )
Should this system check really run every minute?
Is there anything we can do to make the program print info only in cases that need our attention? What I mean is the program should not print anything in the normal case.
The output is a little ambiguous. It both indicates an error, and it says the system is up to date. Anything we should do about that?
Thanks again for an amazing product!
Turn off system auto updating in sysadmin, at least for now.
Thank you, That did it.
I just read that “FreePBX Distro 6.12.65-13 is Skipped due to internal screwup” and my production environment is exactly 6.12.65-13.
I was warned from you about risk and obviously I’m the only responsable of any damage, but actually I’d like to know if it is convenient to do a revert to 5.211 or it is safe to run the script upgrade-6.12.65-14.sh that I found on your wiki.
I noticed that the old path to voicemail & fax is still here, so users that created shortcut on their desktop continue to work in http://HOSTNAME/recordings. I’m worried that they send fax with the old fax pro, that will lead to a inconsistent fax archive.
I suppose that I still have the old path (hostname/recordings), because my install is not clean, but it is a 5.211 upgraded to 6.12
In your official upgrade script to 6.12, please delete the “/recordings” directory or do a redirect to the /ucp directory.
To solve I put the following redirect in the file index.php stored in /recordings directory:
<?php header( 'Location: ../ucp' ) ; /** * @file * main */ include_once("includes/bootstrap.php"); ariPageHeader(); include_once("includes/common.php"); handler(); ariPageFooter(); ?>
Do I have to write this on issues.freepbx.org?
That would be nice…
We uninstall the ari module. That should delete the directory. If not then thats a bug in the ARI module so open a bug report
Looking at the code, it doesn’t actually remove the directory because ari was never allowed to be uninstalled (till 12) so yup its a bug
You closed the issue http://issues.freepbx.org/browse/FREEPBX-7856.
I assume that a new update script will delete the “recordings” directory, but in my case, I still have the “recordings” directory present and working.
What is convenient in my situation?
1)Leave the redirect statement to …/ucp in the index.php file?
2)Manually delete the “recordings” directory
I think that at the end of 6.12 beta testing, I will do a clean install, but in the meanwhile I need to keep my environment more reliable as possible (even if it is a beta :))
Yes I closed it. I made the fix in fw_ari. Since you can’t download fw_ari you won’t be able to get the fix I made. It’s part of being in the beta cycle. I have no plans to fix this any other way.
You are fine doing what you are already doing.
The best thing I’ll can do will be to make a fresh install of freepbx 6.12 when you’ll release the stable version of it.
I read somewhere that I can migrate commercial modules only one time. Is it always true even for a system upgraded to a beta test environment?
You can reset your hardware lock twice. If the system is on the same hardware no reset is needed. If you need to reset more then 2 times it requires a support request to have us do it.