Installed version 17 from SNGDEB-PBX17-amd64-12-13-0-2603-3
Activated with existing deployment ID
Updated Modules via GUI to those current as of 30JUN2026
PBX Version: 17.0.28
PBX Distro: 12.7.8-2408-1.sng12
Asterisk Version: 22.8.2
Following the instructions from 20tele above, here is a ste-by-step guide:
Log in via SSL (I use PuTTY) as root or sangoma depending on how you installed FPBX17
Enter the password you created at install
sudo apt update
System will ask for password again.
sudo apt upgrade Do not upgrade to Debian 13 (trixie) if prompted.
Type Y to proceed
When completed, reboot the system:
reboot
Give it 5 minutes and SSL back in as above.
sudo apt update
response should be all items are up-to-date.
SIP SIP
I have yet had a normal maintenance window of a system update (i.e. apt update && apt upgrade) that required me to reboot the system after the update. Rebooting just because it’s an un-needed step in this process.
Also these two steps are redundant since step 10 does step 9.
9. fwconsole reload
10. fwconsole restart
Step 9 might not be required if being done by 10, but it would be bad practice for me not to advise someone to reload. What harm does it do? None, so the criticism is completely unnecessary.
It also clearly says to check if a reboot is required. You should carry out step 3 if you think you’ve never had to reboot. You might be surprised to learn a reboot is sometimes recommended.
@sippy You don’t need to reboot unless it says to do so when running needrestart.
Well doing a fwconsole reload reloads the configuration layer of FreePBX. It is the cli version of “Apply Config”. So advice to reload is great if all they are doing is reloading the configuration layer of FreePBX. No services are restarted during this process. So in reality you have an instruction step labeled as “Reload Asterisk” and the command doesn’t do that.
9. Reload Asterisk
fwconsole reload
Well, it’s not really clean documentation and by that logic you can add numerous steps that cause no harm and are not needed. The bottom line is, it trains people to do things without understanding why they are doing them or if they are even really needed. In this case, it trains them to do a step they think does X but it actual does Y.
Unwanted and unnecessary are two different things. I think you fall into the former because these are valid critiques.
Yes, in your documentation but I wasn’t replying about what you have in your documentation. I was replying to what @sippy wrote as a “write up” of your instructions. It was a poorly relayed step with no context (actually stripping your context).
Yeah, I know. Which is why I said rebooting just to reboot is un-needed. I wasn’t saying you don’t ever need to reboot I was saying that just doing it “cuz” wasn’t correct.
I find it interesting that someone misquotes your documentation but instead of correcting them you decide to lob a passive aggressive attack at me for it because I pointed out to the person that misquoted you the issue of the misquote.
Noted. I will update the guide.
I mean technically, splitting hairs, it does “reload Asterisk” because it does a core reload but again all that does is read the current configs into memory. The restart includes restarting both FreePBX and Asterisk services so Asterisk is fully restarted during fwconsole restart.
Apply Config is a better title for a beginner’s guide anyway, as readers can tie it directly to the big red GUI button. Updated, thanks.
As this is about playlists for non-experts, I’d suggest that the reboot is necessary. Otherwise they need to be able to recognize when a kernel has been replaced, which definitely requires a reboot, to have any real effect, and also what might affect long running processes.
The fact that Linux will continue running, with no visible effect doesn’t mean that the update is actually complete, affected code and shared libraries need to be reloaded and re-initialised. You are likely to end up with a mix of vunlnerable and made safe components, in memory, possibly two different versions of the same shared library.
Again this is where you need to teach when it is necessary and not teach just to blindly do it because they’re “newbs”. Understanding context of what you are doing is key here. Regular applications (php, apache, mariadb, etc), daemons, shared libraries don’t need a reboot. They need services restarted.
Right which is why you can teach them very simple things like after the update is run you will see
*** System restart required *** or System restart required
If the kernel was updating during the upgrade process then you will see something like this on Debian/Ubuntu for sure. Followed by the “System Restart Required”.
Setting up linux-image-6.1.0-39-amd64 ...
Setting up linux-image-amd64 ...
Processing triggers for initramfs-tools ...
update-initramfs: Generating /boot/initrd.img-6.1.0-39-amd64
Processing triggers for grub-pc ...
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-6.1.0-39-amd64
Found initrd image: /boot/initrd.img-6.1.0-39-amd64
done.
Additionally when a system restart is require it creates a file for that and the MOTD uses it tell them on each SSH login “System restart is required”. Until the system is restarted these warnings keep popping up. Teaching people to blinding do things with no context or reason leads them to rebooting their systems in the middle of the day for no reason.
Things like that just have people to do actions with no reasons why they are doing actions or what those actions actually do. Or as I’ve put it before to people
When I tried to install needrestart I got a not found error, I expect others would encounter this, and so just did a reboot. Most of my installations can tolerate 3-5 minutes of downtime.
2. Install needrestart (if not already installed)
apt install -y needrestart
Probably should add needrestart to either the ISO or the shell installer for v18 thank you!
That’s best practice. Although most software package updates are fine with basic restart of the service, rebooting is the easiest way to use new Linux kernels (hard mode involves ksplice or kexec). And rebooting is the only way to sus out any subtle startup race conditions, missed drivers, or other problems in either hardware/firmware/software that might appear after the next (un)planned power outage of your production systems.