Upgrade from 13 to 14 using convert.freepbx.org

[Hawkeye]

This is the 4th time attempting to run convert.freepbx.org to convert a FreePBX 13 to FreePBX 14.

Start installing a brand new FreePBX 14 server using SNG7-FPBX-64bit-1805-2.iso

Reboot to new FreePBX 14 server, no conversion run as yet.

No Extensions added as yet

Start the conversion process as per http://convert.freepbx.org

![step8-start_convert_production_box|643x384]
(upload://1rc8ynMygYOMib6cmNBH18bFeOK.jpeg)

Production (Donor) FreePBX sending…

After sending the conversion_backup.crypt via ssh to the new FreePBX 14 server…

Doesn’t copy over the email addresses assigned to extensions. And you’ll notice later on, all extensions are created as virtual extensions!

Click the Apply Config button, and the error appears. The error in retrieve conf ALWAYS shows its the lowest number extension. (When checked the extension noted in the error, nothing appears wrong. However, note that inbound routes, all extensions that were going to FAX Recipient were all errors. They did not have the fax recipient, just error.

Note all extensions show as virtual

And it show ext 125 is the problem. Like mentioned above, its always the lowest extension number.

Run yum update to see if it fixes the issue (it doesn’t)

After all this, ran: # fwconsole ma downloadinstall core --force
No repos specified, using: [standard] from last GUI settings

Downloading module ‘core’
Processing core
Downloading…
1111681/1111681 [============================] 100%
Finished downloading
Extracting…Done
Download completed in 5 seconds
Updating tables trunks, pjsip, sip, dahdi, iax, indications_zonelist, devices, users, incoming, outbound_routes, dahdichandids, outbound_route_patterns, outbound_route_sequence, outbound_route_trunks, outbound_routes, trunk_dialpatterns…Done
Migrating pickup groups to named pickup groups
Migrating call groups to named call groups
Checking for possibly invalid emergency caller id fields…none found
Migrating old media encryption values…done
Removing encoding on incoming routes alertinfo values…done
Generating CSS…Done
Module core successfully installed
Updating Hooks…Done

followed by: # fwconsole reload
Reloading FreePBX
Error(s) have occured, the following is the retrieve_conf output:
exit: 1
Unable to continue. Invalid argument supplied for foreach() in /var/www/html/admin/modules/core/functions.inc/Driver.class.php on line 113
#0 /var/www/html/admin/modules/core/functions.inc/Driver.class.php(113): Whoops\Run->handleError(2, ‘Invalid argumen…’, ‘/var/www/html/a…’, 113, Array)
#1 /var/www/html/admin/modules/core/functions.inc/Driver.class.php(125): FreePBX\modules\Core\Driver::devicesGetUserMappings()
#2 /var/www/html/admin/modules/core/functions.inc.php(477): FreePBX\modules\Core\Driver::map_dev_user(‘125’, ‘callerid’, ‘device <125>’)
#3 /var/www/html/admin/modules/core/functions.inc.php(73): core_conf->generate_sip_additional(‘13.22.0’)
#4 /var/www/html/admin/libraries/BMO/FileHooks.class.php(65): core_conf->generateConf(‘sip_additional…’)
#5 /var/www/html/admin/libraries/BMO/FileHooks.class.php(24): FreePBX\FileHooks->processOldHooks(Array)
#6 /var/lib/asterisk/bin/retrieve_conf(877): FreePBX\FileHooks->processFileHooks(Array)
#7 {main}

Also removed modules in the new FreePBX 14 to match what was in the production (Donor) FreePBX 13. It made no difference whatsoever. Still get the same retrieve_conf error.

I would love to know what I am doing wrong here. The instructions at http://convert.freepbx.org/ do not mention anything remotely close to these issues.

Thanks for reading this. If you find a fix, please let me know.

[BlazeStudios (Tom Ray)]

Where these always Virtual extensions? Virtual Extensions do not have devices attached to them. So when this mapping is happening it’s looking at the devices table for information.

If the query comes back with an array of details for a device related to the extension it is querying about AND the ‘devicetype’ key in said array has the value of ‘fixed’ it will treat it as a device exists and try to map those device/user details together. If that check returns false (both of those conditions are not met) it just skips it and returns no mapping.

This looks like there is data that exists in the old PBX databases that make it believe there are actual devices for these extensions/users and there are not. Either that or there is a bug with the mapping function and handling virtual extensions. But I haven’t run into during conversions I’ve done and there have been custom, virtual, PJSIP and Chan_SIP extensions converted.

[Hawkeye]

Hi BlazeStudios, there were never ever any virtual extensions. Only chan_sip extensions.

What I have done in the past to attempt to get past this is re-run the conversion. I will do this now and report back here.
Thanks.

[BlazeStudios (Tom Ray)]

So they were Chan_SIP extensions on the donor machine and the new machine has them listed as Virtual extensions?

[Hawkeye]

Yes, exactly. Does this every time the conversion has been run. All extensions are virtual in the new FreePBX 14.

Re-running the conversion again right now.
Thanks.

[Hawkeye]

Hi BlazeStudios, I stand corrected. Checking with the FreePBX 13, there are 7 Virtual extensions out of 74.

After re-running the convert script a second time, apply config no longer errors out.

Now the extensions are correct as shown below on the new FreePBX 14.

To be very clear here, the ONLY thing done was the re-run of the script curl -s https://convert.freepbx.org | bash
on both servers followed by importing the crypt file from the donor FreePBX 13 server.

Thanks.

[FreerPBXer]

Thank you for posting back with the solution. We have a number of virtualized systems for which the direct upgrade won’t work. This might be a viable option.