Here to chime in from the Plus world. 26.07 upgrade on a Protectli motherboard = kernel panic. The info from here was ridiculously helpful. I use ZFS so I booted to a known good version, deleted the 26.07 environment, entered a shell, and typed echo hint.acpi_spmc.0.disabled=1 > /boot/loader.conf.local followed by another upgrade. Worked flawlessly. Thanks all.

It appears to have been registration-related. All fixed! Thanks.

I would certainly disable the Service Watchdog before upgrade. There's a good chance it's restarting something during the upgrade that should have been stopped and that's causing some problem. In general I would only ever use the Service Watchdog for troubleshooting or some specific issue.

@stephenw10 Ah, just successful logins in the authentication log, but in the system log I see the following about a minute after logging in using LDAP... Sep 8 15:12:19 php-fpm 90613 /index.php: Successful login for user '[redacted username] from: [redacted IP] (LDAP/[redacted AD server name]) Sep 8 15:13:26 php-fpm 24818 ERROR [LDAP Auth] ldap_get_groups() could not bind to server [redacted AD server name]. We've not observed any issues with the binding account or connectivity to the AD server for any other systems, or with any of our pfSense installations prior to the upgrade to 2.9.0, but I'll see if I can get some monitoring in place. I might have 'fixed' it by entering a large value for Auth Refresh Time - perhaps something has changed there between versions. I'm constantly distracted by higher priority issues (not with pfSense!) but will report back if I can get something a little more definite...

@stephenw10 Agreed — no point re-testing 25.11.1. We'll do a fresh install of 26.07 (skipping 25.11.1 entirely, landing from the 24.11 backup) and capture the full set you asked for: ifconfig -vvm lagg0 arp -a truss ping <host-on-lagg> dmesg Re: what it's connected to — the LACP uplink (ix0 + ix1, 10G SR SFP+) goes to a UniFi USG XG-16 (v7.4.1) on ports 13 + 14 (Aggregating / LACP, 20G, Port Mode Infrastructure, Native VLAN Server Network, Tagged Allow All). For reference, on the working 24.11 box ifconfig -vvm lagg0 shows the LACP negotiation fully up: laggproto lacp lagghash l2,l3,l4, active ports: 2, flapping 0 pfSense system: 90:EC:77:88:FB:AB, priority 0x01B2 (434) switch partner: 74:AC:B9:AD:1E:DE, priority 0x001B (27) both members ix0/ix1 in ACTIVE,COLLECTING,DISTRIBUTING / ACTIVITY,AGGREGATION,SYNC I'll capture the same on the 26.07 install and diff it against this. Re: pre-existing flows surviving — you're right that's unexpected. We'll re-examine that during the 26.07 test and report back with evidence either way. Will post the full output here once the fresh install is done.

@coxhaus Very good. It should be a solid setup. I am running a refurbed Intel X520-DA2 10Gb/s network card in another 3060 and use it as the parent interface (trunk port) for up to 15 VLANs to a Ubiquity aggregation pro switch. It is also a solid setup. pfSense 2.9.0 has been reliable for me. Best of luck to you.

Yeah. I confess I've managed to block myself more times than I can count on test systems I forgot I enabled Snort or Suricata on.

@Gertjan said in Auto update check, checks for updates to base system + packages and sends email alerts: @MarinSNB said in Auto update check, checks for updates to base system + packages and sends email alerts: but I get the same error You mean : [image: 1788156076919-9b7ef689-5e2b-4848-bf5e-f2f022bdf20e-image.png] Yeah, these shouldn't be errors lines but mere info lines. You've changed mine in the more 'friendly' : [image: 1788156175918-d1ec652b-b945-456c-ae3d-f6c8ea415a3a-image.png] Change LOG_ERR for LOG_NOTICE where applicable. logger(LOG_NOTICE, "Starting update check"); Real error condition like logger(LOG_ERR, "Unable to check for updates, exiting"); are ok. @MarinSNB said in Auto update check, checks for updates to base system + packages and sends email alerts: /usr/bin/nice -n20 /usr/local/bin/php -q /root/pkg_check.php The command is different from the one I have used in the past: /usr/local/bin/php -q /root/pkg_check.php Both commands are the same. The first one is execute by 'nice' who sets the processor priority a bit lower. My mistake. I failed to also add the full line.

Good question. Upper case -N was added to request a new format for the repo files. -Z makes it request against the new backend. The new backend only uses the new format so it I could imagine using -Z there overrides -N. But I always use -N.

All resolved now. Maybe because my qotom device shows a netgate device id (not sure if that is unique to netgate hardware), but my device probably makes netgate think it is a netgate device, when in fact it is not - just a theory - thanks for the support Steve. They did refund the subscription. You guys, as always are awesome p.s. the instability with the network interfaces, coincidentally occurred with the upgrade timing. In the end, status changes on the interface were triggering a dying PSU. It eventually carked it completely yesterday.

@stephenw10 Yes - for reference if someone searches this thread, it turned out that the device was so old (probably close to 10 years), that the serial number / Netgate device ID wasn't linked. TAC was able to link in the license check database and the issue is resolved. shell command 'pfSense-repoc -DJN' changed from: Your TAC Subscription expired on 2024-05-23. Please renew your TAC Subscription or purchase a pfSense+ subscription by visiting the Netgate store to: Your Netgate device has pfSense+ as part of your device purchase.

Ah, this issue has been fixed in 0.42 which is now available. Run pkg upgrade at the CLI to upgrade it.

Nope that wouldn't invalidate the license or change the NDI. Since it's a Netgate device it should indeed always be valid. You can open a TAC ticket and they will resolve it or send me your NDI in chat and I'll dig into it.

Yes, no errors, but too long for a few MB.