How to enable automatic microcode updates

[olmari]

But this also looks like the Amd early loading system itself works, at least the "no updates found" part. Like Fitch Franco (at forum side :D ) said earlier, I think this is now mostly waiting game for updated suitable microcode package for the actual code loading part to happen on this system :)

[fadern]

Hi,
How will the manual setup work/coexist with the new plugin?

[franco]

Yep, doesn't matter as long as you install the right plugin for your CPU.

Eventually we want to release the early AMD loading code in 24.7.x and remove the late loading from the plugins. So for now the plugins use both load points simultaneously. This means people can further test the 24.7-amd kernel early loading.

I might throw out a new kernel for the early AMD loading. But not today.


Cheers,
Franco

[Wrigleys]

Hi all,

I can confirm that after reverting the tuneables to default and deleting the line "microcode_update_enable="YES"" in /etc/rc.conf, the microcode update will still be performed after reboot.

Many thanks franco and the whole team for another seamless and struggle-free update.

All the best,
Wrigleys

[franco]

Hehe that was the plan, nice :)


Cheers,
Franco

[newsense]

It is best to make sure os-cpu-microcode-{intel,amd} is installed going forward on bare metal systems.

[meyergru]

Yes, but only either one of them, as they are mutually exclusive. If you try to install both, you get strange results (i.e. last one wins and the other package is then "missing").

[franco]

"Missing" in the plugins list? I thought it was just going to uninstall the other one. Then again we didn't have conflicting plugins since os-quagga and os-frr were in the packages alongside for a bit...

[meyergru]

In my case, it was uninstalled and then showed up as missing. I had to uninstall the wrong one again and then install the correct one. Maybe the "missing" was an artifact?

[cookiemonster]

Nice addition. Will it let the admin know when attempting on a non-suitable system, like a Virtual Machine?
I know he/she *should* know, but we've seen people with VMs and misunderstandings.

[meyergru]

Why? It does not hurt. As little as when you choose the wrong version (i.e. AMD vs. Intel). I think many people will stumble over the "install both" hurdle.

In a perfect world (TM), a single plugin would automatically choose if it does nothing (because VM), or installs Intel or AMD versions on installation.

[franco]

The point of contention is:

% git grep microcode_name
sysutils/cpu-microcode-amd/src/etc/rc.loader.d/40-cpu-microcode:cpu_microcode_name="/boot/firmware/amd-ucode.bin"
sysutils/cpu-microcode-intel/src/etc/rc.loader.d/40-cpu-microcode:cpu_microcode_name="/boot/firmware/intel-ucode.bin"

Short of adding more logic to find out what CPU microcode is applicable or adding a GUI toggle this is beyond redemption.

It would probably make for sense for FreeBSD to use it this way... expecially since the kernel code knows if it's executing Intel or AMD microcode because they are separate... ;)

sysutils/cpu-microcode-amd/src/etc/rc.loader.d/40-cpu-microcode:cpu_microcode_amd="/boot/firmware/amd-ucode.bin"
sysutils/cpu-microcode-intel/src/etc/rc.loader.d/40-cpu-microcode:cpu_microcode_intel="/boot/firmware/intel-ucode.bin"

And you have to consider this means pulling irrelevant updates of the other package all the time because it is a hard dependency even if not used.

Funny the late loading code does this automatically without tripping over itself. But I would rather lock this to only use the early loading once the AMD support is in 24.7.x.

We may add the AMD one to our factory images. For now this approach seems the path of least resistance.

[cookiemonster]

Why? - because this is something I want to do when I am around not automatically for a VM especially.
Yes it can hurt. I have had a VM that would crash after a few hours of uptime and took me a while to track the problem. It was fwupd scheduled (not by me) triggering a fwupd update.
Yes it is a different OS but me, no I don't what firmware updates to happen unless I trigger them. Yes they can hurt.
For me is easy in this case, not install the plugin.

[meyergru]

That is somewhat besides my point: fwupd updates firmwares and obviously can do harm. You cannot update microcode from inside a VM. It just does not do anything - which includes harm.

Also there is no cron or systemd job that regularly applies this, as microcode updates are done once (either at kernel start for early loading or - for now only - during the boot process).

[cookiemonster]

Well I will have to respectfully disagree with you there meyergru. The firmware update was problematic for me from a VM, it crashed it instead of not doing anything.
but as I said, easy for me to not install the plugin. The comment and input here is that the plugin should include a warning by default for users of OPN in a VM.