@SamJWard Hmm... they don't have monitoring system in place to notify their server admins that the systems are down? Would be nice if they have a network status page on the netgate support site in cases like this so we don't waste time trying to figure out if there is something wrong with our pfsense / netgate appliances like I dealt with today. This would also prevent un-necessary tickets.

Yes I am a bit frustrated to spend couple of hours troubleshooting only to find out it wasn't my instance. Although I am used to it in the IT world.

Least now I know after finding a couple of posts about this that I can stop troubleshooting and wait till in the morning to try again.

Hmm, yes that should not need to be registered and should always return as eligible.

Send me the NDI and serial in chat and I can check it. Or open a TAC ticket: https://www.netgate.com/tac-support-request

More info needed.

If you're running ZFS you can roll back the BE, yes. But that also means it upgraded and verified the boot or it would have rolled back automatically.

So if the upgrade was successful that implies some other failure in the new version. It failed to pull an IP address?

OK so it's trying to use something in pkg that doesn't exist in 2.4.5.

So, again, what update branches do you see offered in the GUI?

2.4.5 to 23.01 is too large a jump. You will probably need to upgrade first to something closer to 2.4.5.

Send me your NDI and/or Order number in chat and I'll check it.

Steve

@stephenw10

I will try to uninstall and then install it via "pkg upgrade" again.

This: https://redmine.pfsense.org/issues/15396

@SteveITS I don't think I uninstalled plus.

I believe at some point I must have reinstalled the image in order to get ZFS and then I restored from whatever config backup I had.

...maybe I explicitly uninstalled Wireguard at some point. This is a home setup, so I don't keep notes on it like one might for a business install :)

Rich

@SteveITS said in 24.03 pulled?:

@hspindel not as of last night. Which branch do you have selected?

I'm on the RELEASE branch.

Mysteriously, 24.03 just now reappeared as an upgrade.

@stephenw10 Well, to fix the issue, I was lucky I made a backup before attempting to update. I ended up downloading the new 2.7.2 CE ISO with my MacBook Pro through my iPhone hotspot, checked the checksum, and burned the ISO to disk. I wiped the SSD on my computer that pfSense was installed on. I then installed a fresh/clean pfSense 2.7.2 CE. I restored the backup. I updated pfSense to 24.03. All is good now. Wheeeew!

@stephenw10 Thank you Steve. That worked.

That's what you see on the video console when the serial console is set as primary. Everything after mounting root until the console menu comes up is shown on the primary console only. Except for a few things like new device detection and link state changes, hence you see the aesni0 device.
It was probably waiting for some input on the serial console but would have eventually rolled back the BE snap after not verifying the boot.

Steve

The update status reporting was improved. The error state you see that is actually correct and is usually because it has just booted after an upgrade and some other pkg process is running in the background preventing the check running. It will show the update status after that finishes. In previous versions that was incorrectly showing as up to date when in fact it could not check.

Well, I guess posting helped. I finally found the right info, which is "boot.config". The machine had no "/boot.config" or "/boot/config" file. I added one containing:

and it now boots without intervention. The files "/boot.config" and "/boot/config" both worked.

@jimp I think I messed up with interfaces (I switched from a virt wan to a physical wan) and that changed the NID.

Working with assitence to migrate the new NIDs.

Send me the order number and NDI in chat and I can check it.

@stephenw10 Yea I just noticed this yesterday after I re read through the logs.

Then I removed the ntop repo and now update has completed.

Sorry, thats my bad.

All sorted now thanks

It should be handled properly any time the CA trust store gets refreshed now.

I'll get that into the system patches package in the near future as well.

@Gertjan VLAN's, rules and a silly Bitwarden password are in place. "crapmin" was just some self-deprecating humor.

Before upgrading I usually make a new clone from the working BE, name it to xx.yy_upgrade, set it to default boot and boot to it before upgrade.
If all seems ok after a testing period, I rename it to xx.yy_stable