[Fixed] Upgrade from 1.2.3: Interfaces dead on reboot, OpenVPN not setup
-
Upgraded from 1.2.3 Release to 2.0 RC1. Two major issues:
- Log errors like this (excerpt: full log available)
Warning: Invalid argument supplied for foreach() in /etc/inc/util.inc on line 629 Warning: Invalid argument supplied for foreach() in /etc/inc/util.inc on line 592 Syncing OpenVPN settings... Warning: Cannot use a scalar value as an array in /etc/inc/openvpn.inc on line 702 done. Starting syslog...done. Warning: Cannot use a scalar value as an array in /etc/inc/shaper.inc on line 3669 Warning: Invalid argument supplied for foreach() in /etc/inc/util.inc on line 629 Configuring firewall. Warning: Invalid argument supplied for foreach() in /etc/inc/util.inc on line 629 Warning: Invalid argument supplied for foreach() in /etc/inc/util.inc on line 629 . Warning: Cannot use a scalar value as an array in /etc/inc/shaper.inc on line 3669 Warning: Invalid argument supplied for foreach() in /etc/inc/util.inc on line 629 .. Warning: Cannot use a scalar value as an array in /etc/inc/shaper.inc on line 3899 Warning: Cannot use a scalar value as an array in /etc/inc/shaper.inc on line 3901 Warning: Cannot use a scalar value as an array in /etc/inc/shaper.inc on line 3902 Warning: Cannot use a scalar value as an array in /etc/inc/shaper.inc on line 3939 Warning: Cannot use a scalar value as an array in /etc/inc/shaper.inc on line 3941 Warning: Cannot use a scalar value as an array in /etc/inc/shaper.inc on line 3942 Warning: Cannot use a scalar value as an array in /etc/inc/shaper.inc on line 3669 ..done.
I've read some posts here where use of "foreign" characters such as the umlaut can cause these errors; I'm using an American English keyboard and don't see any such characters in the config XML file.
- All interfaces inactive:
LAN (lan) -> em3 -> NONE WAN (wan) -> fxp0 -> NONE (DHCP) WIFI (opt1) -> em2 -> NONE
Using the console to set the interface IP brought the LAN up. In the GUI, the WAN and WiFi were checked as enabled on the Interfaces menu (and IP's / DHCP etc are correct), but show down in Status:Interfaces. Going to the Interface menu and Saving the page brings those up.
This persists through reboots.
Also, each reboot shows migration of each RRD database to new format…shouldn't this only happen on the first boot of 2.0?
Edit to add: My OpenVPN (server) configuration was apparently not imported...no certificates/CA/other settings. The data is in the config XML file.
-
please email me a copy of your 1.2.3 config file. cmb at pfsense dot org
-
Looks like what others have hit that had international characters in a description field, causing the config to be tossed out/not parsed.
-
Jim, I agree that the symptoms are similar; however, I use an American English keyboard, don't use, and didn't see, any int'l characters in the config. Sent a copy of the config file to cmb per his request. (Sent both the 2.0 and 1.2.3 configs; read his note too quickly…)
Thanks for all the help!
-
If you want me to look it over, I can do so also. (jimp (at) pfsense [dot] org) cmb probably won't be back online until later today.
-
Looks like it might be something in your openvpn server config. I see you had openvpn-enhancements installed, that apparently modified your openvpn server settings in an unexpected way that made the upgrade process die.
I'll keep poking at it and see if I can figure out what might be happening there.
-
Jim, thanks for the hints. I deleted all packages (within pfSense), then restored from a backup from 1.2.3 that was made to exclude packages. It rebooted without errors on the console, and the interfaces all came up.
I'm going to reinstall packages, and reconfigure OpenVPN using the built-in cert manager (not a big deal as I only use the server myself to get into my network when traveling…only one client, IOW.
Thanks MUCH for your help!
-
Good news then. Though I am curious what exactly about your old OpenVPN config made it bomb. Just removing the OpenVPN server config was enough to make it continue without problems, though replacing that section with one from a known-good config also bombed, so there may have been some other strange combination of factors going on there.
Tossing the packages and starting over isn't a bad idea in that situation.