Setting IP address as static deletes IPV4 on eth0

I’ve had this happen twice now.

Set up a brand new FreePBX 15 system on a Vultr VM.
go through install, perform all updates through the webui
go to admin > system admin > network settings > change eth0 from DHCP to static
reboot.

(Vultr support recommended this to keep the IP static)

system comes back online and you can’t connect. Use the vultr console to log in and the Eth0 is not up, bring it up and it now has an IPV6 address.

I’ve had this happen twice now in the last 3 days with two different fresh builds.

look into /etc/sysconfig/network-scripts/ifcfg-eth0 and the file is now empty.

repopulating it with proper data and trying to bring it back up doesn’t work and it still comes up with IPV6 address somehow.

currently re-installing this system from scratch with the latest distro ISO to reproduce the issue.

re-installed system from ISO
activated it with prior ID
bypassed all updates and went directly to admin > system admin > network settings
set IP to static
saved network settings.

ifcfg-eth0 changed but remained correct.

will now do all module updates and re-test changing the eth0 IP from static to DHCP and then back again.

Just a bit of info, I’ve been using hosted vultr FreePBX for a while now problem free its been great. Since Vultr assigns a static ip I did not also set it as static in FreePBX and has been problem free working great for a long time…just an FYI

yes almost all of my systems are now vultr. I originally reserved IP’s to ensure they stayed static but was informed by Vultr support not to do this as there is a limit. While they’re vm IP’s “generally” should stay static they advise any systems I build (FreePBX or otherwise) should be set to static and not DHCP “just to be safe.”

Not sure how valid this advice is as it’s more an issue on the DHCP Server side but that’s what I was told. I’ve been changing all my FreePBX systems on vultr to static for literally years now and never had an issue until now.

All module updates applied and the the issue cannot be reproduced.

now applying system updates through FreePBX gui and will retest

all system updates applied and cannot reproduce the issue.

initiating the firewall setup script and re-testing

firewall enabled and tested, can’t reproduce…

That is not how things work.

1 Like

Not the issue… It’s was 100% a FreePBX issue. But I can’t reproduce it now so not sure what was up.

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