@jimp is there not a QA/QC process where someone tests each package individually and confirms it is working? Supplementing this with automatic regression testing would be even better, but I don’t think it would be easy to fully replace the manual testing. Then there could be a list of packages which gradually get a green tick next to them as this testing is completed?

FYI - I installed pfSense 2.7 (build 12.18.22) on my Proxmox box and was able to upgrade to the latest build without issue. I also was able to upgrade pfSense 2.6 to 2.7 (latest build) without any issue. In both cases existing configurations were brought over just fine.

Actually that backtrace does appear to be the same as the one we see occasionally for IGMP Proxy: https://redmine.pfsense.org/issues/12079 I added your textdump there, but that won't be one we get to for the 23.01 release.

That should be fixed by the snapshot building now.

Looks like the locale files are there but aren't matched because we set the language to fr but the locale files need a location, for example fr_FR. https://redmine.pfsense.org/issues/13776

https://redmine.pfsense.org/issues/13752

I opened a Redmine issue for this, that OpenVPN interface code is problematic for sure, but there might be other things that need updated for PHP 8.1 as well. https://redmine.pfsense.org/issues/13775

I can confirm that I had this issue a couple of weeks ago, and that after updating to a newer snapshot today it is fixed.

Fix Applied in commit de0e99275b5275d1f5b2e477fcd0322aef5284c4

For reference: panic: vm_fault_lookup: fault on nofault entry, addr: 0xffffffff83cf7000 db:0:kdb.enter.default> bt Tracing pid 1 tid 100002 td 0xfffffe00098b2ac0 kdb_enter() at kdb_enter+0x32/frame 0xfffffe000859d920 vpanic() at vpanic+0x182/frame 0xfffffe000859d970 panic() at panic+0x43/frame 0xfffffe000859d9d0 vm_fault() at vm_fault+0x15da/frame 0xfffffe000859dae0 vm_fault_trap() at vm_fault_trap+0x71/frame 0xfffffe000859db20 trap_pfault() at trap_pfault+0x22d/frame 0xfffffe000859db80 calltrap() at calltrap+0x8/frame 0xfffffe000859db80 --- trap 0xc, rip = 0xffffffff83cf7fb0, rsp = 0xfffffe000859dc58, rbp = 0xfffffe000859ddb0 --- _end() at 0xffffffff83cf7fb0/frame 0xfffffe000859ddb0 sys_reboot() at sys_reboot+0x2d2/frame 0xfffffe000859de00 amd64_syscall() at amd64_syscall+0x12e/frame 0xfffffe000859df30 fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe000859df30 --- syscall (55, FreeBSD ELF64, sys_reboot), rip = 0x2739fa, rsp = 0x820a15be8, rbp = 0x820a16010 --- This system is an ESXi VM. Given the panic points to a memory issue, it's more likely to be an issue with the VM itself and not the upgrade. FWIW I have not run into this on ESXi 7.

@marcosm Again, Your indicating that there is a configuration problem. The same configuration that has worked for 5 years prior to version 2.70. Just because you look at logs and see packets going out the wrong gateway does not necessarily mean my configuration told them to do so.

I have raised the following issue: https://github.com/travisghansen/hass-pfsense/issues/123

@jimp FYI - I pulled the realteck card from my test machine and inserted an intel card so I have two em# cards em0 and em1 and upon install the message did not appear. Thanks again jimp.

@bmeeks Thank you Bill.

It's a known issue but hasn't been fixed yet: https://redmine.pfsense.org/issues/13660

Moin, I took some time, but today I'm on-site and gave the "NIC" disable thing a try. I added three lines in /boot/loader.conf before I upgraded the machine [2.7.0-DEVELOPMENT][root@boavista.emetriq.com]/root: grep ax /boot/loader.conf hint.ax.0.disabled="1" hint.ax.1.disabled="1" module_blacklist="axgbe" The upgrade worked like charm and everything is working as expected As a side node: I didn't found any clue for the 10GE AMD ax devices on the FreeBSD12 2.7.0, so the NICs weren't functioning anyway. Thanks! for your help. Greetings, Chris

My version of include file already has this fix, but the issue persists.