2.3.3 is live!

doktornotor

@chpalmer:

@BIGGRIMTIM:

Am I the only one who is still showing 2.3.2 on the system info, but 2.3.3 in the update tab? I am not sure if this is a big deal.

Try what Phil said above-

On my 2.3.3-RC that was on "Stable" (because that is what was done when 2.3.3-DEVELOPMENT became 2.3.3-RC - to avoid ending up on 2.3.4-DEVELOPMENT), I:

switched to development on GUI Update Settings

used console option 13 to make it look for the development package database, and when it asked to upgrade I said N

switched back to stable on GUI update settings

used console option 13 again, and it found the "right" stable stuff, said "y" to upgrade

I am not sure if that sequence should really be needed, but for me it got the system recognize the "new stable" and upgrade to it.

Ive got one box that seems to want to stick to 2.3.2 as well.. Fought with it several times yesterday. Its nano and really slow.. Im trying this now. Ill update if this works for this one. All my others upgraded without a hitch.

As far as I can tell the system has been updated but the dashboard is still reporting 2.3.2 as my picture shows.

Do


cat /etc/version*

and check what's there.

chpalmer

@BIGGRIMTIM:

As far as I can tell the system has been updated but the dashboard is still reporting 2.3.2 as my picture shows.

Nah- Im seeing the same thing on my only "nano" box..


Duplicate slice required!!

Before starting the upgrade process, the currently mounted nanobsd partition
needs to be cloned to the secondary partition, where the update will happen

After installation a reboot will be required to switch partition.

>>> Cleaning secondary partition... done.
>>> Duplicating current slice... done.
>>> Restoring slice label... done.
>>> Testing duplicated partition integrity... done.
>>> Mounting second partition to run upgrade... done.
>>> Copying resolv.conf to upgrade partition... done.
>>> Downloading upgrade packages... 
Updating pfSense-core repository catalogue...
Unable to update repository pfSense-core
Updating pfSense repository catalogue...
Unable to update repository pfSense
All repositories are up-to-date.
pkg: Repository pfSense-core cannot be opened. 'pkg update' required
pkg: Repository pfSense cannot be opened. 'pkg update' required
Checking for upgrades (0 candidates): . done
Processing candidates (0 candidates): . done
Checking integrity... done (0 conflicting)
Your packages are up to date.
>>> Locking package pfSense-pkg-Shellcmd... done.
>>> Locking package pfSense-pkg-routed... done.
>>> Unlocking package pfSense-pkg-Shellcmd... done.
>>> Unlocking package pfSense-pkg-routed... done.
>>> Setting secondary partition as active... done.
Upgrade is complete.  Rebooting in 10 seconds.
>>> Locking package pfSense-kernel-pfSense_wrap... done.
Success

[2.3.2-RELEASE][admin@x0x0x]/root: cat /etc/version*
2.3.2-RELEASE
Tue Sep 27 12:13:32 CDT 2016

Tried "Pkg Upgrade" with this end response-

pkg: Cannot get an advisory lock on a database, it is locked by another process

BIGGRIMTIM

@doktornotor:

@BIGGRIMTIM:

@chpalmer:

@BIGGRIMTIM:

Am I the only one who is still showing 2.3.2 on the system info, but 2.3.3 in the update tab? I am not sure if this is a big deal.

Try what Phil said above-

On my 2.3.3-RC that was on "Stable" (because that is what was done when 2.3.3-DEVELOPMENT became 2.3.3-RC - to avoid ending up on 2.3.4-DEVELOPMENT), I:

switched to development on GUI Update Settings

used console option 13 to make it look for the development package database, and when it asked to upgrade I said N

switched back to stable on GUI update settings

used console option 13 again, and it found the "right" stable stuff, said "y" to upgrade

I am not sure if that sequence should really be needed, but for me it got the system recognize the "new stable" and upgrade to it.

Ive got one box that seems to want to stick to 2.3.2 as well.. Fought with it several times yesterday. Its nano and really slow.. Im trying this now. Ill update if this works for this one. All my others upgraded without a hitch.

As far as I can tell the system has been updated but the dashboard is still reporting 2.3.2 as my picture shows.

Do
cat /etc/version*
and check what's there.

Thanks for the help. Here is the output from the command:

"2.3.2-RELEASE
Tue Sep 27 12:13:07 CDT 2016
e936f18c1ad0b847cc1133d376f9950f4770c360
0"

So my upgrade didn't complete, if this info is correct.

NogBadTheBad

Name xxx.xxx.xxx
System Netgate SG-4860
Serial: 1116160595
Version 2.3.3-RELEASE (amd64)
built on Thu Feb 16 06:59:53 CST 2017
FreeBSD 10.3-RELEASE-p16
Platform pfSense
CPU Type Intel(R) Atom(TM) CPU C2558 @ 2.40GHz
4 CPUs: 1 package(s) x 4 core(s)
Hardware crypto AES-CBC,AES-XTS,AES-GCM,AES-ICM
Uptime 19 Hours 18 Minutes 08 Seconds
Current date/time
Tue Feb 21 18:40:56 GMT 2017

19 Hrs uptime all good here :)

Gertjan

Same here : all ok;

(but : I'm using the dyndns RFC 2136 - and something went wrong, what can be seen when you use the GUI 'DynDNS' widget. I found out what is was : the usage of the separators "|" and ":" are mixed up (/etc/inc/services.inc I guess) when assembling the IP cache files - so the 'explode' will fail later on. I'll post some more details later on.)

cthomas

Successfully upgraded four stand-alone pfSense firewalls, three virtual, one physical, without incident.

Then, I successfully upgraded five pairs of redundant pfSense firewalls, handling production workloads, in the middle of the day, without incident.

The last three upgrades I have performed on our redundant Cisco firewalls were not as smooth. Great work guys, truly great work, thank you.

…v

DiskWizard

No go 2.3.2_1 -> 2.3.3 from GUI, the current version remains, going to try console tomorrow.

RonpfS

@phil.davis:

On my 2.3.3-RC that was on "Stable" (because that is what was done when 2.3.3-DEVELOPMENT became 2.3.3-RC - to avoid ending up on 2.3.4-DEVELOPMENT), I:

switched to development on GUI Update Settings

used console option 13 to make it look for the development package database, and when it asked to upgrade I said N

switched back to stable on GUI update settings

used console option 13 again, and it found the "right" stable stuff, said "y" to upgrade

I am not sure if that sequence should really be needed, but for me it got the system recognize the "new stable" and upgrade to it.

Did the same to get the WebGUI to offer 2.3.3-RELEASE (i386), I updated with the WebGUI, it rebooted, updated and then I got a double fault crash after starting the package.

2017-02-21 16:20:11	System4.Info	172.x.x.254	Feb 21 16:20:13 kernel: Starting syslog...done.
2017-02-21 16:20:11	System4.Info	172.x.x.254	Feb 21 16:20:13 kernel: Starting CRON... done.
2017-02-21 16:20:11	Cron.Info	172.x.x.254	Feb 21 16:20:13 /usr/sbin/cron[57535]: (CRON) DEATH (cron already running, pid: 25377)
2017-02-21 16:20:11	Daemon.Error	172.x.x.254	Feb 21 16:20:13 php-fpm[483]: /rc.start_packages: Restarting/Starting all packages.
2017-02-21 16:20:11	System4.Info	172.x.x.254	Feb 21 16:20:13 kernel: Starting package Backup...done.
2017-02-21 16:20:11	System4.Info	172.x.x.254	Feb 21 16:20:13 kernel: Starting package Cron...done.
2017-02-21 16:20:11	System4.Info	172.x.x.254	Feb 21 16:20:13 kernel: Starting package System Patches...done.
2017-02-21 16:20:11	Daemon.Notice	172.x.x.254	Feb 21 16:20:13 php-fpm[483]: [pfBlockerNG] Starting cron process.
2017-02-21 16:20:15	User.Notice	172.x.x.254	Feb 21 16:20:17 check_reload_status: Syncing firewall
2017-02-21 16:20:15	Daemon.Error	172.x.x.254	Feb 21 16:20:17 php-fpm[483]: /rc.start_packages: Beginning https://portal.pfsense.org configuration backup.
2017-02-21 16:20:28	Daemon.Error	172.x.x.254	Feb 21 16:20:30 php-fpm[483]: /rc.start_packages: End of portal.pfsense.org configuration backup (success).

**** Crash & Reboot ****

2017-02-21 16:22:46	System4.Info	172.x.x.254	Feb 21 16:22:48 kernel: Configuring LAN interface...done.
2017-02-21 16:22:46	System4.Info	172.x.x.254	Feb 21 16:22:48 kernel: Configuring TEST interface...done.
```After rebooting system seems fine.

I had a similar double fault crash last week after switching from Development to Stable in order to get 2.3.3-RC, but I didn't update before the system crashed while saving an alias and applying change.

BIGGRIMTIM

Tried Phil's option and still not working. Last night I was prompted to update via the GUI so I did and it said it completed successfully. My dashboard is still reporting 2.3.2, however when I go to the update page it reports 2.3.3 as my pics from my previous post shows. Should I try to update to the 2.3.4 development build? If I do can I go back to the stable channel?

ats1995

Name xxx.xxx.xxx
System PC Engines APU2
Serial: –------------------------
Version 2.3.3-RELEASE (amd64)
built on Thu Feb 16 06:59:53 CST 2017
FreeBSD 10.3-RELEASE-p16

Obtaining update status
Platform pfSense
CPU Type AMD GX-412TC SOC
4 CPUs: 1 package(s) x 4 core(s)
Uptime 02 Hours 09 Minutes 27 Seconds
Current date/time
Wed Feb 22 1:20:42 CET 2017

Humble home user here. All good so far.

dpa

Update is flawless. But it seems that the new d3.js traffic graph is flawed. It's reporting that I have a Terrabyte traffic!

Guldil

@DiskWizard:

No go 2.3.2_1 -> 2.3.3 from GUI, the current version remains, going to try console tomorrow.

Same here with a NanoBSD, can't upgrade, i did 3 times : upgrade / reboot / switch splice and finally it's worked…

Jon Centel

everything looks fine - but

from the console menu brings

Another instance is already running… Aborting!

is this ok ?

*** Welcome to pfSense 2.3.3-RELEASE (amd64 full-install) on tantefrida ***

Logout (SSH only) 9) pfTop
Assign Interfaces 10) Filter Logs
Set interface(s) IP address 11) Restart webConfigurator
Reset webConfigurator password 12) PHP shell + pfSense tools
Reset to factory defaults 13) Update from console
Reboot system 14) Disable Secure Shell (sshd)
Halt system 15) Restore recent configuration
Ping host 16) Restart PHP-FPM
Shell

Enter an option: 13

Another instance is already running... Aborting!

ajm

Just upgraded from an initial install of 2.3.2_p1 to 2.3.3-RELEASE.

This completed without error, the system came back up and was working almost perfectly after the reboot.

The only issue spotted so far, is that the DHCP server now fails to use the System-defined DNS server addresses, and instead issues the network interface address as the DNS server. I therefore had to hardcode the correct address in each network config.

I'm very pleased that the team were able to release 2.3.3 alongside all the work going on on later versions.

Fingers crossed my boxes will now stay up longer than 3 weeks without falling over…

phil.davis

The only issue spotted so far, is that the DHCP server now fails to use the System-defined DNS server addresses, and instead issues the network interface address as the DNS server. I therefore had to hardcode the correct address in each network config.

Start a new separate thread about this. I am surprised, but it needs looking into if you have some unusual case here. It would be better to discuss/debug in its own thread.

phil.davis

@Jon:

everything looks fine - but

from the console menu brings

Another instance is already running… Aborting!

is this ok ?

*** Welcome to pfSense 2.3.3-RELEASE (amd64 full-install) on tantefrida ***

Logout (SSH only) 9) pfTop

Assign Interfaces 10) Filter Logs

Set interface(s) IP address 11) Restart webConfigurator

Reset webConfigurator password 12) PHP shell + pfSense tools

Reset to factory defaults 13) Update from console

Reboot system 14) Disable Secure Shell (sshd)

Halt system 15) Restore recent configuration

Ping host 16) Restart PHP-FPM

Shell

Enter an option: 13

Another instance is already running... Aborting!

That happens if you started an update check from the webGUI, and maybe when the dashboard is retrieving the update status.
So after some seconds/minute, option 13 should work.

Derelict

@phil.davis:

The only issue spotted so far, is that the DHCP server now fails to use the System-defined DNS server addresses, and instead issues the network interface address as the DNS server. I therefore had to hardcode the correct address in each network config.

Start a new separate thread about this. I am surprised, but it needs looking into if you have some unusual case here. It would be better to discuss/debug in its own thread.

That is and has pretty much always been the default behavior.

DHCP hands out the interface address to clients unless something else is defined there.

The System > General DNS server addresses are used by default by the DNS forwarder / DNS Resolver in forwarding mode to fulfill those requests.

Unless both forwarder and resolver are disabled, in which case the System > General DNS servers are used for DHCP.

ETA: Just ran through a few permutations and could not duplicate.

ajm

@Derelict:

@phil.davis:

The only issue spotted so far, is that the DHCP server now fails to use the System-defined DNS server addresses, and instead issues the network interface address as the DNS server. I therefore had to hardcode the correct address in each network config.

Start a new separate thread about this. I am surprised, but it needs looking into if you have some unusual case here. It would be better to discuss/debug in its own thread.

That is and has pretty much always been the default behavior.

DHCP hands out the interface address to clients unless something else is defined there.

The System > General DNS server addresses are used by default by the DNS forwarder / DNS Resolver in forwarding mode to fulfill those requests.

Unless both forwarder and resolver are disabled, in which case the System > General DNS servers are used for DHCP.

ETA: Just ran through a few permutations and could not duplicate.

Thanks for the quick response.

I just re-read the relevant note on the DHCP server config page; "Leave blank to use the system default DNS servers: this interface's IP if DNS Forwarder or Resolver is enabled, otherwise the servers configured on the System / General Setup page."

I had been running BIND since the initial setup, but for a week or so prior to the 2.3.3 upgrade had switched to Unbound in an attempt to identify the cause of a general 'lock-up' after ~1-3 weeks running. Disabling BIND did not fix this, and I've reverted to BIND after the upgrade.

It seems that enabling then disabling Unbound may have set a flag somewhere that caused what I'm seeing ?

ajm

@ajm:

Thanks for the quick response.

I just re-read the relevant note on the DHCP server config page; "Leave blank to use the system default DNS servers: this interface's IP if DNS Forwarder or Resolver is enabled, otherwise the servers configured on the System / General Setup page."

I had been running BIND since the initial setup, but for a week or so prior to the 2.3.3 upgrade had switched to Unbound in an attempt to identify the cause of a general 'lock-up' after ~1-3 weeks running. Disabling BIND did not fix this, and I've reverted to BIND after the upgrade.

It seems that enabling then disabling Unbound may have set a flag somewhere that caused what I'm seeing ?

Update: panic over, I just backed-out of my workaround and it's behaving fine now. Possibly the sequence of changes I made to disable Unbound and re-enable BIND may have a required a restart of DHCP which I didn't do, so it got its knickers in a twist..

Apologies for the noise. I'm a happy camper for now :)

DiskWizard

Okay, I finally worked out my issue.
Console option 13 - no go as well, then I've tried option 8 (shell)
pkg update -f
pkg upgrade -f
System complain about about gcc has no blah-blah-blah = n
Seems like working fine now.
Best regards.