I'm using latest kernel 4.1.6 from gentoos-sources. After I updated both sys-apps/microcode-ctl and sys-apps/microcode-data to their latest versions, I realized that the kernel was able to read by itself the corresponding microcode on boot, with no need of microcode-ctl (which, indeed, does not provide the init script any more due that). So, after some research, I indicated microcode-data it had to generate the initramfs. Once I changed grub accordingly, I restarted the system but the kernel was unable to find the firmware. Reading the man page of iucode_tool, and the provided examples, I was able to create an initramfs file using this command: iucode_tool --write-earlyfw=/tmp/early.cpio /lib/firmware/intel-ucode so initramfs's layout was what kernel was expecting. Reproducible: Always Steps to Reproduce: 1. Update to sys-apps/microcode-ctl and sys-apps/microcode-data to 1.28-r1 and 20150121-r1 on a computer with an Intel processor, using initramfs USE flag on the last package 2. Use a kernel with microcode module static. Change GRUB configuration in order to use that kernel and the generated initramfs on system boot 3. Reboot the system using the previous setup, and check on dmesg and /proc/cpuinfo that microcode was neither read from initramfs nor updated on boot Actual Results: initramfs generated by sys-apps/microcode-data seems to not provide the microcode files in the subdirectories the microcode kernel module and hotplug subsystem expects. Expected Results: initramfs generated by sys-apps/microcode-data works
José: Do you have an existing initramfs that you are combining with the microcode initramfs or is that your only initramfs?
I've made a tweaked ebuild that might address your issue. You can test it by grabbing a copy from https://github.com/cardoe/gentoo/commit/9f094dcd2e635fe00d936b6a8538179aa9404ec3
please attach your kernel config. the early microcode loader does not look for split ucode files, only the kernel/x86/microcode/GenuineIntel.bin file (which is what the generated cpio includes). you can see this in the documentation: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/x86/early-microcode.txt?id=v4.1 as well as the loader itself: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/x86/kernel/cpu/microcode/intel_early.c?id=v4.1 the loader falls back to the split ucode files only if the combined one is not found in the cpio, and it only looks at built-in firmware, so having it in the cpio still wouldn't help. see the scan_microcode function for details.
(In reply to Doug Goldstein from comment #1) > José: Do you have an existing initramfs that you are combining with the > microcode initramfs or is that your only initramfs? Doug: It is my only initramfs
Created attachment 410842 [details] My current .config file (modified at 2015-08-24) This is the .config which I'm using for sys-kernel/gentoo-sources-4.1.6 compilation
(In reply to SpanKY from comment #3) > please attach your kernel config. the early microcode loader does not look > for split ucode files, only the kernel/x86/microcode/GenuineIntel.bin file > (which is what the generated cpio includes). > > you can see this in the documentation: > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/ > Documentation/x86/early-microcode.txt?id=v4.1 > > as well as the loader itself: > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/ > x86/kernel/cpu/microcode/intel_early.c?id=v4.1 > > the loader falls back to the split ucode files only if the combined one is > not found in the cpio, and it only looks at built-in firmware, so having it > in the cpio still wouldn't help. see the scan_microcode function for > details. I have just added my current .config file. BTW, I have just also realized that, when I tried the cpio archive generated by the package, I didn't try a copy of the "raw" version, but a bzip2 compressed one (I enabled CONFIG_RD_BZIP2=y in my .config files years ago). And also, I have been inspecting both the generated cpio archive and the generated working one. As their internal directory topology is the same, I guess the problem could be that initrd/initramfs machinery related to bzip2 decompression silently failed in some step. In any case I'll try with the "raw" version of the cpio this evening.
(In reply to Doug Goldstein from comment #2) > I've made a tweaked ebuild that might address your issue. You can test it by > grabbing a copy from > https://github.com/cardoe/gentoo/commit/ > 9f094dcd2e635fe00d936b6a8538179aa9404ec3 Nice tweak! It runs just the command I ran by hand to generate the working initramfs
The uncompressed, original version of microcode.cpio, generated by the ebuild, worked. So, the problem with the compressed version is not on the generated cpio. Sorry for the inconvenience, José María (In reply to José María Fernández González from comment #6) > (In reply to SpanKY from comment #3) > > please attach your kernel config. the early microcode loader does not look > > for split ucode files, only the kernel/x86/microcode/GenuineIntel.bin file > > (which is what the generated cpio includes). > > > > you can see this in the documentation: > > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/ > > Documentation/x86/early-microcode.txt?id=v4.1 > > > > as well as the loader itself: > > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/ > > x86/kernel/cpu/microcode/intel_early.c?id=v4.1 > > > > the loader falls back to the split ucode files only if the combined one is > > not found in the cpio, and it only looks at built-in firmware, so having it > > in the cpio still wouldn't help. see the scan_microcode function for > > details. > > I have just added my current .config file. > > BTW, I have just also realized that, when I tried the cpio archive generated > by the package, I didn't try a copy of the "raw" version, but a bzip2 > compressed one (I enabled CONFIG_RD_BZIP2=y in my .config files years ago). > > And also, I have been inspecting both the generated cpio archive and the > generated working one. As their internal directory topology is the same, I > guess the problem could be that initrd/initramfs machinery related to bzip2 > decompression silently failed in some step. > > In any case I'll try with the "raw" version of the cpio this evening.
