Worked like a charm. Thanks all.

3 cable and 3 different machines (2 Linux and 1 windows). No luck on any of them. If I'm lucky enough to have the device detected as /dev/ttyUSB0 I still cannot connect. I get input/output errors from minicom. Putty and screen just do nothing. I have made sure to  run those as sudo or to do a chmod -R 777 /dev/ttyUSB0. This has worked before as recent as a couple weeks ago. The only change was the attempt at updating.

About the only thing that makes sense based on what you have said is your eMMC is failing. The fastest thing to try is installing an mSATA and trying again.

Long delays on boot are almost always caused by a DNS resolver/forwarder misconfiguration. A lot of the services that are started on boot really need a fully working network connection with working DNS.

To change the filesystem to ZFS which supposedly fixes a problem with pfBlocker dnsblocklist statistics tracking which causes everything related to php to hang, a complete re-installation of pfSense would be required.

Thank you PiBa, that worked. I installed it and rebooted, the error went away. I un-installed it and rebooted and error is still gone. Thank you again

Ok, did the upgrade this time and that took a few minutes, but at least I know everything is up to date. I was a little concerned since I have been doing 2.4.0.RC updates for about a year. All looks good now. Thanks

Thanks, while I did not see which process exhausted the memory, the fix an bz in that post you mention appear pretty specific so its probably safe to assume that was the issue.

Ram disks are always UFS on pfSense/FreeBSD. Technically you could use another filesystem for them but nobody does that because UFS is the standard filesystem of FreeBSD.

@jimp: @Music: yes that works fine i also did that. But i have a few custom files for my DNS resolver. So when reinstall and then do the config i still need to copy certain files to the correct directory otherwise Unbound etc will not start. Then you can utilize the "Backup" package to easily get an archive of those files to restore later. Also if you put use a glob to specify your files in the advanced options of the resolver (e.g. "custom*.conf") then unbound won't fail if it can't find the files. Or you could get even trickier and use the System Patches package to store them in config.xml create them for you, but that's not quite so easy to maintain. ok thank you will look into that

Thanks!

If either one of your WANs is PPP, then default gateway switching can fail in this way. It's a known issue we've tried fixes for over the years but always ended up backing them out because something else failed. You must have a default gateway, however. It's possible that in the past the PPP gateway was becoming default even when it wasn't set to be.

Ooops, I found the problem…. I have used the wrong VM. I had updated my Pfsense to x64, but misnamed the VM... :( Now uing the correct x64 vm and the update worked. Thnx for the tips!

Finally it was a good opportunity to move pfSense on VMware and of course it worked just fine while I have now one more NUC for my cluster. Moving next: clone it and use CARP for redundancy.  :)

I enabled power daemon and set it between all the modes, the fan slows down a little depending on the selected mode, but usage remains the same for the acpi task. I updated the bios to see if it made a difference as well, but no change. I’ve chalked it up to something with acpi and this version of the kernel in FreeBSD that’s beyond my ability to figure out and rolled back to 2.3.4. Thanks for the suggestion.

Just wanted to finalize this thread and say that this worked perfect even without manual editing of the file. I'm amazed at just how easy it is to work pfSense especially going from different devices and even different versions. The only, ONLY issue I had was that I had to change the temperature probe setting from AMD to Intel. Thanks again, Adam

The file doesn't necessarily have to exist by default. In some cases it's unnecessary so it's empty. Just create a new file /boot/loader.conf.local and put your custom settings there if you need them.

Ugh, total fail on my part for lack of being thorough. Thanks, working as expected…