Now Available: pfSense® Plus 25.07-RELEASE
-
Yeah those errors from the wifi drivers are normal when the hardware isn't present.
Hmm, I wonder if this is because you have multiple SWAP devices.
Try running:
/bin/cat /etc/fstab | /usr/bin/grep swap | /usr/bin/awk '{ printf $1 }' | /usr/bin/head -n 1That's what the RC script runs to get the swap device, if it returns something unexpected it may fail.
Do you see
/tmp/fstab.swappresent? -
@stephenw10
I think you're onto something.25.07-RELEASE][admin@vpnspare.mgmt.blah]/root: /bin/cat /etc/fstab | /usr/bin/grep swap | /usr/bin/awk '{ printf $1 }' | /usr/bin/head -n 1
/dev/ada0p2/dev/ada1p2[25.07-RELEASE][admin@vpnspare.mgmt.blah]/root:cat /tmp/fstab.swap
/dev/ada0p2/dev/ada1p2 none swap sw 0 0That doesn't look like a correct device, so it's quite likely that this breaks it. We have 4 Netgate 7100's which are like this, with two SSD's built in. We got them delivered like this, no modifications done (except for a broken PSU two times).
On 24.11 it works just fine, and probably on all previous versions we used as well in the past 3 years or so.
On 24.11 it looks like this:
/root: swapinfo
Device 1K-blocks Used Avail Capacity
/dev/ada0p2 1048576 0 1048576 0%
/dev/ada1p2 1048576 0 1048576 0%
Total 2097152 0 2097152 0%root: cat /tmp/fstab.swap
Device Mountpoint FStype Options Dump Pass#
/dev/ada0p2 none swap sw 0 0
/dev/ada1p2 none swap sw 0 0Thanks, Jos
-
Aha! Ok let me do some digging here....
-
Ah, already reported in 2.8: https://redmine.pfsense.org/issues/16232
Looks like an easy enough fix though. Patch incoming....
-
Ok this works for me: 175.diff
It's a very simple (one character!) change so you might just manually edit the file. Let us know if you're able to test that.
-
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.
