On Tue, Jan 16, 2018 at 4:06 PM, Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx> wrote: > On Tue, Jan 16, 2018 at 03:42:42PM -0500, Josh Boyer wrote: >> On Tue, Jan 16, 2018 at 3:36 PM, Zbigniew Jędrzejewski-Szmek >> <zbyszek@xxxxxxxxx> wrote: >> > On Tue, Jan 16, 2018 at 06:54:36AM -0500, Josh Boyer wrote: >> >> On Mon, Jan 15, 2018 at 12:58 PM, Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote: >> >> > If microcode is updated, but the initramfs isn't regenerated, so the >> >> > newer microcode get loaded later in the boot process once available? >> >> > Or does it have to be in the initramfs? >> >> >> >> I can't remember if systemd does this now by default or not. The best >> >> option is to regen the initramfs. >> > >> > systemd does not regenerate the initramfs, and never did. I think this is >> > only done automatically upon kernel upgrade. >> >> Sorry, I was unclear. I meant I don't know if systemd has a service >> to reload microcode later during the boot. > > Oh, afaik it has to be loaded very early. early-microcode cpio image is > generated and used when the kernel is starting. I don't think we can > load microcode later. I got irritated at myself for not remembering, so I looked at the code. There is a mechanism in the kernel to support loading microcode later in the boot. It can be done through /sys/devices/system/cpu/microcode/reload. However, nothing in Fedora leverages this and it is really dependent on the class of problem and how the microcode fixes it. All that to say, rebuild the initramfs. It's the safest way to fix ucode issues. josh _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
