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.
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos
