Thanks very much @Gertjan.

I managed to save the file to USB, and to my delight the new installer also offered to pick this up and automatically restored my new 2.4 install.

@kpa:

If it's using UEFI you will notice from the console immediately because the console is in graphics mode as opposed to the old VGA text mode that the non-UEFI installation uses. The other thing you can check is to run this from the command prompt (over SSH or from the Diagnostics->Command Prompt menu):

$ gpart show =>      40  62533216  ada0  GPT  (30G)         40    409600    1  efi  (200M)     409640      1024    2  freebsd-boot  (512K)     410664      984        - free -  (492K)     411648  4194304    3  freebsd-swap  (2.0G)   4605952  57925632    4  freebsd-zfs  (28G)   62531584      1672        - free -  (836K)

The first partition is of type "efi" which gives away that this is an UEFI install, if it's missing you're on the older style of installation.

Also, you can tell from the BIOS set up program of your system right away if it's UEFI, it will tell it to you as just about the first thing, very hard to miss.

Yeah, I just checked. It's still using MBR so probably BIOS (not UEFI).

This turned out to be freebsd 11.0 issue with kvm. Switching my cpu to be emulated as opteron g3 was a workaround. Here are the bug details incase anyone else runs into the same issue.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213333

Thank you, guys!

sds,

I have changed it to "SMTP-Einstellungen testen". Should be correct in the next pfSense release.

@iso70x:

@kevindd992002:

@iso70x:

I have just had to restore a 2.3.4 config onto a fresh 2.4 system (upgrade to 2.4 via GUI failed, long story, file system got corrupted somehow).

Doing a fresh install of 2.4, then restoring the 2.3.4 config backup worked perfectly. All packages were installed automatically and everything seems fine. Entire system back up and running very quickly.

Restore was done via gui diagnostics menu after the system was up and running with default config btw.

For ref, this was done on a PCEngine APU1D4 via a serial cable.

I see. Did you reinstall it in UEFI mode?

No, standard bios I’m afraid. The APU uses the open source coreboot firmware which I believe is comparable to legacy bios.

I see. So we're not UEFI-compatible, bummer :(

With that formatting, just run the pkg info pfSense-base package.

You can get close with the contents of /etc/version and /etc/version.buildtime

In other words: You did something unsupported, and to the surprise of nobody, it broke.

Don't do that.

Worked like a charm. Thanks all.

3 cable and 3 different machines (2 Linux and 1 windows). No luck on any of them.

If I'm lucky enough to have the device detected as /dev/ttyUSB0 I still cannot connect. I get input/output errors from minicom. Putty and screen just do nothing. I have made sure to  run those as sudo or to do a chmod -R 777 /dev/ttyUSB0.

This has worked before as recent as a couple weeks ago. The only change was the attempt at updating.

About the only thing that makes sense based on what you have said is your eMMC is failing.

The fastest thing to try is installing an mSATA and trying again.

Long delays on boot are almost always caused by a DNS resolver/forwarder misconfiguration. A lot of the services that are started on boot really need a fully working network connection with working DNS.

To change the filesystem to ZFS which supposedly fixes a problem with pfBlocker dnsblocklist statistics tracking which causes everything related to php to hang, a complete re-installation of pfSense would be required.

Thank you PiBa, that worked.

I installed it and rebooted, the error went away.
I un-installed it and rebooted and error is still gone.

Thank you again

Ok, did the upgrade this time and that took a few minutes, but at least I know everything is up to date. I was a little concerned since I have been doing 2.4.0.RC updates for about a year. All looks good now. Thanks

Thanks, while I did not see which process exhausted the memory, the fix an bz in that post you mention appear pretty specific so its probably safe to assume that was the issue.

Ram disks are always UFS on pfSense/FreeBSD. Technically you could use another filesystem for them but nobody does that because UFS is the standard filesystem of FreeBSD.