On 18/01/18 18:55, Matthew Miller wrote: > On Thu, Jan 18, 2018 at 11:45:42AM -0500, Pete Geenhuizen wrote: >>>> Do we update the microcode now or do we wait until the latest >>>> microcode_ctl rpm is available and then tackle this issue? >>> Check with your hardware vendor for BIOS/EFI firmware updates. Apply >>> those. >>> >> Thanks for the reply, but you missed what I was asking. I've >> already downloaded the appropriate files from the links that Johnny >> provided in a previous posting. >> My question is, do we wait until the latest microcode_ctl rpm is >> installed or do it now? My concern is that if I do it now the new >> rpm might undo what I've done. > > It does not matter. The microcode_ctl package contains CPU firmware > that is loaded at by the kernel early in the boot process if it's newer > than the one provided by the system firmware/BIOS. It is never > permanently stored in NVRAM or anything — it's loaded at each boot. > Hence, by my understanding, there should not be any permanent damage should you get a 'bad' microcode update, either from Intel or Red Hat, that prevents the system from booting. Presumably one should still always be able to boot the machine from a rescue disk, mount the fs and either delete the offending microcode or uninstall the microcode_ctl package to allow the system to boot again. This should not result in a 'bricked' permanently unrecoverable system.