@stephenw10 I will try again soon, had to reload the server with the previous version to get the internet working again

Currently in pfSense it does, yes. Because the firmware is not present, it tries and fails to load it and that hits the bug. It should not panic if it can't find the firmware. If the firmware was still in-kernel it might load normally. I can't test that. I couldn't get it to load the firmware as a kernel module.

Yup, OK. It's almost certainly the empty tags for opt3 in the dhcpd section there. Line 662 in the config: ... <opt3></opt3> ... If you remove that line Kea should start normally with early DNS registration enabled in 2.8.0.

That's a bios or efi function. It deppends how the BIOS presents it. If it boots pfSense you can use efibootmgr to set the boot order if you need to.

@DominikHoffmann If you're going to install a package, you might as well try the Filer package which can store the code and restore it to the correct location as part of the XML backup.

Same issue here from 24.11 to 25.11. Clearing /cf/conf/backup was the solution. Thanks for sharing !

Oh so you still see this even without pfSense involved at all? It must be a problem in the route then. Like something at your ISP routing packets via multiple routes perhaps. What happens if you route traffic over a VPN to somewhere else so you bypass anything the ISP is doing?

@stephenw10 Thank you for the remark with the power saving settings. This fits to the picture trhat the system allways was crashing at night when nothing happens. I ordered and installed a new internal SSD. Not it is running stable since 3 nights. I think it really have been some power states of the SSD or USB.

You can mount the BE by simply running: bectl mount <be_name>. It will show you a mount point in /tmp. Just be sure to bectl unmount it.

said in "Version 2.8.0 is available." but then "up to date": Ok, I enlarged the efi partition on both pfSense. Restarting the update on the secondary worked, now I'll run it on the primary. All updates have passed without errors, both pfSense are back to normal, data flow seems to be ok. Thx@all. Thread closed. cu.

Mmm, that's a painful read. Yes the 'out of space' error is almost always caused by many old snapshots taking up space but that's usually on eMMC boot devices where space is far more limited. It's possible some other drive issue is triggering it. Using a PPPoE WAN would not have any effect here. If you need to show or modify the Boot Environment from the CLI you should use the bectl command. I've never seen any problems using that. Unfortunately it looks like you may have accidentally removed some ZFS mountpoint snapshot from more BEs than intended. If you run just zfs list does it show available space for each mount point?

Hmm, what do you get after the reboot though? Just the BIOS output? How did you get to 25.07 in the end? There's a separate setting for denying DHCP to clients without a static mapping: Deny Unknown Clients

@stephenw10 Agreed all my subsequent research indicates this should not have been possible to configure! I created the tunnel and got a warning that existing binding would not work, can't rember exact words, I assumed just WAN which was fine for me. Tunnel worked and I still had GUI access to pfSense for several weeks. But, don't think I every restarted pfSense between then and upgrade to 25.07, so might have failed then.

Ah, nice catch. Hmm...

There shouldn't be anything special required there. You should be able to use any two drives in a ZFS mirror. I'd recommend using identical drives though if you can.

You have any output from the console where it fails? What device is this?