First off, THANK YOU!!! to the author(s) who made this upgrade conversion script! For those few of us adopting an older distro that has never seen an update, but want to get to the latest version without having to take each and every step along the way (at one or two steps per day, if we test our work as we should, for us this would take half a year), this is borderline miraculous.
I tried it. It ate all of our available disk space & almost crashed our production PBX. Fortunately for me, I was already SSH-ed in & was quickly able to du my way to the file & delete it, bringing the PBX back to life. Still a disaster narrowly averted is still a disaster, so I won’t be running this script again any time soon!
To the Good, I’m always Very Impressed at how well FreePBX/Asterisk gracefully recover from disasters like this. Nice work, people!!
Question: How do I determine the amount of disk space that is likely to be used for the giant file this script creates? I promise not to complain too much about the fact that it ships that file off to some distant Server somewhere on the Internet for processing, although that does bother me a lot.
I confess I haven’t yet looked at the script to see if there’s a way to put that file elsewhere, but I’d have to guesstimate that at ~60% utilization on the old PBX, I don’t think I have room to do this. I can handle giving the PBX access to more disk space elsewhere in the network, and of course I’d welcome any suggestions re: modifying the script to use it; but I would need to know how much disk space I need to provide for this script to run. (Or is it required that the script run from the distant Server?)
As far as I know the Upgrade conversion tool ONLY works on a FreePBX DISTRO system
and I believe it has to be the latest version i.e. FreePBX Distro 10.13.66-21
Even then the upgrade still has hickups and should not be run on a production system.
(which your response suggests you think (s)he is referring to…)
From what I have read the conversion tool is apparently not perfect but doesn’t have the warnings the distro 6 to Sangoma 7 has as far as using it in Production…
And I can’t see any way to change the script to use some other storage for the enormous file it creates. So I have to assume if I run it again it will eat all my available disk space again & crash the PBX again, so this isn’t really a solution.
Failing that, is there anything you can clean up before trying it again?
I must confess I didn’t pay full attention to the threads about this since it didn’t apply to my situation but I think there were suggestions about what to do in your situation in them…
Thanks, Nick.
I’m required to keep every recording, VM, CDR, CEL, logfile, everything. I’ve already cleared all the “non-essentials” I can find, so the best I’ve been able to do is to Zip up the oldest recordings, which only took me from >72% to ~62% usage.
There are threads about this??? I couldn’t really find any, which is why I started this one. I’m off digging for that gold now!
I can source, prepare, mount & format another disk, of course; that was “plan A”, but as I can’t edit the script, I don’t believe the Script will use it. The target has plenty of space, so maybe I could pre-move the older recordings, I guess. Problem is, du-ing that directory it doesn’t look like that will free up enough space to take me under 50% utilization.
Thanks again for some good ideas & the clue about other threads!
I hope you have a nice day too!
I read about it a few times (but like I said didn’t pay as much attention to it because I am not in that situation) so I know there were at least a few threads about it…
(Just like the one I pointed you too…)
What directory is it trying to use right now? Maybe there is a way to override it (or one could be added if you submit a feature request and don’t need it like “right now”…
Good point. Not needed with me, but a Good Point nonetheless. Thanks!
I feel that “FreeSWServer” person’s pain. I too inherited a Free PBX that was set up by someone who fancied him/herself a bit of a “l33t haxx0r” but was apparently violently allergic to any sort of Update. Or documentation. I may have mentioned, we’re so far behind that, if we followed the steps properly, by the time we got “current”, we’d be so far behind that, by the time we got “current”… etc., etc.
And I have actually read the script briefly (no way would I run it w/o at least parsing what I can of it), but I do appreciate you pointing out the point. I was wondering if I were to d/l it, could I make the changes & run it here (that conversion code number isn’t coming from me), but until I get some room that’s academic.
When I get some time, I’ll go back & re-read the script to see if maybe a symlink would work…
Don’t forget that we are on a public forum… Even if I had known that it was not needed for you it might be needed for someone else…
The temporary directory it creates in the bash script (which is probably used for anything else done after including creating that huge file) is under /tmp so mounting over it would probably be a better bet…
Be careful though, that would mean changing (either temporarily or permanently) /tmp server-wide which I would not be surprised if it caused problems when you do it…
Altering the script to point to your own directory on a different disk sounds like a safer bet…
Your safest bet however I think would be to convert that server to a VM…
Once converted to a VM I believe it is pretty easy to resize the disk to make it bigger than it was on the real server…
You would then proceed with the VM as the source (instead of the real server) for the upgrade…
If anything goes wrong, the real server is unaffected.
You do have to make sure the real server and the VM don’t see each other, that the VM doesn’t connect to your providers instead of the real server and those kind of things…
LOL, if he was anything close to what he was pretending to be he would have understood the value of updating if only to keep the box secure…
Sounds waaaaay more like the “script kiddie” type…
