Solution:
disable 'Monitor M-Wait' in bios
Could be under Features tab > CPU Configuration

@rod1011:

What happen after update does it reboot the system?

Of course.

If your secondary system doesn't have that syntax then your secondary is broken in some way. The configuration did not upgrade properly.

@jimp:

Try this:

pkg clean -ya pkg install -fy pear-Net_IPv6

Didn't help, a user on another forum had me try this.

However, what did work was SSHing in and selecting the upgrade option from the PfSense menu in the command line. It showed that 1 package needed reinstalling, and it upgraded, and was good to go after.

My bad - I had the ADI memstick inserted instead of the uFW recovery.

Recovery seems to be functioning

@luke1018:

Hi may I know how can we do testing (Implementing rules, new codes or configurations) on our local machine and once its ready, how can I duplicate it on the live machine?
Is there a way we can do backup and restore to the live system? or to patch it?

Strange.
The very basic concept of pfSense is that it stores all settings in one file - witch can be backup and restored, even on another machine (if identical network interface names, otherwise you have to setup your NIC's again).
Patching ? What do you mean ? You are aware of the fact that pfSense lives on github, which means sources are available ?

Look in Services -> Snort -> Alerts.

I've found its better to run snort on the internal interface as if you use it on the WAN it logs the WAN address not the client that is natted.

[2.4.2-RELEASE][root@ FQDN]/root: sysctl kern.geom.debugflags=0x10
kern.geom.debugflags: 0 -> 16

[2.4.2-RELEASE][root@FQDN]/root: gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ada0
gpart: /dev/ada0p1: Operation not permitted

Then I went rogue and tried my own:

[2.4.2-RELEASE][root@FQDN]/root: gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ada0p1
gpart: No such geom: ada0p1.

As you may see, I have no clue how disk geometry works. 😂 I'm very happy I didn't for more than a few minutes offline though, now I have time to schedule a reinstall. Whoever came up with backup & restores on pfSense is a f*cking genius! They way packages reinstall themselves and everything is back as before it just amazing. Thanks for your help!

There are a few different possible issues that could lead to your situation, but without more information it's impossible to say what is happening with any certainty.

First, go to the console or connect via ssh and run option 13 and see if it finds the upgrade that way. If not, capture the output and post it here so we can see what it says.

Accessing the GUI from WAN ? YES accessing GUI via WAN interface

What about using the console access ? YES SSH via WAN interface is also OK, btw my instance is a VM (ESXi 5.1.0)

What are your LAN setting ? I have few Sub interface under LAN (please see file Attachement…)

Are you aware what your screen shot is showing (just the basic pfSEnse startup scenario !) - nothing useful in fact - wrong image ?. Its the correct images.  this part when my LAN connection lost..

pfsense_interface.JPG
pfsense_interface.JPG_thumb
pfsense_LAN-interface.JPG
pfsense_LAN-interface.JPG_thumb

It'll be fine.

Just to be clear here the VK-T40E will run 2.4.X no problem. I have one here doing just that.

You cannot upgrade to it directly from a NanoBSD image as Nano was discontinued in 2.3.X as others have pointed out. You can install 2.4.2 fresh and restore your config into it though it should be a simple process.

You might choose to upgrade it to an mSATA SSD or do a full install to the SD card. If you do the latter be sure to install without a SWAP slice and to set /var and /tmp to RAM drives after first booting.

Steve

The system has been restarted several times. I was hoping not to have to do a clean install as the device is in a somewhat inconvenient location. I have seen the threads but many of them reference development versions of 2.4 and it wasn’t clear how much was applicable to my situation. Thanks for responding.

I think this also killed 2.4.1 dev to 2.4.2 upgrade path as well.

@veldthui:

….. and LAN as 192.168.0.25/24...../ /..... Then set the WAN IP to 192.168.0.14/24. It complained .....

Compare this situation as a crossroad with heavy traffic, and all traffic lights go green at the same time.

But, you're right. 2.4.2 won't work doing such things.

Just..  Wow. Thanks for the great f'n support.

Your safest bet is to reinstall. But I would test those drives, first. The upgrade wouldn't (and couldn't) touch the disk layout. Newer versions of FreeBSD are generally better at identifying and preventing disk problems from compounding themselves, so maybe there actually is some aspect of the label that is invalid.

I don't know if it will work for that particular error, but you can try setting this in /boot/loader.conf.local:

What errors does it show before dropping you to single user mode?

To make sure it isn't something stuck from nextboot, try running this once you have it up and running:

That's the same as an APU. It is capable of running 2.4 so long as it's running an amd64 full install (not NanoBSD).

The first thing to try is to run pfSense-upgrade from the console or ssh shell (not the GUI) and see what it says.