Bug 1616433
| Summary: | microcode is not updated early at boot | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Yannick Defais <sevmek> |
| Component: | microcode_ctl | Assignee: | Anton Arapov <aarapov> |
| Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 28 | CC: | aarapov, esyr, h.reindl, jarodwilson, jonathan, klaas, mikedep333, sevmek |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2018-09-24 16:10:15 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Yannick Defais
2018-08-15 21:31:18 UTC
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 |