Great... I was meaning to play with this but have been side tracked all weekend.

I was on 2.3 something when I did this

Well, it would be good to know which exact version you have installed and what version the upgrade has.
If you did a new install anyways, why didnt you download an actual version first and install that?

Nope it's probably this:
https://www.netgate.com/docs/pfsense/hardware/boot-troubleshooting.html?highlight=boot#pfsense-2-2-and-later

The CF card slot in those boxes does not have the DMA pins connected, it can only do PIO mode. But if you use a UDMA capable CF card (most decent sized cards are) the OS will still see that and try to use it. Hence DMA errors.

Steve

Whatever the proxy is for or is doing is probably messing up DNS resolution for your pfSense. The package management system needs a completely clean DNS resolution to operate properly, namely there can not be any filtering or tampering with SRV records, the pkg package manager uses those all the time for finding suitable mirrors for the packages.

Either that or the proxy is doing something to the http(s) downloads of the package catalogs to mess up the update system.

In my case this was linked to my previous post - https://forum.netgate.com/topic/131667/upgrade-2-3-5-to-2-4-3-crash-report/55 ... crash report - which @jimp tried to help me sort out.
I eventually had to load a new image and restore my config.

Colin

If you are installing a patch that is included in the next version (as is the case for both of these and 2.4.4) simply don't check the Auto Apply checkbox. After the update you will have the option to apply the patch again (which should not be able to be applied cleanly and fail anyway) or delete the patch.

This worked perfectly!!!

Are you still seeing this or was it a random occurrence?

Steve

It's an APU2 so was never sold by Netgate.

If you can't send any keystrokes that could be a bad serial cable or it could be a bad terminal setup. Particularly we have seen that with Mac clients using a USB/serial converter.

Steve

Added to that :
When you install a pfSense, why not using the latest version of a branch right away ?
On the other hand, it's good to see how it update/upgrade itself, this is actually a pretty straight forward process.
When it starts to complain it can not update itself, handle your box identical as a Windows PC with the same issue : ditch is really fast. Btw : I presume that you did set up WAN correctly, and you didn't break DNS capabilities.

If you have real "64 bit capable hardware" and you can't install a recent 2.4.x pfSense version because of a FreeBSD 11 kernel versus hardware conflict, you only have one option is : use the BIOS and shut things down (or ripe out the hardware that FreeBSD doesn't like).
Running a 2.3.5 is a dead-end solution, and can only be considered as temporary..

@stephenw10 Yeah the console solved the problem.

In changing the LAN IP range in the UI it cahnges the interface but not the DHCP server config. Console was only solution.

Thanks!

@m0rphius FWIW (every penny paid), I haven't had any issues w/ Realteks and pfSense, even w/ VM's (but Hyper-V).

@johnpoz said in Any urgency to upgrade from 2.4.3-RELEASE to 2.4.3-RELEASE-p1?:

There is also other changes and fixes in this release.. Not just security stuff.

You should always be current on your firewall software.. Not saying you have to pull the trigger 2 hours after it releases.. But makes zero sense to say.. .Ah, nothing there I need, Ah nothing in this one either.. Now your multiple versions behind and when something doesn't work you try and jump to latest and greatest, might have issue with that upgrade - did pfsense test every possible previous release with update to current, etc. etc..

Stuff like these fixes
Fixed a premature session timeout issue on pages which update exclusively using AJAX, such as status_graph.php

Fixed a missing global variable declaration in interface IP address detection

Packages that you might be using.. And update to a package might not work if using outdated version of pfsense, etc.

If you have change control to follow, or just haven't had a spare moment ok sure.. My NY office branch sg-2440 has not been updated to p1 as of yet. But its just a matter of scheduling the update for min disruption to the users there, etc.

I get where you are coming from, and I do my best to keep things current. My challenge is that updates are a balance between fixing existing issues/improvements and the risk of breaking something that is working well.

An upgrade can just as easily break an existing package and then I either have a mess to roll back or live with something broken till a fix gets issued.

Unless there is a compelling reason to update I like to wait about 2-3 weeks for anything non-urgent (I've seen many projects issue a p1 and then have to issue a p2 a few days later) so that if there are serious problems I won't have to deal with them (my FreeBSD skills are not great and I can't afford to have my firewall down for any significant amount of time).

Once I upgrade to a ZFS install I would hope that would solve the problem-If it's implemented correctly (like the FreeNAS projects has done), a botched update is gone with a simple zfs rollback.

@johnpoz I suspect it would head down the same road.

No worries, glad you're back up and running!

Did anyone have any other ideas? At this point, I just want to be able to access resources from one Ip on the 192.168.113.0/24 VLAN on the Cisco side to all the resources behind the PFSense box (10.10.10.0/24).

Thanks, will go check and if needed just order a new one :)