Hi, Update from 2.4 to 2.4.1 and I have same issue as user who started this topic.  

Thank you for the useful info. I believe I have now a device ready for a hot swap. What I've done was: downloaded pfSense-CE-2.3.4-RELEASE-4g-i386-nanobsd.img from https://atxfiles.pfsense.org/mirror/downloads/old/ written it to 4GB CF card using  http://sourceforge.net/projects/win32diskimager/ exported config from the old remote 2.0.1 device via web GUI renamed the file to config.xml and copied via USB stick to /cf/conf/ on the new 2.3.4 device restarted 2.3.4 and it appears to successfully embed the new config (viewed from serial console). That's probably as much as I can do before making a trip to the DC and swapping devices. Could somebody take a quick look at the boot log and point out any potential problems (if any)? I have replaced real DNS names and IP/MAC addresses with dummy ones but it shouldn't alter the original concept. Thanks Adam config-import-log.txt

The whole cpu doesn't need to max out to make things slow.  On my pfsense thru VPN for example, I can hit a wall by maxing out a single core out of 4.  It may only say 30% load, but it will be effectively maxed out.

Fixed in Development https://forum.pfsense.org/index.php?topic=138876.msg760659#msg760659

sure looks like all there to me https://atxfiles.pfsense.org/mirror/downloads/old/ Goes all the way back to 1.0.1 version.

it turns out that a clue I hadn't posted above lead to the solution. Along with my log data, I was getting a (at the end): clog: ERROR: could not write output (Bad address) I searched for that error and found another post 'clog' is used to view circular log files, but not all pfSense logs are circular. I looked for another way of outputting a log to the command line and found "head" head /var/log/suricata/suricata_bceXXXXXX/alerts.log worked.

Thanks, I figured this out last night.  it's simply a matter of predictive device naming. /joe

I'm not too familiar with NanoBSD but I just happened to be aware of how the partitioning works there. You'll have to hope that someone who knows more shares their knowledge here.

I have a similar need. I've recently reinstall to move my pfSense build on to ZFS. I have a single 128Gb M.2 drive so have plenty space and IOPS to spare. I don't want to add a second disk even though that would give the best level of redundancy as I don't have space inside the unit. I would like to enable copies=2 which is easy to do but I would like to apply this to my full installation rather than just newly create blocks. I was thinking of doing the following but I'm not sure if this is sensible. Boot with FreeBSD ISO version that matches my current pfSense install "FreeBSD 11.1-RELEASE-p2". The do the following 1. Drop to shell 2. import ZFS pool and mount 3. create new datasets with same name as existing with "-new" at the end and set copies=2 4. cp -ax <source-path><destination-path>5. zfs rename original datasets so that "-old" is appended 6. zfs rename new datasets so that "-new" is removed from name 7. check zpool bootfs is correctly point and new boot path change if needed. 8. unmount and export ZFS pool Would the above work?</destination-path></source-path>

@Gertjan Fantastic! Changing DIOCADDALTQ to DIOCXCOMMIT works! Cheers Thomas

Please don't spam everywhere and open bug reports for things that are not bugs. There appear to be missing images there. That is not a bug. It is the middle of the night here in the USA where these things are done. Thank you for the report.

It's not an issue at all. You just used a community image for the unit. Community image is identical to the factory one with exception of AWS Wizard, IPsec profile and a few device specific tuning parameters (all of those are available on our wiki). If you have a factory image downloaded, you can install it. If not, just stick with CE.

I should have specified that we are also moving to a new location so the two old firewalls will stay until we shut down that cabinet. So setting up the new firewalls will be in a new cabinet with new IPs and connections. By moving the config I was hoping to save some time. Setting up all IP address, rules, users, etc is a ton of work. I dont think you can use the 2.26 config on 2.4? The upgrade path specified by Netgate is 2.2x to 2.4, you need to do a stop at 2.3x first. Basically, I am trying to get a workable config.xml I can use. If I follow the update path to 2.4 and have a workable config, I can blow that out and reinstall 2.4.x then import the config. I appreciate you taking the time to write that long response, very kind of you.

How did you install pfSense for the first time?  :o

2.4.0, more specifically FreeBSD 11.1 - does not support drivers for Mellanox Connectx3, and Mellanox has no plans to provide upgraded drivers to support FreeBSD 11. If the new cards are available and running what is now the real problem? If it is urgent you could buy this cards and all will be fine for you and your company, or? So this are Infiniband adapters, and this is more or less well known and used for any kind of SAN or storage networks, for sure in some rarely cases this can be interesting for admins to get the hands on and together with their switches able to serve 40/56 GBit/s or 25/50 or 50/100 or 100/200 GBit/s it could be nice to get this working well or together with different OS. But perhaps also the money is rare and a driver not given, you could try out to install pfSense inside of a VM to get the benefits of that adapters and being able to use pfSense more then other distributions. Rather their support informed us that Connectx4 NICs ARE compatible with FreeBSD 11. For sure a generic kernel driver from them would be fixing many things, but for perhaps some rare interested users they don´t hire a driver coder I really think.

If it can run NanoBSD, it can probably run a full install. As long as it's 64-bit hardware and can boot from USB to run the installer. As for the /tmp and /var bit, if you look at System > Advanced on the Miscellaneous tab there you will find the option to place /tmp and /var in RAM disks. The vast majority of the writes on pfSense are in /tmp and /var to temporary volatile status files or logs, and placing those in RAM disks will prevent those writes from wearing out your drives.

By the way. I was forced into reinstalling because my installation broke when I restored a config I had created only minutes before. The backup config.xml included RRD data and after the restore I got a message saying some specific line from the RRD data wasn't allowed twice in the config. (Something like that, I don't remember exactly what the message was and I found no duplicated lines in the file anyway.) After this the WEB GUI was completely down and my pfSense was offline. Restarting the machine didn't help. There was no way left to restore another (older or repaired) config.xml. Login with ssh was possible but even other options in the console menu didn't work. Due to being offline I had no opportunity to ask the community how to resolve this. So I reinstalled the system using the most current version I had available locally which was a 2.4.0 BETA. Lessons learned: Prefer the config history feature to revert to previous settings over restoring a config file. Don't backup RRD data, feature is broken anyway. Run pfSense with zfs. Even with no redundancy (1 ssd in the system) this still provides snapshots on a system level in case restoring a config.xml doesn't work. Create snapshots regularly. Have an installation image available locally for the current and at least one previous pfSense version (even if the system got updated online).

@Qinn: (…) btw Maybe it doesn't matter, but I have noticed that after the upgrade to 2.4.1 the beep, when you login, is back (I remember disabling it). (...) https://doc.pfsense.org/index.php/Disable_Sounds/Beeps