^ yeah is this script in clear text?  Sounds like bad idea to me ;)

There was an issue with the update .tgz files that should be corrected now. Forcing another update to the same firmware should be OK, or a wipe+reload is always a solid path to success.

Interesting. So it appears the ale(4) driver was causing problems for fragmented packets.
Thanks for posting that.

Steve

Thanks a lot for the hint Gertjan!

There is no 8GB nanoBSD image built. Install the 4GB image. It will use the first 4GB of the 8GB CF card. The last 4GB will be free. Who cares?

Dansguardian (becoming E2guardian) and Squid (as long as you do not want to cache) run on nanoBSD. If you are going to do Squid caching then you need a full install.

Some packages are not supported on nanoBSD - to see which are not supported you can look in https://github.com/pfsense/pfsense-packages/blob/master/pkg_config.10.xml - search for "noembedded" to find packages that do not install on nanoBSD.

Upgrades should go fine - the vr* interfaces are already in the config of the upgraded system. I have upgraded 10 Alix 2D13 to 2.2.2 all without trouble.
The change to factory default behavior is documented in just 1 line I can find:
https://doc.pfsense.org/index.php/2.2_New_Features_and_Changes

Change default NICs from vr to em – vr is on the way out and em is the most common NIC in use today.

A reader needs to already know a bit about pfSense and default interface assignment… to understand the ramifications of this 1-line statement  :)

Uhm… perhaps it would work better if you changed your PC's IP address as well to match the pfSense LAN subnet. Or perhaps enable DHCP? Or maybe just try again so that you can tell us what exactly you have done, since you apparently cannot even remember? Sigh...

@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.

esxinetwork.png
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!