I had a problem after upgrading from FreePBX14 > 15 where all modules were showing as ‘Enabled; Not available online’ I was unable to download/update anything. I fixed it by modifying the file located in etc/schmooze/pbx-brand to state ‘FreePBXDistro’ rather than just ‘FreePBX’ (The machine is a distro machine). However when the unit is rebooted this file gets reverted back and I have to modify to be able to download modules again. Any idea what is going wrong?
I was/am having similar issues with a brand new FreePBX appliance we just purchased, similar scenario of after upgrading and running into same issues with upgrading modules.
I am super glad I found your resolution of the file edit to include “FreePBXDistro” as that allowed us to at least finish the upgrade to 15, it was in a partially broken state and wouldn’t finish upgrading all the modules until we did.
Another thing we noticed in relation to this (not sure if you had it too) was that if you tried to do the updates via command line, the results would always come back with an error message along the lines of “Retrieved Module XML was empty”
I think something might have changed behind the scenes as we did another appliance with same upgrade path just a week or two before and it was seamless.
@herebull
Yes i had the same ‘Retrieved Module XML was empty’ issue. It seems the upgrade is killing the distro registration or changing files it shouldn’t. No idea what a permanent fix would be though…
Did you try this:
- yum clean all
- yum update -y
- fwconsole ma updateall
We need more information about your system. Can you either private message me your deployment id or email it to me at [email protected]? Please do not post this to the forum.
Franck, I had actually tried these commands from a prior article I had found on the XML error from a different year.
What ended up working was editing the pbx-brand file as James indicated and then running fwconsole ma updateall from the commandline and it ended up running the updates.
Although it looks like it still does the “Enabled; Not available online” on a few modules that still have updates. I imagine if I do that edit again and re-run, it’ll finally update the remainder but obvious something isn’t working like it should.
@mbrooks Reached out via email with my deployment ID as well.
The only notable difference I saw was that the V15 upgrade jumped to 15.0.16.76 instead of 75. Not sure if that has anything to do with it in my case.
On my first FreePBX60 I deployed which is on 15.0.16.75, I did the update check and didn’t get the “Enabled; Not available online” in the GUI so I’m really curious.
Out of curiosity, @james456 did yours upgrade to 15.0.16.76 too?
@herebull
Yes straight to 15.0.16.76
The upgrade process reported no errors however afterwards none of the modules had updated and wouldn’t do so until I change the file to FreePBXDistro. I also noticed that on my ‘Activation’ page my PBX was showing as un-activated, once I had changed this file everything was fine and the machine was active with the deployment ID
Adding to this thread as I await support in case this occurs to anyone else.
The issue has managed to occur on our second appliance as well after working through some issues on licensing with customer support to get the deployment right and so now we have two appliances thus far showing these problems.
@james456 - Is yours an appliance from Sangoma? I haven’t seen this in our lab or with other customers on VM or white box hardware so I’m curious if you’ve got an appliance too.
Just an update @james456 James, I still have no tangible updates from our paid support with Sangoma with a ticket started Monday of this week. It’s obviously related to deployment ID though.
Edit
@mbrooks @danardf
Looks like if you de-activate and re-activate with a new deployment ID it fixes it and updates start working again. Course that defeats the point as warranty, modules, etc are all tied to the existing deployment ID that exists from the appliance purchase.
What was the upgrade path/means for FreePBX (backup and restore or upgrader module) and also did you migrate from one distro install to another (going from non SNG OS to SNG OS or vice versa)?
Matthew Fredrickson
Just an update on this, we eventually got it resolved / a work-around by having the license/support moved to different deployment ID’s. Mike at Sangoma really got things moving for us and got it taken care of.
@mfredrickson In our case, it was broken out of the box (appliance) with the factory deployment ID, no migrations or any of the sort had been performed. Definitely feels more like a back-end issue/administrative side versus a tech issue since the deployment ID change fixed it.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.