@jailbreaker: added the next 3 lines hw.ata.atapi_dma="1" hw.ata.ata_dma="1" hw.ata.wc="1" This has no effect on 2.2.x, read the wiki for proper hints.

Ah, I didn't know BIND was a package now.  Got rid of that tiny-dns thing and installed BIND.  Looking good and I actually have the features I wanted.  :D Still no go on the arpwatch front, but whatevs.  I will deal with it.  Thanks for all the help!

So I figured out a hilarious workaround for this and I'll post it here so maybe I can help a brotha out… I downloaded VirtualBox on my Mac and installed pfsense to a qcow image and immediately powered it off. Then I copied the qcow image to my host, converted it to qcow2, then re-ran my virt install command. It boots now :)

Kool…...seems to be the best method of upgrade. That way "little surprises" don't bite ya on the can. Going to order a new CF card here to use for "Upgrades"....burn the new one, restore the config.xml file. The autoupdate is a .........well...........rough around the edges. Glad it worked.

@cmb: Shouldn't be a problem in that case. I guessed Hyper-V since it's weird about reporting its interface speeds. Only way I can think of that happening on a C2758 is if you configured the shaper for > 100 Mb on an interface that's running at 100 Mb. Is that possibly the case? The upgrade wouldn't have changed anything there, it was just pre-reboot you were still running a previous ruleset that loaded without errors, which was gone post-reboot. All the interfaces are running at 1Gb & I'm pretty sure the highest I had specified in the shaper was 300Mb. One LAN interface that was in the shaper is unplugged. Maybe that did it? I had specified the minimum bandwidth I wanted available to VoIP on that interface for when I start using it.

The only major issue with  ver 2.2.2  was a  (very) slow reboot issue connected to serial port assignments (or lack of them). It was resolved by 2015-05-17 21:30 with a re-release of the upgrade files including the necessary fix, see:https://forum.pfsense.org/index.php?topic=92408.msg512890#msg512890. Short and sweet - all clear now  ;)

here maybe this helps.  So you see I have 4 physical nics in my esxi host.  Each is connected to different vswitch.  Pfsense has a virtual nic and connection to each vswitch. The wan physical interface goes direct to my cable modem.  The other physical nics connect to my switch and then on different vlans, etc. But they could be different switches completely if you wanted full physical separation of your networks. pfsense does not have a leg in vmkern switch because this is just for management of esxi host.  this is connected to same network as lan, I noticed a huge performance increase when moving files to and from the datastore when vmkern did not share the same physical nic as your lan network, etc. wlan has an AP plugged into the switch, and my unifi controller vm is connected to that vswitch. dmz is just a vswitch with not real physical connection to the real world network.  And then my lan is the normal where most of the vms sit. [image: esxinetwork.png] [image: esxinetwork.png_thumb]

hi charliex this is a surprise for me because i thought this problem appears only on the igel thin client.maybe because of the via padlock. but if you have the same problem on a different hardware it seems not related to the igel. i am with networks clueless so i have no idea whats the trouble. but it worked fine on 2.1.5 and after the update it didnt work anymore whitout me changing anything so i think its a bug in the software. i think will open a bug report. best regards steve

I had the same error as the OP after upgrading from 2.2.1 to 2.2.2 and the above commit does indeed correct the issue. Thanks Phil!

An enhancement could be for an automatic reboot after 1 hour to the previous slice if the upgraded slice is not confirmed as being successful from either the GUI or a CLI prompt. This would be very useful to anyone supporting remote systems as downtime would be limited to 1 hour following a failed upgrade. That would be a nice thing, but would only work if the OS on the new slice is actually bootable. I guess that could still catch some application issues, e.g. if the system booted OK but some firewall rules startup/VPN links/road warrior VPN server… did not come up. If it got some issue booting then any process that monitored things checking to see if success is confirmed by someone/something, would not be running. I can think of 2 cases like this that have happened to me - some dev snapshots that were missing a kernel, and hardware that worked with FreeBSD 8.3 + pfSense 2.1.n but did not boot FreeBSD 10.1 + pfSense 2.2.n - in both these cases the system was sitting at a console boot prompt of some sort and unable to proceed. I always have at home or at my local office an example of every hardware combination that is installed somewhere remotely. Then I can do local upgrades first and know that all my hardware combinations are at least bootable.

Jim, I read what you wrote in the upgrade guide.  There is no mention in what you wrote WHY one would want to add the tunable to their firewall configuration.  What specific symptoms would lead you to needing this tunable? With respect to the open mesh access points, the traffic doesn't need to be handled by the firewall at all.  The main issue was messages filling up the system log, making it basically unusable.  Windows NLB is another animal altogether. Also, my question of the security ramifications of adding this tunable, thereby reverting the kernel back to its previous behavior, has yet to be answered.  Just for the sake of completeness, I think we should have a discussion of how this impacts security.  Was the behavior changed from FreeBSD 8 to FreeBSD 10 just for the sake of being RFC 1812 compliant, or is there a good sense security reason for the change? Is there a possibility that logging this kernel message could be suppressed (in a future version of pfSense), instead of enabling a behavior that violates the RFC? Thanks for all you guys do, Anthony

That Supermicro system looks a lot like the FW-525B which will not boot FreeBSD 10.1 and thus does not work with pfSense 2.2.n The FW-525B is based on: Hardware: Intel PineTrail D CPU - ICH8M Express Chipset Motherboard Jetway FW-525B With CFCard! versus a And the Supermicro A1SRM-LN5F-2358-O is based on Intel Atom processor C2358, SoC (Rangeley), 7W 2-Core, 1.7-2.0GHz 5x GbE LAN including 4 ports pair LAN bypass (SW programmable) ports with SoC I354 and I210-AT Without CFCard! It is a Rangeley 2 Core SoC platform or the little brother of the C2558 and 2758 SoC.

@xbipin: @dotdash: New versions default to 115200 on the serial console i doubt the default speed in freebsd is 115200, atleast it doesnt seem so on my alix https://doc.pfsense.org/index.php/2.2_New_Features_and_Changes#OS_Changes

This arena of 'package testing' is, for example, why newcomer Linux Mint has come from nowhere to lead all the others in new installs.  They review every package upgrade, and in their package manger rate them in order of 'disruption danger' from 1 to 5.  It won't even list upgrades from packages level 4 and 5, other than security related. These are the sort of touches that make the difference between a lab project and a long term mission critical one.  It would be one thing if PF architecture left every package alone other than its core so the user could decide when to upgrade known working packages or not.  But PF architecture doesn't work that way.  It's all or nothing. The only way forward I can see is for the PF upgrade notice system to say 'upgrade available' with no qualification only when the particular packages each install is using have a flag somewhere qualifying they don't have material regressions (only new features buggy / broken).  Who sets does the testing and how that flag is set I don't know. I suppose the 'upgrade available, some packages untested' should pop up when there is an upgrade of the usual sort–- for those who want to take a ride on the wild side, or who think of PF as a learning tool or lab project. I'd bet there is a paid subscription business out there for someone to offer an add-on that requires a subscription fee, but will delay the upgrade process until regression testing they do has completed. But for

https://firmware.netgate.com/auto-update/ADI/amd64/