Talk:Microcode

From ArchWiki
Latest comment: Friday at 12:03 by Jtag in topic microcode hook in mkinicpio

Which CPUs accept microcode updates

AMD has closed its Operating System Research Center since November 2012: See this Phoronix article

The link to AMD's Operating System Research Center doesn't work any longer.

Maybe the section should be updated by removing the information for AMD users and keep only the information for Intel users ?

—This unsigned comment is by Zzrzlk (talk) 08:53, 1 July 2019‎ (UTC). Please sign your posts with ~~~~!Reply[reply]

Grub config file instructs the user not to manually edit it.

It might be worth making some kind of note that grub does not expect users to be editing the config file since the wiki presents manually editing this file as an option.

Benm (talk) 22:43, 27 March 2021 (UTC)Reply[reply]

It specifically says that option is for people managing the config file manually instead of using grub-mkconfig. It's a completely different situation from what you're talking about.
Scimmia (talk) 23:08, 27 March 2021 (UTC)Reply[reply]


Reverting Unified kernel images section to pre Special:Diff/751285

Reverted the Unified kernel images subsection to before Special:Diff/751285, as it just duplicates content which is already in Unified kernel image#mkinitpcio, whereas Unified kernel image contains guidance for mkinitcpio and other methods.

-- Cvlc (talk) 16:50, 5 October 2022 (UTC)Reply[reply]

microcode hook in mkinicpio

/etc/mkinitcpio.conf ships with the hook microcode now. Would be nice to have some information here about what it does or where to find more information. Pavelskipenes (talk) 18:41, 4 March 2024 (UTC)Reply[reply]

https://gitlab.archlinux.org/archlinux/mkinitcpio/mkinitcpio/-/merge_requests/291 Hanabishi (talk) 19:03, 4 March 2024 (UTC)Reply[reply]
I get the impression that I have to
  1. Remove `amd-ucode` or `intel-ucode` from bootloader's initrd.
  2. Add `microcode` to mkinitcpio's hooks.
Is that right? I haven't done anything because I don't want to mess up. I wish the wiki could make it more clear. 4color (talk) 02:44, 6 March 2024 (UTC)Reply[reply]
The `microcode` hook is automatically added to `/etc/mkinitcpio.conf` after new initramfs update. So I think we should only remove ucode from bootloader's initrd and nothing else. (Second step you mentioned is already done automatically) Jtag (talk) 11:23, 6 March 2024 (UTC)Reply[reply]
It is added automatically, but if the user modified `/etc/mkiniticpio.conf` in the past, the change is only done to the Pacnew file and has to be merged manually. The creation of the Pacnew file is also mentioned in the pacman log. Gregthwuen (talk) 13:22, 9 March 2024 (UTC)Reply[reply]
Yes very important note, thanks for mentioning. Jtag (talk) 12:03, 15 March 2024 (UTC)Reply[reply]
You also have to run mkinitcpio again to regenerate the images. But I think this isn't enough because with the changes it's not generating /boot/xxx-ucode.img and apparently no microcode is being loaded as I'm seeing warnings on journalctl. Danisztls (talk) 11:13, 15 March 2024 (UTC)Reply[reply]
What I'm also wondering is whether the `amd-ucode` and `intel-ucode` packages are still required after this change. At least the `.img` files in `/boot/` shouldn't be necessary anymore, right? Gregthwuen (talk) 13:33, 9 March 2024 (UTC)Reply[reply]
Of course. They contain the microcode in /usr/lib/firmware [1], which is used by mkinitcpio.
Hanabishi (talk) 14:15, 9 March 2024 (UTC)Reply[reply]
You mean `amd-ucode` and `intel-ucode` packages are still required, or the `.img` files in `/boot/` aren't necessary anymore, or both? 4color (talk) 14:26, 9 March 2024 (UTC)Reply[reply]
Both. If you use mkinitcpio with the new microcode hook, you don't need imgs anymore. You could delete them manually, but they will be installed again with the next firmware update anyway, so it is kinda pointless.
Answering ahead of the next question: old images are kept for compatibility [2].
Hanabishi (talk) 14:36, 9 March 2024 (UTC)Reply[reply]
Thanks for clarifying. For other hooks mkinitcpio prints out a warning about “possibly missing” files, which does not happen for the `microcode` hook with the `-ucode` packages missing. That's what irritated me a bit. Gregthwuen (talk) 15:33, 9 March 2024 (UTC)Reply[reply]
I went down the rabbit hole, yes - and the bit of missing information from the announcement is a step found in the forums after:
  1. Update all packages
  2. Add `microcode` to mkinitcpio's hooks
  3. Regenerate all initrds
    1. mkinitcpio -p linux
    2. mkinitcpio -p linux-lts
  4. Add to `/etc/default/grub`:
    1. GRUB_EARLY_INITRD_LINUX_STOCK=""
  5. Regenerate grub.cfg (keep an old copy! you can rescue boot it)
    1. cp -a /boot/grub/grub.cfg /boot/grub/grub-old.cfg
    2. grub-mkconfig -o /boot/grub/grub.cfg
Under the hood, the intel/amd packages own both the pre-built /boot img files and the unpacked files in /lib/firmware. The new mkinitcpio code runs a CPU detection routine, then takes the unpacked files and builds it's own combined binary ("GenuineIntel.bin" e.g.) which is then added inside the initramfs file. (run mkinitcpio --verbose .... > log.txt to see it all, it's a lot of output)
So for now due to how the packaging is combined for ucode, we have to use that extra setting to tell GRUB to ignore those files on disk as part of it's auto-detection routines. It's documented about 1/2 the way down the manual over here: https://www.gnu.org/software/grub/manual/grub/html_node/Simple-configuration.html TE (talk) 14:26, 9 March 2024 (UTC)Reply[reply]
Is using the new microcode hook actually manadatory in all cases going forward, or just for the subset of users that were previously relying on the --microcode flag and the microcode option in the preset files?
If you're using GRUB you can just skip adding the microcode hook and microcode loading is still going to work. In this case there is no need to add GRUB_EARLY_INITRD_LINUX_STOCK="" to /etc/default/grub. That's what I did since it seemed the more straightforward solution given the (lack of) information in the news. Noctavian (talk) 16:10, 12 March 2024 (UTC)Reply[reply]
No, not mandatory. You can remove the hook and continue to use separate .img files the old way.
In fact mkinitcpio is very late with this trasnition. E.g. dracut includes microcode into the initrd image already for years.
Hanabishi (talk) 16:19, 12 March 2024 (UTC)Reply[reply]
Noctavian your question is also "how far do I want to drift from the Arch desired defaults?" as well. The updated mkinitcpio package deploys the microcode hook in the default config file, making it an expected part of a "normal" system going forward. You needn't have ever used any special work before such as a --microcode switch, it was all being done for you by the GRUB logic and ucode packages working in tandem.
The updated GRUB work is nothing more than "don't have two subsystems trying to do the same thing" (inject microcode), it's left in place right now for compatibility needs; I can envision a future where the `intel-ucode` (and amd) packages stop deploying the file /boot/intel-ucode.img which will naturally stop GRUB from adding it as an initrd without any config actions needed. But that day may be far down the road (who knows), by doing this work now I ensure my desired outcome is met. $0.02 TE (talk) 18:37, 12 March 2024 (UTC)Reply[reply]
Is there any discussion or justification for why this change was made in mkinitcpio? I've been familiar with dracut for a while and understood this microcode loading method to be implemented there only for some legacy compatibility reason, and that loading microcode as a separate initrd was the superior option, if supported. Brocellous (talk) 20:00, 13 March 2024 (UTC)Reply[reply]
You might find something in the discussion around the relevant merge request. Do you have some reference for this dracut reasoning? — Lahwaacz (talk) 22:31, 13 March 2024 (UTC)Reply[reply]
I doubt that information too. At least because dracut worked that way since the very introduction of microcode loading support [3]. And even mere awareness of existing images was introduced far later [4].
Hanabishi (talk) 23:11, 13 March 2024 (UTC)Reply[reply]