Just to let people that are new to this know - I’m having trouble upgrading an existing FreePBX 12 (with PBX In A Flash) system to FreePBX 13. It’s complaining about missing the freepbx_users table. I’ve got it under control and I’ll post the steps once I get it squared away. This is my last PIAF system (Hi @SkykingOH) and I’m trying to convert it to “straight” FreePBX.
I’m pretty sure I’m going to end up hand-jamming the table into the system (or converting a table to the new table) using MySQL. I’m also aware that this is “deep magic” and should only be attempted by people willing to die trying. I’ll write up the process and post it so that we have it documented in one relatively easy-to-follow post.
I hope that it provides some succor to those people that are completely new to this to know that these kinds of things happen to folks that have been doing this stuff for years too.
Hi, You should not have to manually create the table.
BTW, the only way to do that properly is to look in the FreePBX installation package and grab the asterisk MySQL script (in the MYSQL directory off the install root when you untar the package) and run just those table create commands.
@tm1000 Userman is complaining about the table being missing on the reload. It had a problem originally with the BMO code, and fwconsole installation of core and framework fixed those. The recommended “solution” in the error message is to uninstall and reinstall userman, but I’m pretty sure that’s not going to cut it.
@skykingoh I’ve been looking through the old posts, trying to figure out the “best” way to do this. Pulling the create scripts out of the install package is one way. There may also be a way to do it my using a combination of fwconsole commands and the UI. I’m pretty sure it will end up being relatively simple, but a lot of people tried a lot of things that ended up not working to make this particular problem go away over the past year.
Ward, I saw your post about that in my research, but it’s a scary step for lots of people that use FreePBX. We’re kind of victims of our own success - giving people a GUI that is as awesome as FreePBX or PIAF means that lots of folks that didn’t cut their teeth on custom dial plans are using the system, so getting into the CLI or /bin/sh and running MySQL scripts can be a little daunting.
Asterisk hasn’t stopped and is still running fine, so I’m not going to get completely wrapped around the axle. It’s my “let’s try THAT and see what happens” server anyway, so it’s not critical.
This difference of opinion (between two heavyweights for this system) is the crux of the thread.
There are several ways people have tried to solve this going all the way back to the original Version 13 ALPHA code and several of them have had success.
I’m going to try reinstalling Userman again (I’m going to try deleting it completely and reinstalling it this time) to see if it helps.
Oh - there is one thing that I’m going to submit a ticket on. When fwconsole was installed (to replace amportal), the ‘x’ bits weren’t set, so running “fwconsole …” was a non-starter. Running a quick “chmod +x {path}/fwconsole” solved it. Might be something that needs to be added as a prophylactic step in the upgrade script? Like I said, I’ll drop a ticket on it.
It’s not a difference of opinion and Andrew is right. It’s a lack of clarity in my writing.
I should have written:
“If I table has to be manually created the only way to properly do it is to utilize the section for that table out of the MYSQL DB creation script located in the install package.”
This is a hail mary step only. If the module detects the lack of the table and creates it doing the step manually creates additional risks that are unwarranted.
It is also key if one is going to modify the DB structure directly parsing the error correctly is key. If the table is missing is one issue. I have often found that what happens is data is imported from a previous version and the table structure is missing a field and that causes an error. In this case it is best to drop the table, create it with the schema for the running version then enter the data via the FreePBX interface. Manually populating the tables from one version to another with the data is very challenging due to the many relationships between the tables.
I’ll write up the process and post it so that we have it documented in one relatively easy-to-follow post.