See https://forum.pfsense.org/index.php?topic=145990.0 I have it on 2.4.2-p1 too /Bingo

The elixir to every I.T. problem: REBOOT. :D

check duration: 1001ms Well your testbox took longer than 1 second to respond.. And did so 3 times in a row. So either the url its checking does a lot of processing and is already close to that 1 second regularly. Or perhaps the webapplication got restarted and needed to load its configuration from disk again or some memory garbage collection happening.. Just guessing here.. Anyhow there was a period of time that the webserver was unable to respond properly.. Making the health checks span more time than the default 1 second works to avoid the 'down' syslog message, it doesn't fix the underlying problem. Perhaps enable the "Log checks" on the backend, then it will log a bit more around when the state of the health is changing. And might tell how often one or two checks are failing..

Are you dedicating your TS140 to pfSense, or are you going to virtualize? Just asking because I have a TS140 with the i3-4130. If you plan on running something like ESXi so you can use your TS140 as a server and a router, you might want to upgrade the processor to a Xeon - the 4130 only has a total of 4 threads available. For my uses that just isn't enough oomph, so I upgraded to a E3-1275V3. Just something to consider if you will be doing more with your TS140 besides just routing packets.

You really ought to supply some more hardware details, but maybe I can read between the lines.  Seems you have an Atom based box of some sort and apparently have a monitor directly attached (or else you use the term console different ways in the same context).  The simple answer is, don't use the serial image. If the monitor is a temporary attachment to be replaced by an actual serial connection, then a few things.  It's not usual for boot sequences to start using all available outputs but eventually the serial image is going to switch to just the serial connection.  If your really are using a serial console and it's cutting out, then the most likely thing is the APU2 and pfSense have different serial speeds set and you'd have to reset you serial connection speed after it hits that point in the boot.  You'll need to look up what those are, but my vague recollection from setting up my APU2 a while ago is that they are not the same or I could be thinking of the net5501.  You can then change one or the other setting so they match and avoid that problem in the future.

Found it at the extreme bottom of the config file, thanks. Makes sense in retrospect as the vLANs configured in another section have a selection for their parent interface. I thought that was what I was configuring above all in one step but guess not. Edited it to this and it all came back up fine. <vlans><vlan><if>em0</if> <tag>10</tag> <vlanif>em0.10</vlanif></vlan> <vlan><if>em0</if> <tag>11</tag> <vlanif>em0.11</vlanif></vlan></vlans>

Thank you both. For the record, turning off gateway monitoring fixed the issued.

Well thank you for this thread so am not the only dummy who can't do this simple thing :) Got error on my Sandisk SSD ask well, and I gave up, not gonna buy another SSD, UFS and my UPS already does the job anyway, just thought if it's free, throw that in there right, but if it makes me jump through hoops, meh.

Thanks, I think I get that. Much appreciated.

Yup, I can see it's a matter of timing!  Anyway, very happy that you were able to give me a positive response to my query.  Now to find a reasonably priced 1U 8 port router!  eBay beckons… Thanks again.  :-)

Yes (to all of those)

ok, i figured it out.  Basically just formatted a flash drive fat32, copied the config.xml to /conf/config.xml and ran a fresh install.  It seems to have pulled the data from the .xml file into the new install automatically.  After the reboot i unplugged the flash drive and it booted up complete with the WAN, lan, VPN, etc configs intact.

An NMI error is almost certainly hardware (non-maskable interrupt, generally indicative of an unrecoverable hardware error), and those that are not hardware are due to some interaction with the BIOS, so still related to the hardware. It's possible you have some incompatibility with that hardware or BIOS and FreeBSD, or it could be a hardware failure.

Just going to put this out there: My network needed to be majorly redone in order to reduce complexity.  That is, remove VLANs, make configurations more 'sane', and condense networking down to one switch and many VLANs. Five hours later of beating my head on Cisco switch configs and Ubiquity wifi controllers and access points to get everything talking around the network properly, it works.  I'm now fully on a virtualized pfSense appliance.  I might fiddle around with upgrading the APU in-place, but that's a long time in the future.  My network now operates with the newly-configured pfSense VM. Thanks for your advice to point at the "redo it with a VM" solution, it actually is responding faster now than it did before.  (AND the VLAN trunks all work without issue!  :D)

Hi AndyC, That was the case, thanks!

Fairly new to the Linux world, seems to me lots of stuff are version 0.xx and suggest not fully stable, regardless there are only 2 choices for pFsense right, NUT or APCUPSD. Try them and see if they work for you. Am using APCUPSD and notice there are lots of parameters to configure and haven't had the patience to fine tune mine to make sure it works as expected as my power outs are rare and power usually comes back before battery runs out.  APCUPSD master-slave is relatively simple. the Master is configured just like a standalone. And the Slaves, instead of listening to a cable (serial/usb) are configured as NET and poll the Master at intervals for status.