May 2nd Snapshot doesnt work, breaks everything! Beware
-
Should I see the snapshot? My SG-3100 says I am up to date with the last update being from April 25th.
"built on Wed Apr 25 02:28:12 CDT 2018"If you see that, you're probably on the Factory images and not CE. Factory needs more work before the FreeBSD 11-STABLE (11.2-PRERELEASE) builds are ready.
-
Should I see the snapshot? My SG-3100 says I am up to date with the last update being from April 25th.
"built on Wed Apr 25 02:28:12 CDT 2018"If you see that, you're probably on the Factory images and not CE. Factory needs more work before the FreeBSD 11-STABLE (11.2-PRERELEASE) builds are ready.
Yes, thats it. The SG-3100 is still within the first year so it gets the factory image. No rush, just curious.
-
Should I see the snapshot? My SG-3100 says I am up to date with the last update being from April 25th.
"built on Wed Apr 25 02:28:12 CDT 2018"If you see that, you're probably on the Factory images and not CE. Factory needs more work before the FreeBSD 11-STABLE (11.2-PRERELEASE) builds are ready.
Yes, thats it. The SG-3100 is still within the first year so it gets the factory image. No rush, just curious.
You can use the factory image indefinitely, not just the first year.
-
I suspect I may have found part of the issue people are seeing in this thread:
https://redmine.pfsense.org/issues/8495
It's possible that your firewall never rebooted after updating and it's running half updated, if you run /etc/rc.reboot that will do most of the process but the last command fails, you can then safely run 'reboot' after to finish the job.
For example:
/etc/rc.reboot /sbin/rebootOnce you're on a snap with the fix I just committed for that bug it will restart itself OK again.
-
I suspect I may have found part of the issue people are seeing in this thread:
https://redmine.pfsense.org/issues/8495
It's possible that your firewall never rebooted after updating and it's running half updated, if you run /etc/rc.reboot that will do most of the process but the last command fails, you can then safely run 'reboot' after to finish the job.
For example:
/etc/rc.reboot /sbin/rebootOnce you're on a snap with the fix I just committed for that bug it will restart itself OK again.
Ran the commands and my DHCP connection still isn't coming back.
May 3 17:12:25 php-fpm 324 /interfaces.php: The command '/sbin/dhclient -c /var/etc/dhclient_opt1.conf igb2 > /tmp/igb2_output 2> /tmp/igb2_error_output' returned exit code '15', the output was ''
-
I just updated to 2.4.4 built on Thu May 03 18:39:20 CDT 2018 and it's generating a crash report, which I sent.
I'm still having dhcpv6 problems. I put wireshark on it and there do not seem to be any ipv6 messages at all.
-
Getting this error now in console with build: 2.4.4.a.20180503.1839
-
Something is definitly wrong with those builds, I cant halt or reboot via gui or ssh…
-
I reverted to 2.4.3 release and it works fine.
-
Same here, DNS Resolver and DHCP not starting after update, update never rebooted and ran half updated for 1-2 days, until i reverted back to stabile 2.4.3 with no problems.
-
Getting this error now in console with build: 2.4.4.a.20180503.1839
I can replicate that, but it appears harmless: https://redmine.pfsense.org/issues/8497
-
Something is definitly wrong with those builds, I cant halt or reboot via gui or ssh…
Please read the thread. That has been addressed.
-
/etc/rc.reboot
/sbin/rebootThis code helped. Runtime now reseted.
-
I can confirm this issue is still in the latest 5-04 snapshot
Running the above commands did not help
/etc/rc.reboot
/sbin/reboot -
I am still having issues with the new snapshot (5/4) too. I have 3 WAN connections and the two statics still seem to be working, but the appliance I have screeches to a halt after upgrading. I also cannot get a DHCP address on the third connection. Attached is the errors I get on initial boot and sequential reboots result the same.
 -
I can confirm this issue is still in the latest 5-04 snapshot
Running the above commands did not help
/etc/rc.reboot
/sbin/rebootThere is no "this issue" in this thread. You need to provide details about exactly what is not working, with console and/or log entries related to the issue.
-
I am still having issues with the new snapshot (5/4) too. I have 3 WAN connections and the two statics still seem to be working, but the appliance I have screeches to a halt after upgrading. I also cannot get a DHCP address on the third connection. Attached is the errors I get on initial boot and sequential reboots result the same.
Please at least post the DHCP log and any dhclient entries from it, and anything that looks relevant in the system or routing logs as well.
I can't replicate any DHCP client issues here, mine are all working OK.
-
Unfortunately I had to rebuild it so I could post this so I only have my syslog to go back to. I am using the 2.4.4-DEVELOPMENT (amd64) built on Thu Apr 26 14:32:50 CDT 2018 FreeBSD 11.1-STABLE snapshot to restore to and the C2758 board you used to use. When I upgrade to the latest snapshot, I am unable to do much of anything with the appliance. It looks like it just keeps bouncing the interface for that wan.
dpinger: HOME_DHCP 47.34.34.1: sendto error: 65
check_reload_status: Configuring interface wan
php-fpm[87613]: /rc.newwanip: rc.newwanip: Failed to update wan IP, restarting…
php-fpm[87613]: /rc.newwanip: rc.newwanip: on (IP address: ) (interface: HOME[wan]) (real interface: igb2).
php-fpm[87613]: /rc.newwanip: rc.newwanip: Info: starting on igb2.
dpinger: HOME_DHCP 47.34.34.1: sendto error: 65
kernel: arpresolve: can't allocate llinfo for 47.34.34.1 on igb2
dhclient[20017]: exiting.
dhclient[20017]: connection closed
dpinger: HOME_DHCP 47.34.34.1: sendto error: 65
kernel: arpresolve: can't allocate llinfo for 47.34.34.1 on igb2
kernel: arpresolve: can't allocate llinfo for 47.34.34.1 on igb2
php-fpm[43905]: /rc.linkup: HOTPLUG: Configuring interface wan
php-fpm[43905]: /rc.linkup: DEVD Ethernet attached event for wan
dhclient: /sbin/route add default 47.34.34.1
dhclient: Adding new routes to interface: igb2
dhclient: New Routers (igb2): 47.34.34.1
dhclient: New Broadcast Address (igb2): 255.255.255.255
dhclient: New Subnet Mask (igb2): 255.255.254.0
dhclient: New IP Address (igb2): 47.34.X.X
charon: 13[KNL] 47.34.X.X appeared on igb2
charon: 13[KNL] 47.34.X.X disappeared from igb2
dhclient: ifconfig igb2 inet 47.34.X.X netmask 255.255.254.0 broadcast 255.255.255.255
dhclient: Starting add_new_address()
dhclient: REBOOT
kernel: igb2: link state changed to DOWN
check_reload_status: Linkup starting igb2
HOME_DHCP 47.34.34.1: sendto error: 64 -
JimP, I can send you a 4m syslog from the time of upgrade if you would like.
after thumbing through more of the syslog, it seems pretty consistent on these repeated lines:
php-fpm[43905]: /rc.linkup: DEVD Ethernet attached event for wan
php-fpm[43905]: /rc.linkup: HOTPLUG: Configuring interface wan
charon: 04[KNL] 47.34.X.X disappeared from igb2
kernel: arpresolve: can't allocate llinfo for 47.34.34.1 on igb2
kernel: arpresolve: can't allocate llinfo for 47.34.34.1 on igb2
dpinger: HOME_DHCP 47.34.34.1: sendto error: 65
dhclient[20017]: connection closed
dhclient[20017]: exiting.
kernel: arpresolve: can't allocate llinfo for 47.34.34.1 on igb2
dpinger: HOME_DHCP 47.34.34.1: sendto error: 65
php-fpm[87613]: /rc.newwanip: rc.newwanip: Info: starting on igb2.
php-fpm[87613]: /rc.newwanip: rc.newwanip: on (IP address: ) (interface: HOME[wan]) (real interface: igb2).
php-fpm[87613]: /rc.newwanip: rc.newwanip: Failed to update wan IP, restarting…
check_reload_status: Configuring interface wan
dpinger: HOME_DHCP 47.34.34.1: sendto error: 65 -
I will have to roll back to April Build until this is fixed.
My DHCP connection has the same errors as the poster above.
