Talk:Microcode

CPU microcode loading support for custom kernel

Is the section Microcode#Enabling Intel Early Microcode Loading in Custom Kernels still relevant when initrd /intel-ucode.img is added to the Gummiboot options? -- Gim (talk) 09:42, 1 November 2014 (UTC)

Passing parameters with refind

With this edit User:Vesz deleted "/boot/" from parameters. Is this correct? Because in the following paragraph there is explained to use initrd=/intel-ucode.img or /boot/intel-ucode.img as required. As you can see, there "/" symbol is used before "intel-ucode.img". — Agent0 (talk|contribs) 20:21, 20 February 2015 (UTC)

I have only tried using it without a /, and it works. I assume that it might work with a / as well but I haven't confirmed it. Either way it seems that if you have a separate boot partition it's wrong to enter the path in a root-filesystem format. I don't have access to the system in question right now so I can't try with a leading /. Vesz 21:09, 20 February 2015 (UTC)

Disable microcode updates

Is there any way to disable microcode updates? We have had trouble with failed microcode updates in VMs so it would be great if it were possible to disable them (for AMD in this case)

—This unsigned comment is by Marcus039 (talk) 05:02, 3 January 2016‎. Please sign your posts with ~~~~!

The answer to your question is clearly articulated in the main article. Graysky (talk) 15:18, 3 January 2016 (UTC)

No it is not, the page deals only with enabling, not disabling microcode updates. For Intel it can be disabled trivially (you just uninstall intel-ucode), but since for AMD the updates are available in linux-firmware and applied automatically, disabling it is not clear at all. -- Lahwaacz (talk) 20:06, 3 January 2016 (UTC)

The late loading of microcode doesn't happen by default, it's done by /usr/lib/tmpfiles.d/linux-firmware.conf. It can be disabled by creating an empty /etc/tmpfiles.d/linux-firmware.conf. I also opened FS#59840. -- nl6720 (talk) 08:09, 28 August 2018 (UTC)

The bug report didn't work out, so I added instructions for disabling late microcode updates. -- nl6720 (talk) 06:30, 2 September 2018 (UTC)

Please remove the following paragraph

Warning: This file will automatically be overwritten by /usr/bin/grub-mkconfig during certain updates negating the changes. It is strongly recommended to use the configuration directory in /etc/grub.d/ to manage your GRUB configuration needs.

This paragraph must be removed because grub now recognize the presence of intel_ucode.img in /boot.

—This unsigned comment is by Speedyx (talk) 13:53, 28 October 2016‎. Please sign your posts with ~~~~!

That's why there's Microcode#Automatic_method. The warning says that the grub.cfg file would be overwritten by grub-mkconfig, which is still true. -- Lahwaacz (talk) 14:39, 28 October 2016 (UTC)

Since the section starts with "Alternatively, users that manage their GRUB config file manually...", I removed the note. -- nl6720 (talk) 08:40, 27 August 2018 (UTC)

Addition in EFI Boot stub

My addition to the Microcode#EFI_boot_stub_.2F_EFI_handover refers to use cases where the kernel and initrd are merged into a single .efi file, which can be signed for secure boot. In that case you can only specify a single initrd. If you want to update the microcode anyway in this setup, the microcode and the actual initrd can be concatenated with cat. --Aliena 27.05.2017 20:07

Thank you for responding to this, better late then never. However, that still does not explain why the single .efi file is necessary (initrd is not mentioned even once on the Secure Boot page), nor what objcopy ... is supposed to do. It also does not seem specific to the "EFI boot stub / EFI handover" section. -- Lahwaacz (talk) 19:37, 27 May 2017 (UTC)

I'm only learning how to care of contributions, i.e. having a watchlist etc. objcopy is not mentioned directly, but the Secure Boot page refers to sbupdate-git^AUR which uses it to generate a single .efi file. There is also this github repo which has a script to do the same job. This setup is desirable because this way kernel, initrd and cmdline are protected by secure boot. This is a special application of the EFI boot stub since that stub is used as a "base binary" in objcopy to generate the singed kernel binary. Thus I added it to the section rather than creating an own one. And when using this objcopy tool to solve the problem of securing the initrd you can only integrate a single initrd. Now the question my post answers is: "How can I use objcopy to have the microcode loaded before the actual initrd?" and the anser is "Concatenate them". Aliena 17:20, 28 May 2017 (UTC)

amd-ucode

There is now a amd-ucode that provides /boot/amd-ucode.img, it's used the same way as /boot/intel-ucode.img - by adding it as the first initrd. When linux-firmware 20180821.1d17c18-2 moves to core, Microcode and some pages in Category:Boot loaders will need to be updated.

Should we duplicate each boot loader configuration for each microcode or use a pseudo-variable (e.g. /boot/cpu_manufacturer-ucode.img)? -- nl6720 (talk) 09:50, 24 August 2018 (UTC)

I updated the article and used the pseudo-variable. -- nl6720 (talk) 09:19, 26 August 2018 (UTC)