FreePBX ISO on EFI VM ... wow, fail. lol

I’m trying to do a test deploy of SNG7-PBX-64bit-2104-1.iso in an EFI VM to compare it to SwitchVOX.

VMWare 7, create new virtual machine, 2 vCPU, 4 gig memory, 100 gig disk, VM type: EFI

With EFI enabled, the default ISO boot option is automatically chosen after about 5 seconds, and blows away the previous state of the virtual disk without any prompting or warnings whatsoever.

Trying an install with BIOS boot mode, there is no nearly instant auto-selection and it sits at the boot menu waiting for me. Only EFI boot does that.

So apparently, attempting an in-place upgrade via the ISO with EFI enabled, can very easily be deadly to your existing disk state, if you are too slow powering on the VM, and then activating the console window.

Also, I am amazed all the boot menu default install choices are apparently designed to auto-wipe the VM disk with no prompting, unless you choose to do a custom install.
,

So anyway, with EFI enabled, on reboot after the auto-selected automatic default installation, all I see is a grub> bootloader prompt. So the EFI bootloader is broken using the default ISO boot choice.

… well tested software I see.

Crazy, the modules updater via the web GUI will screw up a fresh system install from a default install of FreePBX for Asterisk 18. What the hell.

After installing modules for Asterisk 18, eventually the modules status window goes blank with no further activity. After waiting 30 minutes, close the status window and a red error flashes by across the top and disappears before I can read it.

Then another updating modules message appears with a spinning graphic and nothing seems to be happening. After again waiting for an interminable amount of time and no activity, I refresh the admin web page, and go back to the modules update page.

ERROR: Core is missing!

Exception (404)
Unable to locate the FreePBX BMO Class 'Core’A required module might be disabled or uninstalled. Recommended steps (run from the CLI): 1) fwconsole ma install core 2) fwconsole ma enable core

,

Is this software intentionally broken to try to push people in the direction of using SwitchVOX instead?

A clean install of FreePBX with Asterisk 18 updating itself fails. Ridiculous.

Apparently the web GUI sucks for upgrading and the command line should be used instead, even though the login prompt exhorts you to go use the GUI.

Wipe and reinstall for the 20th time. Let’s try updating modules for Asterisk 18 only through the linux shell and to hell with the web interface until the modules are updated.

You’ll get a better response on this forum by asking for help nicely, rather than ranting and raving before most of us have even had a coffee.

Good luck.

EFI boot
FreePBX 15 Installation, Asterisk 18
Graphical Installation - Output to VGA
FreePBX Standard
Set root password, wait for install to complete
Reboot

Login for the first time to VM console, get ip address, sign out.
Reconnect via PuTTY so we can copy and paste the terminal window.

Update CentOS via yum before anything else
yum update

[…]
Upgrade 23 Packages

Total download size: 22 M
Is this ok [y/d/N]:
y

[…]
Complete!

reboot

Login again
fwconsole sysadmin activate 123456789

[…]
Setting permissions…
Restarting httpd…
Done

Update modules from command line using modules administration, using screen so I can also watch system status in top.

screen -S Update-Modules
fwconsole ma upgradeall

The following red messages scroll by:

Unable to resolve dependencies for module core
Unable to resolve dependencies for module adv_recovery

Wow the download of the “endpoint” module went 10 times faster in the CLI than via the web interface

Blue text during modules install:
(node:6558) MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 SIGINT listeners added. Use emitter.setMaxListeners() to increase limit

I hope that’s not important. Not sure what I’m supposed to do about it.

Also these messages are entertaining.

added 401 packages from 334 contributors and audited 405 packages in 117.56s
found 51 vulnerabilities (2 low, 16 moderate, 23 high, 10 critical)
run npm audit fix to fix them, or npm audit for details
[npm-cache] [INFO] [npm] installed npm dependencies, now archiving

I hope none of that matters.

[…]
Chowning directories…Done
Chowning directories…Done
Chowning directories…Done
…and we’re back at the prompt again with no final status message

I know some modules failed to update, so we’re going to repeat the modules update command until everything is reported as succeeded.

fwconsole ma upgradeall

Module(s) requiring upgrades: adv_recovery
Upgrading module ‘adv_recovery’ from 15.0.53 to 15.0.53
Downloading module ‘adv_recovery’
Processing adv_recovery
Verifying local module download…Verified
Extracting…Done
Download completed in 0 seconds
Updating tables adv_recovery_primary_server_settings, adv_recovery_heartbeat_log, adv_recovery_backuprestore_log, adv_recovery_notifications_log, adv_recovery_serviceswitch_log…Done
log file created /var/log/asterisk/adv_recovery.log
Restarting Advanced Recovery process…Generating CSS…Done
Module adv_recovery version 15.0.53 successfully installed

Very nice. Advanced recovery updated to the same version that it already is. Good job.

Nothing about core mentioned. I guess that solved itself?

All upgrades completed successfully!

I’m sorry but I don’t believe you. I still don’t know if it’s actually done, so we’re going to keep trying to update modules until there’s nothing else to do.

fwconsole ma upgradeall
No repos specified, using: [standard] from last GUI settings

Up to date.
Updating Hooks…Done

Okay then, I think we are finally done updating Asterisk 18 … lol

reboot

Yeah updating modules doesn’t update Asterisk. Nothing with the FreePBX GUI updates Asterisk. If you are updating Asterisk you are running a specific command for that update. Nothing related to modules or the GUI. So for the record, you didn’t update Asterisk you updated the modules in FreePBX. These are two completely different things.

No, not really. Done way more than just one install, which seems to be your experience, this doesn’t happen. Have you considered this could all be PEBCAK?

Default installs of new software should not break themselves for no reason. I would have to assume the default install method for FreePBX normally expects to use BIOS mode of VMWare, though we are firmly in the UEFI era at this point.

Allowing the ISO to simply boot by itself with the default boot selection in UEFI mode results in an unbootable system stuck at the grub> prompt after the first reboot. That’s not me doing that.

,

It auto selects everything during this auto-boot aside from the root password, and wipes the partition table of the source disk and proceeds to being overwriting what was there literally within 6 seconds of booting using the default selection in UEFI mode. That is insanely dumb and dangerous for auto-selected boot options of an installer ISO.

Both barrels of that shotgun are firmly aimed at your foot as you press the VM Power On button and wait for the UEFI boot selection menu to appear, hoping you aren’t delayed accessing the VM console or there isn’t input lag during the 5 second boot autoselection that instantly destroys your VM disk.

If you have a specific question to ask then ask, if your purpose is just to rant. Well that’s your choice but unlikely to achieve much other than annoying the community.

If you feel there is a bug or a feature improvement then log it using https://issues.freepbx.org

Personally I haven’t used VMWare to deploy but have created numerous KVM templates in Solus without issue.

You can’t really compare FreePBX with SwitchVox, particularly as they have a specific VM image and is a commercial/locked down product and is a very different beast to FreePBX.

As far as I know this is never recommended, not for FreePBX ISO nor for the Enterprise Linux distros on which it is based.

No need to be amazed. Installation is documented at Sangoma Documentation and clearly states that installing from ISO will take over the whole disk.

2 Likes

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.