@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: zroot:/boot/zfsloader 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

Hmm, unexpected to see that error. But, yes, on an amd64 install it the _1 update does not do anything anyway.

@patient0 Yea sorry about that kept posting in wrong place total my fault for not looking closer. I was really P----d at the time. and thanks for reply i look further into today

@stephenw10 I understand what you're saying, and if this is the “fashion” now, I'll follow “everyone else”. Thank you for your intervention.

@stephenw10: It was fine a few hours later.

Ah nice. Also confirms an issue exists there. And still exists in 24.03-REL.