@manicmoose said in Kernel Panic when Upgrading to 2.8.0 beta:

are using CE community as the guinea pigs.

@manicmoose Plus is has been more current than CE in recent years. So no the reverse has been the case which imo is a problem for the long term viability of a free CE version competing for plus clients without clear benefit for Netgate.

Not sure if this will help, I also had the same issue where after upgrading to 2.8.0 it would hang. Mine was hanging just after it detected the interfaces, right after you get the Y/N question of if you want to configure the VLANS. I wouldn't touch it, then it auto detects and then that's where I had it hang. I tried all of the above mentioned things, nothing worked. I erased the entire system and tried a fresh install of 2.8.0 and it hung in the exact same place again. After a few more changes and attempts in BIOS and install settings, I finally put everything back to the way it was before the upgrade and did one final install of 2.8.0 from scratch, this time I hit the Y when prompted to configure the VLANS and went through the set up of them. As soon as I did that, viola. The boot process continued on as the way it should. Not sure what is causing it to hang at the autodetect of the interfaces, but that seemed to fix it. Booted up right away, I restored my backup, and everything is working. Sorry for the long winded message. Hope this helps.

I would like to add I am having the same problem after upgrading from 2.7.2 to 2.8.0. The only packages that I had installed were Wireguard and the system patches. Packages were uninstalled then updated. As with the others, the message only shows up again after a reboot.

Running bare metal on a

Dell Wyze 5070 Extended

Intel(R) Pentium(R) Silver J5005 CPU @ 1.50GHz
Current: 1500 MHz, Max: 1501 MHz
4 CPUs : 1 package(s) x 4 core(s)
AES-NI CPU Crypto: Yes (active)
QAT Crypto: No

4 GB DDR4

250GB M.2 SATA used for pfSense
(Internal eMMC not used)

Intel I350-T2 Network card

Very basic configuration (no vlans) with no wireguard at the moment (Did not restore my configuration file yet).

Had no issues running 2.7.2

Yup I agree. Let me see about adding some debugging there.

Hmm, so it still failed at boot with outbound NAT set to automatic?

Thanks, @BBcan177.

Some clear confusion ITT re pfSense system version and pfBlockerNG package version numbers. For posterity:

pfSense 2.7.2 CE - Database Sanity check issue not present, because pfBlockerNG and pfBlockerNG-devel packages are both on "RELENG_2_7_2" branch of pfSense / FreeBSD-Ports

pfSense 2.8 CE - Database Sanity check regression, possibly because branch updated to "devel" for both packages?

(RELENG_2_7_2 branch: pfBlockerNG/pfBlockerNG-devel)
(devel branch: pfBlockerNG/pfBlockerNG-devel)

I think that's what's happened. Maybe someone can give me a sanity check. 😜

The package version numbers appear to have been realigned in pfSense 2.8 CE however. The last package versions of pfBlockerNG and pfBockerNG-devel on pfSense 2.7.2 CE were 3.2.8 and 3.2.0_20 respectively.

But under 2.8 CE, both packages are now currently on version 3.2.8 (pfBlockerNG and pfBlockerNG-devel).

Will both packages continue to be maintained separately and we should expect version numbers to potentially diverge again?

@AngryAnt said in pfSense -> pfSense NUT connection issues:

I had explicited the firewall allow rules to the NUT port only

Yes, that is appropriate. The allow example really should have had a destination port like so:

Screenshot 2025-06-03 at 10.56.00.png

@SpunkThing

That's right. There is no /boot/modules/if_re.ko without either of these packages being installed. It wouldn't print this message if you didn't have the driver I provided loaded, so indeed you're using the same driver as me.

@johnpoz hmm ok i thought i was done but maybe not.

I have a bunch of smart bulbs. ive gone through and renamed them [ Services -> DHCP Server -> LAN]

98966f2f-72e1-4ccc-bea6-85d2eddbdca9-image.png

but they still come through to pihole with their default names:

4f474660-139b-4a4b-ab80-cec37f44af2e-image.png

How do i get pihole to pickup (pfsense to broadcast?) the hostname/description ive assigned it?

EDIT: disregard, turns out it was a simple as giving it a few min to update

@johnpoz Yes we have them as static DHCP reservation on the router. But I removed them from that when we tried to fix this issue.
All the devices (WAPs and network switches) went to the IP of 192.168.1.20... every single one of them. (We could see that on the cloud key, so we still had cloud key access somehow, but basically the entire network went down and just stopped working). We can try set the cloudkey IP static on the device, ill look into doing that.

Im assuming the unifi devices talk to the router first to get their IP's, then talk to the cloudkey for other stuff, as you can run the equipment without the cloudkey.

We are setting up a test lab today so hopefully can figure it out.

Thanks again for your help and patience.

End of the story, linked to DHCP but not only, the LAN 2 VLAN interface was assigned with the IP address of my ngnix proxy (which was not the case previously), that created a lot of mess !!!

Once found, no more issues !

@jdeloach said in pfSense 2.8.0 full iso/img:

I was never able to upgrade to 2.7.x because of issues with FreeBSD that the BSD folks (all flavors) didn't want to continue to fix.

What issue was that?

@stephenw10 @gerdesj Thank you both for the information. I am now looking at posts from BBCan177 and there are indeed plenty. As for the link to the official documentation of the pfblocker package, I'm afraid that it isn't of much help, the information there is somewhat limited.

Thanks to all for the conversation, this was very useful!

👍

Changing over to python mode has significantly reduced cpu usage on my system from around 25% to less than 10%.

@SteveITS said in Netgate Configuration Export (6100 MAX):

Well hopefully you won't need to track down many changes made in 2012.

It's more of an emotional problem for me at this point. 🙄

@stephenw10 yea I only got 10G NICs. I tested on the host itself for today to get the setup right. Tomorrow I am going to test with my 2 Servers which are capable of doing 10G via SFP+

Well it's presented that way because the vast majority of users are either reinstalling Plus on an eligible device or installing CE on one that isn't. But I agree it could be clearer. I'll raise it.

I believe I've found the issue causing the weird behavior.

In looking at the MAC addresses captured, I can see that the "wrong" address is 02:42:0a:08:08:02

When using macvlan, the MAC always defaults to matching the specified IP address, but the incorrect address above doesn't.

So I then took a look at the lease table and saw this:

Screenshot 2025-06-01 at 11.13.53 AM.png

Hmm... That's not right. But it's the same wrong number. Looks like it's ignored in 2.7.2 and not ignored in 2.8.0

I made an edit to the reservation, put the correct 0A in there and... Look at that, MAC comes up to match in 2.8.0 and replies start working.

SonofA....

Now I can probably get going on the meat of this update (for me), migrating from ISC to KEA and the new if_pppoe.

@w0w
I used tail -f /var/log/system.log after restarting php-fpm

May 30 11:23:32 Obamium-fw rc.php-fpm_restart[87304]: >>> Restarting php-fpm May 30 11:23:32 Obamium-fw check_reload_status[88770]: check_reload_status is starting. May 30 11:26:47 Obamium-fw nginx: 2025/05/30 11:26:47 [error] 81351#100414: *675 upstream timed out (60: Operation timed out) while reading response header from upstream, client: 192.168.1.251, server: , request: "POST /widgets/widgets/interfaces.widget.php HTTP/2.0", upstream: "fastcgi://unix:/var/run/php-fpm.socket", host: "192.168.1.1", referrer: "https://192.168.1.1/" May 30 11:26:53 Obamium-fw nginx: 2025/05/30 11:26:53 [error] 81351#100414: *675 upstream timed out (60: Operation timed out) while reading response header from upstream, client: 192.168.1.251, server: , request: "GET / HTTP/2.0", upstream: "fastcgi://unix:/var/run/php-fpm.socket", host: "192.168.1.1", referrer: "https://192.168.1.1/status_logs.php" May 30 11:27:02 Obamium-fw nginx: 2025/05/30 11:27:02 [error] 81351#100414: *675 upstream timed out (60: Operation timed out) while reading response header from upstream, client: 192.168.1.251, server: , request: "POST /widgets/widgets/interfaces.widget.php HTTP/2.0", upstream: "fastcgi://unix:/var/run/php-fpm.socket", host: "192.168.1.1", referrer: "https://192.168.1.1/" May 30 11:27:18 Obamium-fw nginx: 2025/05/30 11:27:18 [error] 81351#100414: *675 upstream timed out (60: Operation timed out) while reading response header from upstream, client: 192.168.1.251, server: , request: "POST /widgets/widgets/interfaces.widget.php HTTP/2.0", upstream: "fastcgi://unix:/var/run/php-fpm.socket", host: "192.168.1.1", referrer: "https://192.168.1.1/" May 30 11:27:33 Obamium-fw nginx: 2025/05/30 11:27:33 [error] 81351#100414: *675 upstream timed out (60: Operation timed out) while reading response header from upstream, client: 192.168.1.251, server: , request: "POST /widgets/widgets/interfaces.widget.php HTTP/2.0", upstream: "fastcgi://unix:/var/run/php-fpm.socket", host: "192.168.1.1", referrer: "https://192.168.1.1/" May 30 11:27:49 Obamium-fw nginx: 2025/05/30 11:27:49 [error] 81351#100414: *675 upstream timed out (60: Operation timed out) while reading response header from upstream, client: 192.168.1.251, server: , request: "POST /widgets/widgets/interfaces.widget.php HTTP/2.0", upstream: "fastcgi://unix:/var/run/php-fpm.socket", host: "192.168.1.1", referrer: "https://192.168.1.1/" May 30 11:28:05 Obamium-fw nginx: 2025/05/30 11:28:05 [error] 81351#100414: *675 upstream timed out (60: Operation timed out) while reading response header from upstream, client: 192.168.1.251, server: , request: "POST /widgets/widgets/interfaces.widget.php HTTP/2.0", upstream: "fastcgi://unix:/var/run/php-fpm.socket", host: "192.168.1.1", referrer: "https://192.168.1.1/" May 30 11:28:20 Obamium-fw nginx: 2025/05/30 11:28:20 [error] 81351#100414: *675 upstream timed out (60: Operation timed out) while reading response header from upstream, client: 192.168.1.251, server: , request: "POST /widgets/widgets/interfaces.widget.php HTTP/2.0", upstream: "fastcgi://unix:/var/run/php-fpm.socket", host: "192.168.1.1", referrer: "https://192.168.1.1/" May 30 11:28:25 Obamium-fw nginx: 2025/05/30 11:28:25 [error] 81351#100414: *675 upstream timed out (60: Operation timed out) while reading response header from upstream, client: 192.168.1.251, server: , request: "POST /getstats.php HTTP/2.0", upstream: "fastcgi://unix:/var/run/php-fpm.socket", host: "192.168.1.1", referrer: "https://192.168.1.1/" May 30 11:28:30 Obamium-fw nginx: 2025/05/30 11:28:30 [error] 81351#100414: *675 upstream timed out (60: Operation timed out) while reading response header from upstream, client: 192.168.1.251, server: , request: "POST /getstats.php HTTP/2.0", upstream: "fastcgi://unix:/var/run/php-fpm.socket", host: "192.168.1.1", referrer: "https://192.168.1.1/" May 30 11:28:36 Obamium-fw nginx: 2025/05/30 11:28:36 [error] 81351#100414: *675 upstream timed out (60: Operation timed out) while reading response header from upstream, client: 192.168.1.251, server: , request: "POST /getstats.php HTTP/2.0", upstream: "fastcgi://unix:/var/run/php-fpm.socket", host: "192.168.1.1", referrer: "https://192.168.1.1/" May 30 11:28:36 Obamium-fw nginx: 2025/05/30 11:28:36 [error] 81351#100414: *675 upstream timed out (60: Operation timed out) while reading response header from upstream, client: 192.168.1.251, server: , request: "POST /widgets/widgets/interfaces.widget.php HTTP/2.0", upstream: "fastcgi://unix:/var/run/php-fpm.socket", host: "192.168.1.1", referrer: "https://192.168.1.1/"

Or do you mean another file?
And are there logs from php-fpm that I can maybe look at? If so, where can I find them?