Version 2.3.3_1 is available
-
Seems that it is on 10.3 p17 if you check via the console cmd.
So I'd assume the versioning on the GUI wasn't changed?
See attached.
-
Yeah, looks like you're right. I have P16 on GUI but console cmd check says P17. It's not a bug, it's a feature :o
-
Yeah, looks like you're right. I have P16 on GUI but console cmd check says P17. It's not a bug, it's a feature :o
Shows P17 in the GUI here. Likely another symptom of the "package manager needs a brain transplant".
-
Now, can someone tell me what's this?
Configuring IPsec VPN... Mar 10 18:23:40 ipsec_starter[42810]: Starting weakSwan 5.5.1 IPsec [starter]... Mar 10 18:23:40 ipsec_starter[42810]: no netkey IPsec stack detected Mar 10 18:23:40 ipsec_starter[42810]: no KLIPS IPsec stack detected Mar 10 18:23:40 ipsec_starter[42810]: no known IPsec stack detected, ignoring! done Mar 10 18:23:41 ipsec_starter[43518]: charon (43621) started after 280 ms
(IPsec does actually work, though seeing similar WTF in console output is not exactly what one would expect.)
-
If the GUI shows p16 something must be cached by your browser or maybe it never rebooted after the update.
The kernel version reported by uname wouldn't have anything to do with pkg, and should show the same anywhere.
@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
-
Had a successful update to 2.3.3_1 on my SG-4860, save one tiny glitch… reporting here for FYI purposes only, not a bitch.
all the ancillary packages packages restarted successfully this time too.My Dynamic DNS Status widget did show the cached IP not only as bad but had a : extension with an 8 digit port number.
Going into the service and punching "Save & Request Update" resolved even this small issue. -
===> 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.
-
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 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.
-
===> 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 modifiedNo idea what locked the kernel… will probably do updates through the console in future.
-
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…
-
WG x750e updated from WEB without any troubles.
-
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". -
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 -
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. -
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/6064Setting an appropriate search domain for the client will fix it in most cases.
-
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:~$ -
Then it doesn't match the domain on the firewall used/assumed for the hostnames. If it did, the short names would still resolve.
-
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?
-
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.