Created attachment 582890 [details] My emerge --info output The current ebuild version of intel-microcode (20190618_p20190623) is missing the microcode 0xb000036, required for my CPU. It just ships microcode 0xb000037 which cannot be use with the following kernel and CPU [1]: # uname -a Linux micro 4.19.59-gentoo #1 SMP Mon Jul 15 16:19:53 CEST 2019 x86_64 Intel(R) Xeon(R) CPU E5-2620 v4 @ 2.10GHz GenuineIntel GNU/Linux I had to install setup ebuild =sys-firmware/intel-microcode-20190514_p20190525 in a local overlay (/usr/local/portage) in order to be able to mitigate the mds CPU vulnerability. # USE="-* split-ucode" emerge -1 =sys-firmware/intel-microcode-20190618_p20190623 ~ iucode_tool -S -l /lib/firmware/intel-ucode/* iucode_tool: system has processor(s) with signature 0x000406f1 microcode bundle 1: /lib/firmware/intel-ucode/06-4f-00 microcode bundle 2: /lib/firmware/intel-ucode/06-4f-01 selected microcodes: 001/001: sig 0x000406f0, pf_mask 0xef, 2015-07-02, rev 0x0014, size 31744 002/001: sig 0x000406f1, pf_mask 0xef, 2019-05-14, rev 0xb000037, size 30720 # USE="-* split-ucode" emerge -1 =sys-firmware/intel-microcode-20190514_p20190525 ~ iucode_tool -S -l /lib/firmware/intel-ucode/* iucode_tool: system has processor(s) with signature 0x000406f1 microcode bundle 1: /lib/firmware/intel-ucode/06-4f-00 microcode bundle 2: /lib/firmware/intel-ucode/06-4f-01 selected microcodes: 001/001: sig 0x000406f0, pf_mask 0xef, 2015-07-02, rev 0x0014, size 31744 002/001: sig 0x000406f1, pf_mask 0xef, 2019-03-02, rev 0xb000036, size 30720 [1] https://www.intel.com/content/dam/www/public/us/en/documents/corporate-information/SA00233-microcode-update-guidance_05132019.pdf
It's not missing but the icude_tool mode we use will combine all available ucodes and install only the latest version which is 0xb000037. You can get 0xb000036 version when you force USE=vanilla. > which cannot be use with the following kernel and CPU Can you please elaborate? Why do you think that this MCU doesn't work for you?
I was mistaken. Now, I tried =sys-firmware/intel-microcode-20190618_p20190623 with the following settings: /etc/portage/package.license: sys-firmware/intel-microcode intel-ucode /etc/portage/package.use: sys-firmware/intel-microcode -* hostonly initramfs In order to be able to load microcode 0xb000037, I needed to have in my /etc/portage/make.conf: MICROCODE_SIGNATURES="-S" Otherwise, the initramfs is not loaded and the old microcode 0xb00002e is used.
(In reply to David Sardari from comment #2) > Now, I tried =sys-firmware/intel-microcode-20190618_p20190623 with the > following settings: > /etc/portage/package.license: sys-firmware/intel-microcode intel-ucode > /etc/portage/package.use: sys-firmware/intel-microcode -* hostonly > initramfs > > In order to be able to load microcode 0xb000037, I needed to have in my > /etc/portage/make.conf: > MICROCODE_SIGNATURES="-S" Well, since we have USE=hostonly you don't need any MICROCODE_* var anymore. USE=hostonly will do exactly that... add "-S" option. You only need to set MICROCODE_* on your own if you want to manipulate blacklist. And in your case you have to do that because your processor is blacklisted because it will require current kernel, see https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-firmware/intel-microcode/intel-microcode-20190618_p20190623.ebuild?id=10029729826cd75a0351e9ec65f2ed2644d777fb#n36 Glad we sorted the issue. Thanks for the feedback. (Changing resolution to INVALID because the reported issue from summary is invalid).
If I am not mistaken the CPU was blacklisted in: https://gitweb.gentoo.org/repo/gentoo.git/commit/sys-firmware/intel-microcode?id=eb9036f6f998c91c6bc021f73bc10ca1b5240ae7 But, this should only affect kernel version <4.14.34. I am using, however, the current LTS kernel: Linux micro 4.19.59-gentoo #1 SMP Tue Jul 16 14:01:16 CEST 2019 x86_64 Intel(R) Xeon(R) CPU E5-2620 v4 @ 2.10GHz GenuineIntel GNU/Linux If the problem still affects the current LTS kernel version, pkg_postinst() should be updated [1]. Otherwise, the microcode shouldn't be blacklisted for kernel =>4.14.34. [1] https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-firmware/intel-microcode/intel-microcode-20190618_p20190623.ebuild#n235
Btw, I can only load the microcode via initramfs. Loading via the new methods leads to a kernel panic: https://wiki.gentoo.org/wiki/Intel_microcode#New_method_without_initram-fs.2Fdisk
We don't take kernel version into account when installing this package because the current running kernel while installing could be OK but user could switch kernel after installation... due to the risk of an unbootable system, user should decide on his/her own. Which method lead to a panic? Keep in mind that "initramfs" can refer to two methods (i.e. created initramfs using genkernel/dracut containing MCUs or chained loading of multiple initramfs', i.e. using /boot/intel-uc.img).
(In reply to Thomas Deutschmann from comment #6) > We don't take kernel version into account when installing this package > because the current running kernel while installing could be OK but user > could switch kernel after installation... due to the risk of an unbootable > system, user should decide on his/her own. Then, the warning in pkg_postinst() in ebuild intel-microcode should be shown regardless of the kernel version (IMHO). I wasn't aware of this problem, because I didn't start with the kernel version <4.14.34, where the warning message kicks in upon intel-microcode installation. I started with gentoo-sources 4.19.59 on my new system, and the warning message didn't get shown. > Which method lead to a panic? Keep in mind that "initramfs" can refer to two > methods (i.e. created initramfs using genkernel/dracut containing MCUs or > chained loading of multiple initramfs', i.e. using /boot/intel-uc.img). I don't have any problems using intel-uc.img. Thus I refrained from using the following "new" method which leads to kernel panics on my system: https://wiki.gentoo.org/wiki/Intel_microcode#Kernel_2 intel-uc.img work for me and didn't take a deeper look at above "new" method.
