Thanks - I downloaded all of the 2.3.4…  in case the links disappear later. I know I should run out and buy 5 new boxes to get rid of the old hardware...  Let me check my pockets...  Lent!

At least that is the way with standard FreeBSD I can fairly report that it is working for me in pfSense version 2.3.x and 2.4.x too!

Awesome, thanks! Wasn't sure if there might be any incompatibilities or caveats importing a config from an older version of the nano distro into the current/full distro.

I cannot thank you enough Renato. I've been tearing my hair out for a few months with this issue before stumbling upon your suggestion here. Sure enough, /usr/local/share/pfSense/keys/pkg/revoked/.empty was there - and the moment it was removed, presto! All I wanted to do was install man :'(. This will be pinned prominently in my notebook! (Though all other systems I manage have been upgraded past 2.3.3!) Cheers, Sam. @Renato: It's exactly what I suspected. There is a bug in pkg that causes this crash. You can see details here: https://github.com/freebsd/pkg/pull/1586 We already fixed it in pfSense before submit the patch to upstream, and based on truss output we can see: The presence of the empty file /usr/local/share/pfSense/keys/pkg/revoked/.empty is the cause. I suspect there is a /usr/local/share/pfSense/keys/pkg/trusted/.empty file too. Just remove them and it will work as expected. As soon as you update pkg to latest version bug will be fixed.

@chudak: I have Sonic 1gb fiber.  @opalmer  it sounds it will/may affect me as well? Thx Answering my own query - I see no speed slowness on Sonic 1gb fiber on 2.4.1 release.

We fixed it.

I have 1 with a 32 bit install and that is exactly how it looks…

Perhaps you don't have interfaces available to add? Configure a vlan, or a openvpn server, and check the page again?

Yeah!  Recovered!    Thank you kindly.  I was banging my head against the wall because dropping into Single User mode mounts read-only, and even trying to run the /etc/rc.remount_rw script was failing.      Didn't realize I could cut out the boot process at any time using Ctrl-C. I'm back in business.

Current snapshots are OK here. Looks like somehow you are missing the pfSense PHP module, or it has failed to load.

Hello to all. I revert to this older post of mine, for an unclosed issue. Today, after a long bike trip in Corsica, I performed the update of my SG-1000 to 2.4.0 It worked. Before and after, I saved the entire configuration (not skipping packages nor RRD data). In System>Advanced>Firewall & NAT, Firewall Optimization Options is still on "Normal". From my earlier update to 2.4.0beta, I had received the following remark: (Filter Reload: There were error(s) loading the rules: /tmp/rules.debug:19: cannot define table bogonsv6: Cannot allocate memory - The line in question reads [19]: table <bogonsv6> persist file "/etc/bogonsv6" @ 2017-10-23 15:49:41) Can I now safely erase that remark and forget about it ? TIA.

try bouncing the LAN interface from the console (ifconfig if down; ifconfig if up) and then restarting php-fpm if you get a 502 error

OK, this issue is solved.  I looked further at the error, and needed to apply further debugging techniques. If disabling sdp would not work, go further back. So I disabled the FireWire driver adding this line to /boot/device.hints hint.fwohci.0.disabled="1" Rebooted and firewall came up fine with 2.4.0 kernel just fine.

Appears issue has been resolved in the RC for 2.4.1 so far if anyone runs into this.

I updated from the last version.. 2.3.x … okay, yes this is the reason, I use old keys.. thanks!

The only common filesystem between Linux and FreeBSD that might work realistically is ZFS but ZFS multi-OS multiboot is not for the faint of heart.

A bit of history:  Back in 1980 the IBM PC came with MSDOS on 160K floppies.  No room for TZ files.  So MSDOS set its time directly from the CMOS clock.  So generally you'd set that to local or "wall clock" time.  When folks started porting the UTC based *nix to the PC, provision was made to deal will wall clock CMOS time so as to be able to dual boot nicely.  For FreeBSD, the presence or absence of /etc/wall_cmos_clock was used to tell the kernel if the CMOS time was local or UTC.  See FreeBSD's adjkerntz(8).  Can't tell you how Linux does it, but presumably it has it's own method to coexist with DOS. Checking  my pFsense install ( fresh 2.3.x on an APU2) I don't see /etc/wall_cmos_clock, so presumably the pFsense default is to have the CMOS set to UTC.  But perhaps the OP put pFsense originally on a box with local time in cmos and does have that file. Now I haven't yet migrated my servers from FreeBSD 10 to 11, so don't know if FreeBSD made changes to the process.  But possibly it has changed and pFsense 2.4 picked that up, and maybe that config is confusing the NTP Widget.  Although why the NTP widget is looking at anything other than a NTP query and displaying UTC (NTP doesn't deal with local times at all) is beyond me.  But given OP's NTP peer status his system is probably running time correctly.  It would be worth looking at the system log after a boot to see if the "ntpdate" was jumping the time by 4 hours (assuming pFsense overrides the limiter).  That would be a good indication of confusion between what the kernel thinks is in the CMOS and what actually is.