Why microcode_ctl and not intel-ucode-firmware?

[vt-alt]

Why the package is called microcode_ctl unlike amd's version which includes ucode-firmware in the name? I am thinking about packaging it for ALT Linux, but unsure about naming scheme.

[SkewedZeppelin]

That is simply the name used by Fedora, which this package was made for: https://src.fedoraproject.org/rpms/microcode_ctl
I kept the name so it could automatically override their ucode packages by setting a higher epoch.

feel free to change it as appropriate for whatever distro you're packaging it for

[SkewedZeppelin]

seems ALT uses an even different scheme: firmware-intel-ucode

[vt-alt]

Yeah. Thanks for the answer. By their spec it seems they had microcode_ctl tool, but not anymore. I think we should name it firmware-intel-real-ucode, since we already have firmware-intel-ucode (from Debian). And I think how to package amd-ucode so it does not conflict with firmware-linux (with /lib/firmware/amd-ucode already), perhaps, it should go into /lib/firmware/updates.

[SkewedZeppelin]

back when Fedora had amd-ucode part of linux-firmware I used a post install hook in the spec file to move them into place

[vt-alt]

BTW, a small remark after some testing, README says microcode.amd_sha_check=off is needed only in regard of resigned firmware, but it seems to be always required for non-official amd-ucode.

For example, my test supermicro box can handle 08001278 which is not in arch/x86/kernel/cpu/microcode/amd_shas.c. Curiously, it is, while having nion-updated BIOS, can load non-resigned microcode.

[SkewedZeppelin]

seems to be always required for non-official amd-ucode.

all of .official is official, but yes the database in Linux is seemingly gatekeeping ucodes that also aren't in linux-firmware

I suspected this, but most of my systems either are already running the latest ucode or are eol by the vendor and I'm using the resigned variant. so thank you for testing that, I'll adjust this soon to always recommend that flag.