I extended the ebuild to only install suitable/applicable microcode instead of all available microcode by adding the optional USE flag 'scan-system'. The new flag affects both install methods (cpio archive, split ucode). Basis for the modifications was the latest available ebuild (sys-firmware/intel-microcode-20171117_p20171215). Changes: - add USE flag 'scan-system' - add dependency for new flag - add code to src_compile and src_install to handle new flag - change install location of cpio archive (*) - add some helpful elog messages - add flag description to metadata.xml (*) The current install location '/lib/firmware/microcode.cpio' is somewhat misleading, as it could hold any sort of microcode. Thus, I changed the location to '/lib/firmware/intel-ucode/initramfs.cpio', which gives some hints
Created attachment 513642 [details] intel-microcode-20171117_p20171215.ebuild Full modified ebuild
Created attachment 513644 [details] metadata.xml Full modified metadata.xml
Created attachment 513646 [details, diff] Unified diff patch Unified diff patch for both ebuild and metadata.xml
Sample output for my Intel-driven system: * Messages for package sys-firmware/intel-microcode-20171117_p20171215: * Signature of detected processor(s): 0x00020652 * Suitable microcode bundle: 41 (intel-ucode/06-25-02) * Suitable microcode bundle: 42 (intel-ucode/06-25-05) * * CPIO archive was installed to '/lib/firmware/intel-ucode/initramfs.cpio' * This archive needs to be prepended to an existing initramfs image: * # cat /lib/firmware/intel-ucode/initramfs.cpio existing-image > combined-image * * Split binary ucode files were installed to '/lib/firmware/intel-ucode' * * Please refer to the Gentoo Wiki for more detailed information: * https://wiki.gentoo.org/wiki/Intel_microcode Resulting contents of '/lib/firmware/intel-ucode': total 32K drwxr-xr-x 2 root root 4,0K Jan 7 16:26 . drwxr-xr-x 6 root root 4,0K Jan 6 18:57 .. -rw-r--r-- 1 root root 8,0K Jan 7 16:26 06-25-02 -rw-r--r-- 1 root root 3,0K Jan 7 16:26 06-25-05 -rw-r--r-- 1 root root 12K Jan 7 16:26 initramfs.cpio
That looks like a lot of complexity for very little benefit.
I'd say it is reasonable complexity, and the real benefit, aside from saving a little space, is telling the user which microcode is the right one for his system. Other bug reports on this package show that people have a hard time figuring out what microcode to use and how to use it - both is addressed by the changes. That was also why I created this in the first place.
(In reply to Maxxim from comment #6) > I'd say it is reasonable complexity, and the real benefit, aside from saving > a little space, is telling the user which microcode is the right one for his > system. > > Other bug reports on this package show that people have a hard time figuring > out what microcode to use and how to use it - both is addressed by the > changes. Users don't *need* to figure that out -- the iucode_tool does it for you when you run it, and initramfs generators just include all of the available files.
(In reply to Mike Gilbert from comment #7) > Users don't *need* to figure that out -- the iucode_tool does it for you > when you run it, and initramfs generators just include all of the available > files. And that's exactly what the ebuild does. So what are we talking about? Please see bug #624846 - it was even a dev pointing out that the ebuild should do more than it currently does. Perhaps you look at it as someone who knows what microcodes are, how they work and what to do with them. I'd say that's hardly something every other user knows.
(In reply to Maxxim from comment #8) > (In reply to Mike Gilbert from comment #7) > > Users don't *need* to figure that out -- the iucode_tool does it for you > > when you run it, and initramfs generators just include all of the available > > files. > > And that's exactly what the ebuild does. So what are we talking about? The ebuild should continue just install all of the available files -- there's no need to filter them at build time. > Please see bug #624846 - it was even a dev pointing out that the ebuild > should do more than it currently does. > > Perhaps you look at it as someone who knows what microcodes are, how they > work and what to do with them. I'd say that's hardly something every other > user knows. Building the microcode into your kernel is not a great solution. That's basically the only scenario where you might need to figure out which files are necessary for your target CPU, though including all of them would probably work just fine. The best supported way to load microcode is to generate an initramfs using a suitable tool (genkernel or dracut). The wiki article below details several alternative methods. There are several different ways to accomplish essentially the same thing. https://wiki.gentoo.org/wiki/Intel_microcode
sys-firmware/intel-microcode[initramfs] creates /lib/firmware/microcode.cpio which can be used in a bootloader. I was thinking about the same (add a use flag which will call iucode_tools with "-S" parameter) when I touched this package. At least genkernel for example will include all AMD _and_ all Intel firmwares... we are talking about ~1.8MB.
(In reply to Mike Gilbert from comment #9) > Building the microcode into your kernel is not a great solution. That's > basically the only scenario where you might need to figure out which files > are necessary for your target CPU, though including all of them would > probably work just fine. > > The best supported way to load microcode is to generate an initramfs using a > suitable tool (genkernel or dracut). > > The wiki article below details several alternative methods. There are > several different ways to accomplish essentially the same thing. > > https://wiki.gentoo.org/wiki/Intel_microcode You're preaching to the choir here. *I* know all that, I read the whole article half a year ago when I first wanted to add microcode patching to my systems. I wouldn't have been able to modify the ebuild without the knowledge. After I had figured it out, I thought 'man, this is more complex than it has to be'. See, just because *I* know all about it, I don't assume everyone else does. Let me explain something: I've been using Gentoo since 2002, back in the days where a simple world upgrade could easily render one's system unusable, when there was little documentation and one basically already had to be a Linux expert to even use Gentoo. Gentoo has since come a long way, and although it still is and probably always will be an expert distro, I fail to understand why one shouldn't make other users' lives easier when all it takes are 30-40 lines of code (that's what we're talking about here, already including message-only lines). About the size of intel-microcode: yes, it's only a few megs, but then I never said that this modification is about saving storage space. Isn't one of the major advantages of Gentoo that it's thin and users can tweak it the way they like (at least that's what *I* like about it the most)? This optional USE flag supports exactly that. Also, it may be a few megs now, but there's now way of telling it'll stay that way in the future, so why not take the necessary steps now. And, last but not least: we're talking about *one* package here. If every package would just install a few megs of stuff that has no use, you'll end up with a system quite larger than necessary.
(In reply to Mike Gilbert from comment #9) > Building the microcode into your kernel is not a great solution. That's > basically the only scenario where you might need to figure out which files > are necessary for your target CPU, though including all of them would > probably work just fine. One last thing to add: that may be you opinion, but the wiki article tells users that this is the *preferred* way of doing it (see https://wiki.gentoo.org/wiki/Intel_microcode#New_method_without_initram-fs.2Fdisk)
(In reply to Maxxim from comment #12) > (In reply to Mike Gilbert from comment #9) > > Building the microcode into your kernel is not a great solution. That's > > basically the only scenario where you might need to figure out which files > > are necessary for your target CPU, though including all of them would > > probably work just fine. > One last thing to add: that may be you opinion, but the wiki article tells > users that this is the *preferred* way of doing it (see > https://wiki.gentoo.org/wiki/Intel_microcode#New_method_without_initram-fs. > 2Fdisk) that in turn is opinion of user Janos666 https://wiki.gentoo.org/index.php?title=Intel_microcode&type=revision&diff=551478&oldid=539942
I am still opposed to this patch, but I will defer to other base-system members before closing the bug.
I'll take a compromise: - I don't want all the iucode_tool complexity in the ebuild. - But I will allow a simpler selection method to install a subset of microcode, maybe by the same filename fragment like passed to the kernel?
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=de233b906ee278949e0e140d42d44f087f76d395 commit de233b906ee278949e0e140d42d44f087f76d395 Author: Robin H. Johnson <robbat2@gentoo.org> AuthorDate: 2018-01-10 21:57:09 +0000 Commit: Robin H. Johnson <robbat2@gentoo.org> CommitDate: 2018-01-10 22:13:35 +0000 sys-firmware/intel-microcode: rewrite to use iucode_tool. - Use the Intel upstream 'iucode_tool' to process all of the input microcode, from both the text-format microcode.dat file and other inputs, then generate a clean set of split outputs & optionally also initramfs output. - Allows easy inclusion of any future split-ucode releases for single CPUs. - No longer uses intel-microcode2ucode.c from $FILESDIR. - Expert users can use the new MICROCODE_SIGNATURES variable to install only a subset of microcodes on their system, as requested by bug 643786. - Avoids accidently bloated split-ucode files per bug #644100. - USE=monolithic is no longer supported, please see iucode_tool for any fallback. - USE=initramfs now writes to /boot/intel-uc.img (8.3-safe naming). Fixes: https://bugs.gentoo.org/643786 Fixes: https://bugs.gentoo.org/644100 Package-Manager: Portage-2.3.16, Repoman-2.3.6 Signed-off-by: Robin H. Johnson <robbat2@gentoo.org> .../intel-microcode-20180108-r1.ebuild | 78 ++++++++++++++++++++++ 1 file changed, 78 insertions(+)
