Thanks I will try that.

And thank you for all your help. It's greatly appreciated.

Ha.  ;D
5.5.22 in 2.2.1:
https://doc.pfsense.org/index.php/2.2.1_New_Features_and_Changes#Misc_Binary.2FOS_Changes

You don't have to tell us of course. However it's hard to offer advise if you can't give us some idea.

Steve

/var/run should normally have almost nothing in it. Mostly the pid files of running processes. Either you have something odd going on, like thousands of processes or there's some calculation error happening.
Either way installing 2.2.1 directly and restoring your config is the quickest way past this.

Steve

I did a rolback to 5.5, and everything worked greate. Think I will wait for som ner updates, or test it on a different server before upgrading again.

You shouldn't need to do anything at that point it should auto-boot the F1 option after a few seconds. The fact that it isn't implies it's stuck there at the boot loader prompt for some reason. The most likely cause is that you have some unusual drive controller. I couldn't find anything about that board but if it has any sort of raid controller you should turn that off. Also try chaning the SATA mode. See:
https://doc.pfsense.org/index.php/Installation_Troubleshooting#Boot_from_hard_drive_after_CD_installation_fails

Steve

hi renatohpc

As Escorpiom said, the CD go bad quickly.

I was wondering if the USB PEN installation could be a workaround in your scenario case.

I looked up onto the MOBO web site and the MANUAL have NOT a word about the USB in the BOOT PRIORITY section.

That let me believe that is not supported. But a Try cost you nthing else than time.

But what the read of the manual have poped up is that fact that the MOBO is NOT 64 bit compliant and since you picked up a x86_64 image to install it could lead to further problems…

Have fun.

I think I may have figured this out, even though I never managed to collect a proper crash dump.  After reading through the responses to my posts I checked in the bios and found that on the HP T5740 / T5745 thin client there is no way to disable hyperthreading (HT) in the bios.  I did a bit of research and found a sysctl toggle for hyperthreading.

By adding:

machdep.hyperthreading_allowed=0

to /boot/loader.local.conf I was able to disable hyperthreading.

This seems to have quelled the random crashes on my N280 Atom cpu when running i386 nanobsd in conjunction with ipsec.

Big thanks to all those who chimed in, and especially robi, who put me on to exploring hyperthreading.  I hope that this info helps someone else as well.  If I run into any more problems I will update this thread.

UPDATE
After some further reading about IPSec crashes on i386, I came across a thread here indicating that a different sysctl toggle may alleviate the problem in a more finely targeted manner than shutting off hyperthreading.

I have now remove the HT tweak discussed above, and I'm testing to see if setting:
net.inet.ipsec.directdispatch=0
fixes the issue.

Here is the thread and relevant post: https://forum.pfsense.org/index.php?topic=88606.msg501050#msg501050

Cheers,
Bennett

https://forum.pfsense.org/index.php?topic=90830.msg502489#msg502489

Hey @all,

I had the same probleme.
Solution: In PuTTy-Option "Serial" set "Flow Control" to "None" instead of the standard option "XON/XOFF"

Hope someone could use this :-)

That removed the notice not to change anything from the GUI.  Hopefully I didn't just turn off the Check Engine light without filling up the oil first.

Two services aren't running. One wasn't running before the update but as I never use it, I didn't care (Darkstat Bandwidth Monitor, which always seems to stop working anyway).  The second is Secure Shell Daemon which I've not noticed before.  If I start the service it stops immediately.  As I'm not connected via SSH at the moment perhaps it's not needed currently?

I was having the same difficulty on a RCC-VE 2440.

I solved it by booting my box with a memstick in liveCD mode, dropping to a shell and running:

tunefs -t enable /dev/ada0s1a
reboot

YMMV

None.

I specifically tried some regular Kingston CF cards which had DMA errors on that motherboard. I moved to Apacer Industrials, and problems gone.
Note also, that it also happened the other was around with some other motherboards too, pfSense would not boot from Apacer Industrial CF cards, but works just fine with regular Kingston and other chinese no-name brand CF cards.

Also noticed that when used with passive CF-IDE adapters with Windows, Apacer Industrials are detected a fixed disks (like regular PATA hard disks), while Kingstons and friends were detected as removable disks. Perhaps that's the difference between them, in the CF card's firmware.

There are at least thee different things, and different types of logs, that you may be talking about.  Can't tell without more info.

Bandwidthd data files (*.cdf) are stored in /usr/pbi/bandwidthd-amd64/local/bandwidthd. (Adjust if needed for i386).  To move those, I first would install bandwidthd on the new server, then copy the old *cdf files as well as the old etc/bandwidthd.conf to the new system.  Files in htdocs should be created as needed.

System log files are binary in a 'circular log'  format, and live in /var/log.  In a console you can generate plain text by using the clog utility, ie "clog /var/log/system.log |less".  No sense, IMHO, in copying these to a new system.

The rrd data files are used to create the rrd graphs you may be referring to, and these live in /var/log/db.  I'm pretty sure there are ways to back up the rrd data, and I think they are moved automatically when upgrading a system, but I'm not sure of the correct way to move old data to a new install with a potentially different configuration.  They are binary, so if you are going i386 to amd64, they are not compatible.  There are ways around that, but require some manual intervention, essentially a dump & restore.  Maybe somebody can chime in with proper way to move rrd data.

See comment #34

The ‘free’ AMIs are gone. We dropped the price on the remaining AMIs.
By paying for the AMI, you help support the project.

@hec:

Last time i tried carp with vmware we had a lot of packetloss and a the vips did not work.

You have a config issue at the ESX level somewhere in that case. Those possibilities are all outlined here:
https://doc.pfsense.org/index.php/CARP_Configuration_Troubleshooting#Hypervisor_users_.28Especially_VMware_ESX.2FESXi.29

If all you want is a proxy style VPN then pfSense just needs one NIC, the WAN, and a VPN set up to tunnel all client traffic and NAT it out of the WAN interface.

However I would recommend having a LAN interface so you can manage pfSense without allowing WAN traffic to reach the web GUI.

https://doc.pfsense.org/index.php/Upgrade_Guide#Disk_Driver_Changes