On Tue, Jan 16, 2018 at 3:55 PM, Reindl Harald <h.reindl@xxxxxxxxxxxxx> wrote: > > Am 16.01.2018 um 21:42 schrieb Josh Boyer: >> >> 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 > > > you can't and frankly even yourself said that in > https://bugzilla.redhat.com/show_bug.cgi?id=1083716#c9 Er... that's not exactly what that bug said. It said we can't solve the TSX issue later in boot. It didn't say there wasn't a way to load microcode later for issues that could be resolved later. > that was how it worked years ago but since Haswell where the microcode > removes TSX as example this must happen in the initrd because otherwise the > kernel may use cpu-instrcutions which are gone after microcode update and > crashs Right. I've no idea what the ucode updates in question do, nor whether they can be loaded later in boot. That's orthogonal from whether there is a mechanism to do so. josh _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
