2.3.3 is live!

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.

Keyser Soze

I was skeptical given the numerous upgrade problem threads compounded with my own past experiences of upgrade problems, always having to manually reinstall packages and etc to get things going again.

Performed a CLI (option 13) update to v2.3.3 and much to my astonishment, it just worked.

NOYB

How many of you do a "sane" upgrade process. Like reboot first to make sure everything comes up clean before compounding any issues that may be lurking with a upgrade?

RonpfS

And also disable packages like Snort/Suricata/pfBlockerNG/etc before the reboot .

mifronte

Just completed the upgrade via the web dashboard with success.

BIGGRIMTIM

Had to do a complete clean install. Restored config and things are working again.

Jailer

@NOYB:

How many of you do a "sane" upgrade process. Like reboot first to make sure everything comes up clean before compounding any issues that may be lurking with a upgrade?

Never have and I've never had an upgrade problem in the 2+ years I've been using pfSense.

NOYB

@Jailer:

@NOYB:

How many of you do a "sane" upgrade process. Like reboot first to make sure everything comes up clean before compounding any issues that may be lurking with a upgrade?

Never have and I've never had an upgrade problem in the 2+ years I've been using pfSense.

I always do. And until this time the pre-upgrade reboot always went fine. This time pfSense wouldn't shutdown. Config write or some such thing had it locked. Dropped to shell and forced it to shutdown.

Just can't wonder how many of the issues people have are due to some obscure issue lurking that would be cleared away by a pre-upgrade reboot. Know it shouldn't be necessary but think it is a good practice anyway.

chpalmer

@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.

This is what I had to do as well for just one box.. All my others upgraded just fine.

pppfsense

Shouldn't the 'smart' upgrade process take care of this and anything else 'needed'?

@RonpfS:

And also disable packages like Snort/Suricata/pfBlockerNG/etc before the reboot .

Jailer

I've never disabled my packages either (snort, pfblockerng) and never had an issue with an upgrade.

RonpfS

The idea is to prevent anything blocking while doing the update.