You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!

Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.

If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.

Having a problem logging in? Please visit this page to clear all LQ-related cookies.

Introduction to Linux - A Hands on Guide

This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.

The simplest way to append the microcode to an initrd is to use the /etc/mkinitrd.conf. My previous post, (post #4 of this thread) simplifies the process by far. I think that this method should be the recommended way to apply the microcode to a initrd because its the simplest and most fool proof method for newbies and advanced users alike. However, I do realize everyone has their own way of doing things but something is getting lost in translation. Remember, K.I.S.S. principle.

Using the 'cat' command isn't necessary to do any of this. Pat and team simplified the process for us with the mkinitrd.conf. A wrapper script for mkinitrd_command_generator.sh isn't necessary either if you use the mkinitrd.conf.

One advantage of making the cpio image file from processor microcode file is that you end up with ramfs file having size ~24k, so much less compared to the file with 1.5M size that iucode_tool produces using the microcode.dat file

One advantage of making the cpio image file from processor microcode file is that you end up with ramfs file having size ~24k, so much less compared to the file with 1.5M size that iucode_tool produces using the microcode.dat file

The initrd's allocated memory is usually discarded after switching the root. So, does not matter even the iucode_tool produce a 15MB sized thing.

Anyway, both sizes are laughable considering your capitalist sizes of memories, I heard that around 64GB is a minimum and the greedy ones go 256GB.

One advantage of making the cpio image file from processor microcode file is that you end up with ramfs file having size ~24k, so much less compared to the file with 1.5M size that iucode_tool produces using the microcode.dat file

iucode_tool -S option will do that for you. No need to manually figure out which file you need to use:/usr/sbin/iucode_tool -S --write-earlyfw=intel-ucode-local.cpio /lib/firmware/intel-ucode/

I remove the obsolete microcode.dat file from the package when I build it.

You can see that I've got two initrd's for the 4.4.110 kernel, one with the microcode. This is on a LVM/LUKS Slackware64 14.2 multilib install.

To run in forward sequence the steps taken
1. sboinstall iucode_tool from SBo
2. pulled the SBo of intel-microcode. Modified with emacs to point to 20180108 Intel file and then build and upgradepkg, since previously had sboinstall intel-microcode which used 20171117.
3. verified date/time of /boot/intel-ucode.cpio was same as build date/time of the intel-microcode run in previous step.
4. cat /boot/intel-ucode.cpio /boot/initrd-custom-4.4.110.gz > /boot/initrd-custom-4.4.110_ucode.gz
5. using emacs modified lilo.conf to add proper stanza pointing to /boot/initrd-custom-4.4.110_ucode.gz
6. execute lilo and confirmed output of Slak44110+ is added and no error codes generated.
7. rebooted

This is reflecting the original ucode level that was present before the intel-microcode SBo install.

So I'm thinking that nothing was loaded. But maybe this simply indicates that no revisions are available to that CPU processor which would be consistent with Intel's statement that only CPU's from past five years will be available this week and all other processors hopefully by end of January.

The simplest way to append the microcode to an initrd is to use the /etc/mkinitrd.conf. My previous post, (post #4 of this thread) simplifies the process by far. I think that this method should be the recommended way to apply the microcode to a initrd because its the simplest and most fool proof method for newbies and advanced users alike. However, I do realize everyone has their own way of doing things but something is getting lost in translation. Remember, K.I.S.S. principle.

Using the 'cat' command isn't necessary to do any of this. Pat and team simplified the process for us with the mkinitrd.conf. A wrapper script for mkinitrd_command_generator.sh isn't necessary either if you use the mkinitrd.conf.

I agree with you, using the mkinitrd.conf file seems like the right way to do this. Just look at the steps I went through, but the mkinitrd still only works if you've used the intel-microcode slackbuild and have the /boot/intel-ucode.cpio. Also I've always used AlienBob's initrd generator script so I can add the LVM/LUKS, hibernation swap flag and have multiple initrd's in order to fall back if the new one fails. So I have to try the suggestion and see if it produces a different result.