Thanks cmb. I installed from CD to the system with the HDD installed and kept all H/W the same post-install.

Helo Jamerson, I've been in a similar boat trying to install pfSense on my MSI AM1I motherboard, an AMD based mini ITX board with a rather spartan bios.  The USB installer boot would crash out leaving me unable to install it.  Although I turned off the 'Windows 8/8.1 secure boot' and set it to boot from 'Legacy and UEFI', it defaulted to UEFI no matter.  After thinking about it for a few minutes, i switched the sata port setting from AHCI to IDE, thinking it would force legacy over UEFI.  I was then able to boot the USB (I have no idea how a sata setting affected USB but it did) and install it to the local drive.  Once it installed, I installed needed packages and restored my old pfSense settings, then went back into the bios and set the sata port back to AHCI.  I had nothing to lose at that point in trying, other than some time.  So far, so good, I've rebooted maybe 5 times and have had no issues with pfSense loading or with any services starting.  So I am just throwing out that idea as a possible way to force legacy boot.  You might also want to check if there is any kind of legacy setting in the BIOS for USB as well, and try them.  Good luck.

@yodabug: LOL–I see this has devolved into a discussion about the posters understanding of networks and the network stack.. That wasn't a discussion, just a explanation how the ISP works here in Belgium @yodabug: BUT, since the community here at PFsense seems to be of the  "holier than thou you must be an idiot" crowd I will take myself on over to the Zentyal crowd and just re-install next years developer version. I mean you should see the support people are getting in the community user forums at Zentyal–true open source atmosphere. This is a forum for getting help for free, so you don't have to be rude because you run a little bit frustrated because pfSense doesn't work at the first time. And if you don't like the support here, go ahead and go to Zentyal if you feel better there. And last, we do not pretend to be holier, but who started with the first sentence "i have 25 years of experience…." ? Not we, but you, so if like to be a smartass and can't appreciate the help people are giving to you, then figured it out for yourself !!!

For future reference, I had this same problem on an old laptop. Using "hint.agp.1.disabled=1" rather than "hint.agp.0.disabled=1" fixed the problem.

Given the fact that you had to run that command, you should enable "Use non-local gateway" option at "System > Routing > Gateways > (Default Gateway) > Edit > Advanced".

Both Windows and FreeBSD clients were missing the usual V6 DNS server addresses. With Comcast the V6 delegated prefix changes with every pfSense reboot. I'm requesting a 60 bit prefix. The delegated ranges below are correct given that the masked (xxxx) parts are the same value for both interfaces. LAN (lan)      -> re2        -> v4: 192.168.1.1/24                                   v6/t6: 2601:cf:xxxx:19b0:230:18ff:fec8:fdb/64 DMZ (opt1)      -> re3        -> v4: 192.168.2.1/24                                   v6/t6: 2601:cf:xxxx:19b1:230:18ff:fec8:fdc/64 I think I have found the problem, and a partial solution. On the Resolver (unbound) config page, there is a drop-down that allows you to specify network interfaces. Out of paranoia I've always selected only the LAN and DMZ interfaces there, leaving out the WAN interface. I'm guessing that most leave this setting at the default ALL setting. On a whim, since I was having V6 DNS resolution issues, I replaced the setting with ALL. Lo and behold all started operating as expected!!! Reverted to the more selective setting, with the following /var/unbound/unbound.conf generated. Interface IP(s) to bind to interface: 73.184.240.250  <<=== What is this doing here. It is the WAN side V4 address which is NOT selected! interface: 2001:558:6011:93:3ce8:f1d4:efe4:5540 <<=== Same here for V6! interface: 192.168.1.1 interface: 2601:cf:8101:b550:230:18ff:fec8:fdb interface: 192.168.2.1  interface: 2601:cf:8101:b551:230:18ff:fec8:fdc interface: fe80::230:18ff:fecb:11a3%re1 interface: fe80::1:1%re2 interface: fe80::1:1%re3 interface: 127.0.0.1 interface: ::1 Unbound restarted, I ran the V6 tests, again all is well!!! Rebooted… No more V6 DNS resolution!!! Over to the service status page. The unbound DNS resolver is stopped! Manually start the resolver and V6 DNS support is restored. So the question is: Why does unbound fail at reboot if specific interfaces are configured for unbound. No error logs in the unbound logs. This in the system log: rc.bootup: The command '/usr/local/sbin/unbound -c /var/unbound/unbound.conf' returned exit code '1', the output was '[1468603936] unbound[35432:0] error: can't bind socket: Can't assign requested address for fe80::230:18ff:fec8:fdb [1468603936] unbound[35432:0] fatal error: could not open ports' OK, deleted the V6 link local interfaces from the selected unbound interfaces, rebooted, and all is well. Sooo… Should link local interfaces actually be considered as V6 DNS query interface candidates or not. If so, why do they cause unbound to fail on reboot. If not, should they be presented as interface candidates in the unbound interface selection drop down?

Thank you Chris, tomorrow i install latest 2.3.2 build with fix.  :) EDIT: test with 2.3.2 snapshot 20160715.0559. Works. :)

Just a bump to express my dissapointment from an unsatisfied customer… During an internet outtage the other day I took the opportunity to do an upgrade on our pfsense box, only to discover a day or so later I was no longer receiving my emailed daily reports which contain traffic graphs for all my network segments.  Various searching led me to here. This is really a bummer.  This was one of the main reasons I moved to pfsense from another firewall appliance.  I do recognize this functionality was never built in to pfsense to begin with, and was only available by the use of a 3rd party "plug-in" essentially.  However, daily emailed reports with information graphs is pretty much standard fare these days, even on some lowly consumer routers. Please consider adding this feature in future releases. Thank you. -Alan

Mine work without a hitch!  :-)

There is generally no need to do incremental upgrades. Actually you are even better off not doing any incremental upgrades. A few little issues in the upgrade code have been fixed over time, so the very latest upgrade code is the best. If you move to 64-bit, then just restore your 2.1.5 config, it will reboot and apply all the upgrade steps right up to 2.3.* 2.3.2 will be out very soon, so you might even wait until then, just to save you upgrading again soon after you get to 2.3.1_5

@oletuv: Is the code in /boot/loader.conf.local loaded in addition to or instead of /boot/loader.conf? In addition.

Updating from console fails as well!!! [image: putty.png] [image: putty.png_thumb]

Yes, realize it should be able to boot from USB too.  Unclear why OP wants to go through the additional efforts though.  Unless there is something limiting their ability to point VM at ISO. Update: Oh wait, think I get it now.  The light just turned on. They are just trying it on the VM, but the final target is a physical machine.  duh.

You're missing files that are a key core part of the system. Seems likely your CF is flaky.