Now Available: pfSense® Plus 25.07-RELEASE
-
Just tested the patched pfSense-rc on our spare unit.
/etc: diff pfSense-rc.org pfSense-rc
590c590
< SWAPDEVICE=/bin/cat /etc/fstab | /usr/bin/grep swap | /usr/bin/awk '{ printf $1 }' | /usr/bin/head -n 1SWAPDEVICE=
/bin/cat /etc/fstab | /usr/bin/grep swap | /usr/bin/awk '{ print $1 }' | /usr/bin/head -n 1Works like a charm:
: swapinfo
Device 1K-blocks Used Avail Capacity
/dev/ada0p2 1048576 0 1048576 0%
/dev/ada1p2 1048576 0 1048576 0%
Total 2097152 0 2097152 0%: cat /tmp/fstab.swap
Device Mountpoint FStype Options Dump Pass#
/dev/ada0p2 none swap sw 0 0
/dev/ada1p2 none swap sw 0 0
[25.07-RELEASE][admin@arn1-ops-vpnspare.mgmt.sidn.nl]/etc: -
I'm planning to upgrade, but still on 24.11 and I have ZFS mirror with GEOM mirrored swap, would this problem affect my system or is it just for systems with multiple separate (non-mirrored) swap partitions on the both drives?
-
Try running the new command in 24.11:
/bin/cat /etc/fstab | /usr/bin/grep swap | /usr/bin/awk '{ printf $1 }' | /usr/bin/head -n 1If that returns a valid device it will be fine in 25.07.
Either way it won't prevent you upgrading. And you should just be able to apply the patch afterwards to regain SWAP. If you need it.
-
@stephenw10
It returns "/dev/mirror/swap" so guessing it should be ok.
Never had pfSense using any swap, but better safe than sorry... :) -
Yup should be fine.
-
As expected, also works just fine on 25.07.1-RELEASE.
-
Is the SG-3100 a still supported device? Just bricked one of ours updating 24.11 -> 25.07.1 - notice the "unsupported platform" message from the update log.
... Installed packages to be UPGRADED: pfSense-boot: 24.11 -> 25.07.1 [pfSense-core] Number of packages to be upgraded: 1 [1/1] Upgrading pfSense-boot from 24.11 to 25.07.1... [1/1] Extracting pfSense-boot-25.07.1: .......... done >>> Upgrading pfSense kernel... Checking integrity... done (0 conflicting) The following 1 package(s) will be affected (of 0 checked): Installed packages to be UPGRADED: pfSense-kernel-pfSense-3100: 24.11 -> 25.07.1 [pfSense-core] Number of packages to be upgraded: 1 [1/1] Upgrading pfSense-kernel-pfSense-3100 from 24.11 to 25.07.1... [1/1] Extracting pfSense-kernel-pfSense-3100-25.07.1: .......... done ===> Keeping a copy of current kernel in /boot/kernel.old >>> Removing unnecessary packages...done. >>> Upgrading boot code... Unsupported platform. System is going to be upgraded. Rebooting in 10 seconds. Success -
Scratch that last post. The problem was related to +30k backup config files as noted in other posts.
Problem solved unit on 25.07.1 now. Will clear the directory before doing our other units. -
Yup it's only the boot code update script reporting that there. The 3100 is EoL but 25.07(.1) does still support it.
-
All,
On my SG5100 just upated to 25.07.1 over the weekend. No issues. It uninstalled and re-installed one package automatically. Otherwise I did nothing else.
To be clear, my setup is fairly simple.
Phizix
-
Unsuccessful upgrade from 24.11 => 25.07.1 on an SG2100.
Things to Note:
- Performed upgrade from console using option 13
- All went smooth with packages updated, boot code updated, and rebooted into 25.07
- Got to Updating Configuration and abruptly stated "Shutdown Now!"
- Rebooted itself into 24.11
Sincerely welcome any ideas on what might be causing this and/or any diagnostic steps I should take.
Thanks!
Relevant Console Log Output:
Welcome to Netgate pfSense Plus 25.07.1-RELEASE... ...ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib /usr/local/lib/compat/pkg /usr/local/lib/compat/pkg /usr/local/lib/ipsec /usr/local/lib/mysql /usr/local/lib/perl5/5.36/mach/CORE 32-bit compatibility ldconfig path: done. External config loader 1.0 is now starting... mmcsd0s1 mmcsd0s2 mmcsd0s3 mmcsd0s3a Launching the init system... done. Initializing.................... done. Starting device manager (devd)...done. Loading configuration...done. Updating configuration...2025-09-23T23:33:14.237019-07:00 - php-fpm 597 - - /rc.linkup: Ignoring link event during boot sequence. ....2025-09-23T23:33:14.562014-07:00 - php-fpm 597 - - /rc.linkup: Ignoring link event during boot sequence. 2025-09-23T23:33:14.754643-07:00 - php-fpm 598 - - /rc.linkup: Ignoring link event during boot sequence. 2025-09-23T23:33:14.755108-07:00 - php-fpm 1206 - - /rc.linkup: Ignoring link event during boot sequence. 2025-09-23T23:33:14.888755-07:00 - php-fpm 597 - - /rc.linkup: Ignoring link event during boot sequence. 2025-09-23T23:33:14.931626-07:00 - php-fpm 1203 - - /rc.linkup: Ignoring link event during boot sequence. 2025-09-23T23:33:15.026406-07:00 - php-fpm 598 - - /rc.linkup: Ignoring link event during boot sequence. Shutdown NOW! shutdown: [pid 2086] 2025-09-23T23:48:09.690216-07:00Waiting (max 60 seconds) for system process `vnlru' to stop... done Waiting (max 60 seconds) for system process `syncer' to stop... Syncing disks, vnodes remaining... 0 done All buffers synced.Full Console Output: pfsense-console.zip
-
@johan333 said in Now Available: pfSense
Plus 25.07-RELEASE:Performed upgrade from console using option 13
... and you've logged the console output.
That's just
At least, you've put all changes on your side. If the upgrade goes well, you have the details, and you can forget about them.
If it didn't, something went wrong, changes are high you know what happened, and why.Now for the bad news : about the shutdown.
It happens in the very early boot sequence of the kernel.
It's the kernel itself that bails out - or the kernel calls /sbin/shutdown - as this executable contains this exact text string "Shutdown NOW!" but afaik, the file system isn't even mounted yet, so the kernel can't even use "/sbin/shutdown" at that moment.
The thing is, nothing, the why part, was logged.
A work around could be : intercept the boot sequence, and activate verbose kernel logging ?There is a solution, and keep in mind : your pfSense works. So you have a backup of your pfSense config.
Worse case situation : get the installer, and wipe clean / reinstall completely from scratch.
This will take 10 minutes of your time. Success is guaranteed.
... and it will take the 'why this this happened' with it :(I hope you'll receive more helpful info from other forum readers.
-
Hmm, nothing obviously wrong there. Do you see an alert after it reboots into 24.11?
Check System > Boot Environments. Do you see the new 25.07.1 BE marked as failed?
-
@johan333 Based on other posts…
see if /cf/conf/backup is full. If so delete files or visit Diagnostics >Backup> Configuration history until it doesn’t time out. There was a bug where they weren’t automatically deleted.
Delete old/unnecessary boot environments. (Ignore the “size” shown)
-
Yup, very good point. Since it appears to be failing at 'updating configuration' check for far too many backups.
-
Thank you for the help.
@stephenw10 - I would've expected to see some type of kernel panic notice based on this behavior, but no alerts whatsoever. I have the SG2100 console port connected via USB to a RaspberryPi device and logging the console output via
screen. Yes, as per the screenshots, it states the BE failed to verify.
@SteveITS - Interesting...I'll give the GUI diagnostic screen a try. Here's what /cf/conf/backup has:
[24.11-RELEASE][root@pfSense.home.lan]/: du -sh /cf/conf/backup 2.0G /cf/conf/backup [24.11-RELEASE][root@pfSense.home.lan]/: ls -l /cf/conf/backup | wc -l 12318 -
@johan333 said in Now Available: pfSense
Plus 25.07-RELEASE:12318
That's it, then. Should be ~30 files by default.
There were a couple bugs at play, pfBlocker updates a timestamp in the file every cron run, and the backups were not being pruned automatically. So every hour for a year or more... I've seen a few posts here and on Reddit with similar update failure.
-
@SteveITS said in Now Available: pfSense
Plus 25.07-RELEASE:There were a couple bugs at play, pfBlocker updates a timestamp in the file every cron run,
25.07.1 has this issue with pfBlockerNG.
But Maximum Backups option is working.
-
@SteveITS Wow, very interesting and great insight. Based on the evidence, I would've never come to this discovery/conclusion. The diag page does time out BTW, so I'll just manually prune it and try the update again. Know if the bug was fixed in 25.07 and if not what is the work-around people are using (e.g. CRON job)?
-
@mcury said in Now Available: pfSense
Plus 25.07-RELEASE:25.07.1 has this issue with pfBlockerNG
I don't have a link handy but I'm pretty sure Netgate posted that's been fixed in a later version? Or there was a patch in that forum somewhere. It's worse if using pfB in HA because the secondary was getting multiple config files because of its cron plus the sync at cron time.
I have a note to check config history before starting an update.
diag page does time out
It will but if you keep reloading after that, and be patient it should eventually load. I think mine timed out after 10 minutes and had deleted most of the files.
25.7 fixed the history retention.
