Upgrade to v14 error > Network

I am attempting to upgrade a FreePBX install from v13 to v14. Everything went okay until “Stage 2.” It made it through the Mariadb upgrade, but failed at “Attempting to check for internet connectivity.”

“Aborting as we are unable to detect an internet connection. After configuring your internet connectivity, please run mv /var/run/post_sngupdate /var/run/post_sngupdate.old && /usr/sbin/post_upgrade”

The box had internet connectivity before starting the upgrade (it needed it to start the process), and nothing has changed. I do note that the machine has a static IP and there is not a DHCP server available to it. I am also able to ping the machine, so its network adapter is up and has the correct IP.

The process is stuck at that last message indicating to run the move command, but there is no prompt and I am unable to type anything. The machine is responsive, as the screen periodically goes to a blank screen but can be woken by pressing a key.

I also note that I am able to log in via SSH, and from there, ping by IP address. It appears that I am unable to resolve names, however. Again, this worked just fine prior to initiating the upgrade.

Any thoughts on how to proceed?

1 Like

Hi!

This has a lot of similarities with the problem some of us had early on.

Do you have DAHDI hardware or are using a VM?

Back when I upgraded this was what seemed to be causing the problem…

(Some of those cards like the Sangoma A200 appear as network cards to the system and seemed to cause problems.)

Did you check the content of resolv.conf, does it make sense?

At one point network connectivity got restored on my system and I am not sure why to this day…

I do know that on my system I had to disable the firewall at one point because it was causing me trouble…

Can you try this?

iptables -F
iptables -X
iptables -t nat -F
iptables -t nat -X
iptables -t mangle -F
iptables -t mangle -X
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT

This is just a temporary solution to see if clearing things make any difference, you will lose those as soon as you reboot…

By the way, have you created your ticket and uploaded the two logs as described in the troubleshooting section?

Good luck and have a nice day!

Nick

Almost forgot…

I think you can cancel it with Ctrl-C and you can also open a new terminal with ALT-F2 (ALT-F3, etc…)

Good luck and have a nice day!

Nick

I have the same issue but it is a slightly different ending. When my upgrade halts at that point eth0 is no longer present even though /etc/sysconfig/network-scripts/ifcfg-eth0 is still there. Also if I try to run system-config-tui it errors as well. leaving the machine offline to the internet.

Hi!

What is your network card, any possibility it is no longer supported?

Good luck and have a nice day!

Nick

Ah, I do have an A200.

I will take a look at your other suggestions…

Hi!

An easy way to see if it makes a difference might be to remove the card temporarily…

The script you ran has quite a few problems that were present when I ran it over a month ago fixed, Back when I run it looks like something I did at one point somehow got me out of the no network connectivity problem.

Somehow, while trying to fix some of those problems, network connectivity got restored…

The A200 I have (and other DAHDI hardware (including another A200) another early tester had) seemed to play a part in our loss of network connectivity.

Mind you, there were other DAHDI and Wanpipe problems present that you should no longer have but I had to get unstuck from that loss of network connectivity to have them…

After that problem got apparently resolved I could not access the FreePBX GUI and I had to disable both the iptables and firewalld service if I recall correctly.

I do not recall anybody else mentioning this problem and I am not sure why this was needed. Not everyone has telephony hardware (like the A200) and not everyone’s setup essentially put the PBX in a DMZ of sorts…

(A real DMZ, a different subnet with it’s own firewall rules, usually more server than the main LAN…)

The other person who had network connectivity problem and telephony hardware had to restore from a backup so i do not know if he would have had the same problem or not…

To this day I still have one problem related to the Wanpipe drivers… About 4 of the about 5 minutes of the boot time of my system are taken by them:

re:

Sep 9 09:18:17 jester wanrouter: Configuring interfaces: w1g1
Sep 9 09:18:17 jester wanrouter: done.
Sep 9 09:18:17 jester wanrouter: Waiting for Dahdi /dev/dahdi …
Sep 9 09:22:42 jester systemd: wanrouter.service start operation timed out. Terminating.
Sep 9 09:22:42 jester systemd: Failed to start SYSV: WANPIPE WAN Router Initialization Script…
Sep 9 09:22:42 jester systemd: Unit wanrouter.service entered failed state.
Sep 9 09:22:42 jester systemd: wanrouter.service failed.
Sep 9 09:22:42 jester systemd: Starting LSB: Bring up/down networking…
Sep 9 09:22:43 jester network: Bringing up loopback interface: [ OK ]
Sep 9 09:22:43 jester kernel: sky2 0000:04:00.0 eth0: enabling interface

Looks like something times out at 09:22:42 after running since 09:18:17…

Interesting tidbit, can you see what gets initialized after the wanrouter? :wink:

Things works after that and if I stop and then start them once the system is up they take nowhere that time… They perform flawlessly as far as I can see, it’s only that initial initialization that fails in this way…

Keep us posted and good luck and have a nice day!

Nick

Did you make progress on solving this? I am seeing this on one of my machines. It is running in a VMWare instance.

It is unlikely that you need wanrouter on a VMWARE machine (or any machine for that matter unless you have Sangoma hardware), you should

systemctl disable wanrouter

and try again.

Thanks.

This is more to do with this message than the wanrouter:

Hi!

I believe @waldrondigital had a similar problem with a VM install…

He had to change something on his virtual network card I believe…

Let me dig it up…

Good luck and have a nice day!

Nick

Found it…

Good luck and have a nice day!

Nick

1 Like

If you disable wanrouter then it is quite possible that you WILL have network connectivity, if

ip address

shows any spurious interfaces , and

ip route

shows a bad default and

cat /etc/resolve.conf

is nonsense , then you won’t have network connectivity to to named internet sites.

Thanks! Taking a look now, and will report back how it goes.

[quote]
shows any spurious interfaces[/quote]

Interesting…I think IPv6 is enabled…would that cause issues as well?

It shouldn’t but if you have only ipv4 then I suggest you disable it.

You are welcome!

Keep us posted!

Back when we upgraded (or tried to, I don’t know if @waldrondigital was able to ensuccessfully upgrade one of his installs) the two things that appeared to causes issues were VM related (like the network card) or DAHDI hardware that appeared as network cards…

(In my case, my Sangoma A200…)

I am pretty sure it’s active on mine and doesn’t cause problems (but then, things that don’t cause any problems for some end up causing problems for others) but I am not running this on a VM.

I do recall that someone reported this recently:

He was not talking of a total loss of network connectivity, only DNS problems (which would look like a loss of network connectivity), but that’s something to keep in mind…

Good luck and have a nice day!

Nick

If you have debian +8 or perhaps centos >= 7 then there is a chance that your eth devices are now ens devices if “virtualized” , check your

dmesg for that, if so then I would perhaps look at

https://access.redhat.com/solutions/2592561

If this specifies a UUID for the interface you may want to remove it. I had this issue too. The UUID had changed somehow during the process, perhaps due to the newer kernel.

Your udev rules might well impact the nameing of your network devices, I prefer the good old ethN (not ens or uuid :wink: ) usage both in udev and your network interfaces definitions, many older scripts just expect that the internet is available through /dev/eth0 , and there is no downside to reverting to that naming as far as I know. You might need to add some kernel options to grub if you want to do that though

https://access.redhat.com/discussions/916973