Description of problem: The latest microcode for Intel should update to version 0x25 in my case (Intel(R) Core(TM) i7-4790K) but it does not. Version is 0x24 which is from the Bios I updated myself. Version-Release number of selected component (if applicable): microcode_ctl.x86_64 2:2.1-26.fc28 How reproducible: Just update the microcode_ctl package and reboot. Steps to Reproduce: 1. boot the OS. Actual results: $ dmesg | grep microcode [ 0.520184] microcode: sig=0x306c3, pf=0x2, revision=0x24 [ 0.520453] microcode: Microcode Update Driver: v2.2. Expected results: revision=0x25 Additional info: $ lscpu | grep Intel Identifiant constructeur : GenuineIntel Nom de modèle : Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz Upsteam documentation (Intel): https://downloadcenter.intel.com/download/28039/Linux-Processor-Microcode-Data-File == 20180807 Release == ../.. ---- updated platforms ------------------------------------ ../.. HSW-H/S/E3 Cx/Dx 6-3c-3/32 00000024->00000025 Core Gen4 Desktop; Xeon E3 v3 $ grep 'stepping\|model\|microcode' /proc/cpuinfo model : 60 model name : Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz stepping : 3 microcode : 0x24 model : 60 model name : Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz stepping : 3 microcode : 0x24 model : 60 model name : Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz stepping : 3 microcode : 0x24 model : 60 model name : Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz stepping : 3 microcode : 0x24 model : 60 model name : Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz stepping : 3 microcode : 0x24 model : 60 model name : Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz stepping : 3 microcode : 0x24 model : 60 model name : Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz stepping : 3 microcode : 0x24 model : 60 model name : Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz stepping : 3 microcode : 0x24 $ sudo journalctl --no-hostname -o short-monotonic --boot -0 | grep 'microcode\|smp' [ 0.000000] kernel: smpboot: Allowing 8 CPUs, 0 hotplug CPUs [ 0.014050] kernel: smpboot: CPU0: Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz (family: 0x6, model: 0x3c, stepping: 0x3) [ 0.014888] kernel: smp: Bringing up secondary CPUs ... [ 0.017347] kernel: smp: Brought up 1 node, 8 CPUs [ 0.017347] kernel: smpboot: Max logical packages: 1 [ 0.017347] kernel: smpboot: Total of 8 processors activated (63961.77 BogoMIPS) [ 0.520184] kernel: microcode: sig=0x306c3, pf=0x2, revision=0x24 [ 0.520453] kernel: microcode: Microcode Update Driver: v2.2.
next time don't give negative karma just because a update seems not to have any positive impact on your machine as long there are no regressions and before cry out type "dracut -f" into a root shell and reboot
As Herald said, $ sudo dracut -f fixed the issue. Thank you. Why is this command not part of the install process of this package (microcode_ctl)? Waiting for the next kernel update is somewhat a workaround.
please consult stackoverflow for questions about the boot process! because it's not much fun overwrite the last recent known working initrd with arbitary updates lsinitrd shows you what is all in there and you have for every installed kernel a own initrd, if something is borked there and you update the kernel without reboot and the kernel don't work your last recent entry is also dead the whole idea of having more than one kernel is to ensure a working way back at boot in case of troubles and when every random package which is contaiend in the initrd re-creates it you will lose that capability, so just wait for the next kernel which is anyways away only a feew days on fedora or RTFM [root@rh:~]$ uname -a Linux rh.thelounge.net 4.17.14-202.fc28.x86_64 #1 SMP Wed Aug 15 12:29:25 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux however, just because something does not have any positive impact for you don't justify negative karma and holding back the update for everryone else by disable autopush as long you can't point out a regression
i turn the question: update *which initrd* only the last recent? every existing for every installed kernel and risk a unbootable system? to gain what? 99.0% of all users don't reboot anyways even if the initrd is automatically updated with the risk of breaking boot of the probably only working kernel because they are not capable to realize it's needed years ago microcode updates have been applied at runtime but ten came Intel Haswell with the first microcode update which *removed* CPU capabilities and so they have to be applied before the kernel these days otherwise the kernel says "hey, fine, TSX instrcutions there" enables usage and after apply teh microcode they are gone and the system crashs
Harald is just right here. This concern was brought up several times in past, and I can't add more to what Harald wrote. We want to keep you machine bootable.
Hi, I think you should rethink this approach to get in line with downstream. Leaving users with unpatched microcode may leave them with a more vulnerable system. RHEL approach is to update initramfs, not just latest but multiple. https://git.centos.org/rpms/microcode_ctl/blob/c8/f/SPECS/microcode_ctl.spec#_211 Related BZ (I am guessing from changelog, not public): https://bugzilla.redhat.com/show_bug.cgi?id=1760508 And more related information from changelog: * Wed Jun 03 2020 Eugene Syromiatnikov <esyr> - 4:20191115-4.20191115.5 - Re-generate initramfs not only for the currently running kernel, but for several recently installed kernels as well. Greetings Klaas
> Re-generate initramfs not only for the currently running kernel, but for several recently installed kernels as well that is nice on RHEL but for Fedora when you have updates-testing enabled and some dracut update or whatever component leaves you with a non-working initrd it's no fun when you can't boot at all
(In reply to Harald Reindl from comment #7) > > Re-generate initramfs not only for the currently running kernel, but for several recently installed kernels as well > > that is nice on RHEL but for Fedora when you have updates-testing enabled > and some dracut update or whatever component leaves you with a non-working > initrd it's no fun when you can't boot at all I would be happy with just recreating the newest kernel initramfs so that you can keep two working initramfs (with the default 3 installonly limit and assuming it's not a brand new installation) to satisfy the possibility of a dracut version breaking initramfs creation. In the microcode_ctl.spec file I linked above you'll see that this is also something rhel engineers were concerned about. From a user standpoint I am very much for handling it the "RHEL" way. Fedora being upstream RHEL I was not expecting it to behave this differently and there is not even a message in logs :)
FYI, there's an RFE[1] for splitting out early ucode part of initrd, it is the likely way forward. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1829601