@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.

Thank you! 😃

@johnpoz said in S.M.A.R.T. not available on Netgate 2100 in 24.03?:

Nice thread - I plan on moving to ssd on my sg4860 when I install 24.03.. Having smart will be handy.

It's already there on amd64, this only affected ARM systems

No there isn't. Interetsing idea though, you could open a feature request: https://redmine.pfsense.org/

Yup it's probably that. The upgrade from 23.09.1 to 24.03 is quite large, it requires quite a lot of space to pull in the update files. I would want to see at least 1G available.

Steve

@slu Ah thanks a lot, I never thought to look at the boot environments because they were showing that they only took up a few KB of space.