Version 2.3.3_1 is available

guterkerl

I did the upgrade through ssh using option 13. I only have a few packages so didn't have any issues. uname shows p17

Installed packages to be UPGRADED:
	pfSense-rc: 2.3.3 -> 2.3.3_1 [pfSense-core]
	pfSense-pkg-tinc: 1.0.28_2 -> 1.0.28_3 [pfSense]
	pfSense-pkg-squidGuard: 1.15 -> 1.16 [pfSense]
	pfSense-pkg-squid: 0.4.36 -> 0.4.36_1 [pfSense]
	pfSense-pkg-darkstat: 3.1.3_3 -> 3.1.3_4 [pfSense]
	pfSense-kernel-pfSense: 2.3.3 -> 2.3.3_1 [pfSense-core]
	pfSense-default-config: 2.3.3 -> 2.3.3_1 [pfSense-core]
	pfSense-base: 2.3.3 -> 2.3.3_1 [pfSense-core]
	pfSense: 2.3.3 -> 2.3.3_1 [pfSense]
	curl: 7.52.1_1 -> 7.53.0 [pfSense]

Number of packages to be upgraded: 10

doktornotor

@jimp:

@doktornotor that IPsec error is harmless, strongSwan whines about that on FreeBSD because that check is Linux-y. https://wiki.strongswan.org/projects/1/wiki/FreeBSD#Known-Problems

Yeah I figured it's some sort of logspam, thanks.

segfooled

@jonese:

@segfooled:
===> Removing static obsoleted files
I had the exact same issue. Waited move than an hour. I figured I had accidentally canceled the web page or something…

I did note that I had a kernel locked or something message prior to that.

I rebooted and did the upgrade via the shell instead. It did some updating and things appear good now.

I hope future upgrades go smoother..... not exactly confidence inspiring with a problematic upgrade.

Ok to recap: I had not cancelled the WebUI updater, anyway it sat there at the above cleaning status and never rebooted. Upon manual reboot I was at 2.3.3_1 BUT p16.

Solved: Update via console (ssh) option 13). Kernel package was not updated apparently due to locked kernel. It updated via the console and rebooted to p17. WebUI now shows p17 as well.

I would assume that everybody seeing p16 in the WebUI has the locked kernel update issue, so go update via console/ssh to solve this.

Re-reading my upgrade page that I quoted earlier, it contains this line:```
pfSense-kernel-pfSense-2.3.3 is locked and may not be modified


No idea what locked the kernel… will probably do updates through the console in future.

doktornotor

The kernel package is locked normally on purpose (and only unlocked on upgrades). Dunno what makes the package manager think it's missing, it sure like hell wouldn't boot without kernel. Sigh…

kobzar

WG x750e updated from WEB without any troubles.

segfooled

@doktornotor:

The kernel package is locked normally on purpose (and only unlocked on upgrades). Dunno what makes the package manager think it's missing, it sure like hell wouldn't boot without kernel. Sigh…

Corrected above - at the console it didn't say missing kernel but something along the lines of wasn't updated last time because locked. Then it loaded the kernel package and updated it ok.
Also added the line from the initial updater that apparently pointed to the issue on the first run "locked … may not be modified".

empbilly

Here is version 2.3.3-RELEASE-p1 (amd64), but it showed FreeBSD 10.3-RELEASE-p16. Via the command line I made a```
pfSense-upgrade -d

bheinsius

This doesn't look like a very good upgrade.
I upgraded from 2.3.2.
DNS Forwarder could not find local hostnames for dhcp-issued ip addresses anymore.
Port forwarding did not work anymore (probably because of the dns problem).
I'm no firewall expert so I reverted to my 2.3.2 slice and all is ok again.

jimp

@bheinsius:

This doesn't look like a very good upgrade.
I upgraded from 2.3.2.
DNS Forwarder could not find local hostnames for dhcp-issued ip addresses anymore.
Port forwarding did not work anymore (probably because of the dns problem).
I'm no firewall expert so I reverted to my 2.3.2 slice and all is ok again.

If your DNS failed to work after the upgrade, it wasn't a proper DNS configuration to start with.
https://redmine.pfsense.org/issues/6064

Setting an appropriate search domain for the client will fix it in most cases.

bheinsius

I had these messages in the pfsense log:

filterdns failed to resolve host xxxx will retry later again.

search domain in client /etc/resolv.conf is fine:

bheinsius@kemphaan:~$ cat /etc/resolv.conf

Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf( 8 )

# DO NOT EDIT THIS FILE BY HAND – YOUR CHANGES WILL BE OVERWRITTEN
nameserver 10.0.0.1
search internal.abc.nl
bheinsius@kemphaan:~$

jimp

Then it doesn't match the domain on the firewall used/assumed for the hostnames. If it did, the short names would still resolve.

bheinsius

as i said before i'm no firewall expert.
can you help me where i may be missing this setting?

has dns in pfsense changed from 2.3.2 to 2.3.3 causing this problem to surface in 2.3.3 and not in 2.3.2?

jimp

Help would be a topic for a different thread. And if you read the release notes for 2.3.3 you'll find the answer about the changes.

bheinsius

ok, thank you.

fredfox_uk

Updated last night through the GUI as always, but got a failed message from the GUI. The messages said packages updated but kernel failed due to locked Kernel.

SSH and and ran a shell and used pfSense-upgrade -d.

Everything seems to be working ok.

Is there anything that I did wrong? I've never seen the kernel package being locked.

Here's the output :-


>>> Updating repositories metadata...
Updating pfSense-core repository catalogue...
pfSense-core repository is up-to-date.
Updating pfSense repository catalogue...
pfSense repository is up-to-date.
All repositories are up-to-date.
>>> Unlocking package pfSense-kernel-pfSense...
Unlocking pfSense-kernel-pfSense-2.3.3
The following 1 package(s) will be affected (of 0 checked):

Installed packages to be UPGRADED:
        pfSense-kernel-pfSense: 2.3.3 -> 2.3.3_1 [pfSense-core]

Number of packages to be upgraded: 1

15 MiB to be downloaded.

**** WARNING ****
Reboot will be required!!
Proceed with upgrade? (y/N) y
>>> Downloading upgrade packages...
Updating pfSense-core repository catalogue...
pfSense-core repository is up-to-date.
Updating pfSense repository catalogue...
pfSense repository is up-to-date.
All repositories are up-to-date.
Checking for upgrades (1 candidates): . done
Processing candidates (1 candidates): . done
The following 1 package(s) will be affected (of 0 checked):

Installed packages to be UPGRADED:
        pfSense-kernel-pfSense: 2.3.3 -> 2.3.3_1 [pfSense-core]

Number of packages to be upgraded: 1

15 MiB to be downloaded.
Fetching pfSense-kernel-pfSense-2.3.3_1.txz: .......... done
Checking integrity... done (0 conflicting)
>>> Upgrading pfSense kernel...
Checking integrity... done (0 conflicting)
The following 1 package(s) will be affected (of 0 checked):

Installed packages to be UPGRADED:
        pfSense-kernel-pfSense: 2.3.3 -> 2.3.3_1 [pfSense-core]

Number of packages to be upgraded: 1
[1/1] Upgrading pfSense-kernel-pfSense from 2.3.3 to 2.3.3_1...
[1/1] Extracting pfSense-kernel-pfSense-2.3.3_1: .......... done
===> Keeping a copy of current kernel in /boot/kernel.old
Upgrade is complete.  Rebooting in 10 seconds.

Broadcast Message from admin@pfSense.paulgh.me.uk
        (/dev/pts/0) at 23:44 GMT...

Upgrade is complete.  Rebooting in 10 seconds.

>>> Locking package pfSense-kernel-pfSense...
Locking pfSense-kernel-pfSense-2.3.3_1

mifronte

I upgraded via the web GUI dashboard and also received the update failed message in my browser. However, the router rebooted itself before I can get to the console and came up with the new update and all seems fine.

phil.davis

@mifronte:

I upgraded via the web GUI dashboard and also received the update failed message in my browser. However, the router rebooted itself before I can get to the console and came up with the new update and all seems fine.

Note for readers: This is the "normal" behavior. The webGUI code that "monitors" how the upgrade is progressing (showing the log messages coming out…) is a bit too stupid and sometimes gets the idea that something in the upgrade output indicates that the upgrade has failed. But actually the upgrade process is happily detached and running in the background. Eventually the upgrade finishes its processing and kicks off a reboot.

So don't be in a panic when that happens - make yourself a cup of coffee, get a command line somewhere and run "top" to see that some interesting looking things are running, be happy when it reboots.

And yes, the webGUI needs to be made smarter at "guessing" if the upgrade failed.

AWeidner

@phil.davis:

Note for readers: This is the "normal" behavior. The webGUI code that "monitors" how the upgrade is progressing (showing the log messages coming out…) is a bit too stupid and sometimes gets the idea that something in the upgrade output indicates that the upgrade has failed. But actually the upgrade process is happily detached and running in the background. Eventually the upgrade finishes its processing and kicks off a reboot.

So don't be in a panic when that happens - make yourself a cup of coffee, get a command line somewhere and run "top" to see that some interesting looking things are running, be happy when it reboots.

And yes, the webGUI needs to be made smarter at "guessing" if the upgrade failed.

Uhm, that seems not always to be the case. Mine sat for three hours at step 6 of 7 (see my post #7), top showed nothing interesting and i rebooted after getting impatient. Also several users from the site where the updated pfSense box is installed, complained about "not having internet", due to squid being stopped during the unfinished update process.

kpa

The issue seems to be that the update/upgrade process is launched asynchronously from the GUI and the only monitoring the GUI does is the update log by parsing it in an ad-hoc manner and it doesn't pay any attention the status codes returned by the various sub-operations of the update/upgrade.

AWeidner

@kpa:

The issue seems to be that the update/upgrade process is launched asynchronously from the GUI and the only monitoring the GUI does is the update log by parsing it in an ad-hoc manner and it doesn't pay any attention the status codes returned by the various sub-operations of the update/upgrade.

Then maybe there should be an advice, at least for this update, to only use the console based updater until the issue is resolved ???
(no criticism, just asking).