[SOLVED] How to load new Intel microcode

bamunds · 01-05-2018, 10:51 PM

This thread started on the Latest Kernel release thread. https://www.linuxquestions.org/quest...14#post5802714 at post 505 and continues through post 518. To avoid duplication of helpful comments please read that thread at least for the posts listed.

NOTE this only address the microcode loading issue and not the full mitigation for Meltdown or Spectre threat.

It is for the purpose of helping me understand how to load my older Intel Pentium D 820 processor on a no-longer support emachine t5224. The platform is a full install of Slackware 64 14.2 with multilib and FVWM as primary WM.

iucode_tool version 2.2 is loaded from Slackbuilds.org.
The man page is a great and required read to understand the tool.
This tool was loaded to discover processors signature in hopes of seeing if Intel had new microcode to overcome the Meltdown and Spectre threats.

This lead to a coversation about how Intels instructions for loading the 20171117 microcode, which does NOT have the newest microcode to address Meltdown or Spectre, but was important to read and understand what is offered, can be used to load microcode.

The installation is using LVM/LUKS and therefore requires an initrd. The initrd is re-created with each new kernel upgrade. Kernel installs are updated to either Pat's latest official release or kernel.org latest release every 2 months, which ever comes first. Currently the platform is on 4.4.106 with 4.4.88 (Pat's latest official release) as the backup kernel.

The iucode_tool man page indicates that much has changed with microcode loading as of Linux kernel 4.4. The driver is now always loaded due to suspend and resume. Updating microcode earlier is safer and can should only be done at boot. It requires an uncompressed intramfs image in /kernel/x86/microcode/GenuineIntel.bin and must be the first initramfs called early initramfs. Read the man page of iucode_tool for Linux Notes section to get all the requirements.

What I need help understanding is how the iucode_tool inter works with the Intel Linux-microcode file.
I suspect that I have to unpack the file. Then use the intel_microcode SBo package https://slackbuilds.org/repository/1...tel-microcode/ to build a microcode from the /intel-ucode tar directory.

This third tool now will "2) write the microcodes to an early initramfs archive: /boot/intel-ucode.cpio" which then has to be PRE-pended to the initrd. So as Darth Vader indicated in the in the other thread a way to do that with:

Quote:

Originally Posted by Darth Vader

@bamunds

My solution to load the Intel microcode:

Code:

# Create the base initrd.
mkinitrd -c -k "$KVERSION" -r "$ROOTDEV" -f "$ROOTFS" -m "$KMODULES" -h "$SWAPDEV" -u -M -w 5 -o /boot/initrd-${KVERSION}.gz

# Concatenate the intel-ucode.cpio and base initrd on the final initrd.
cat /boot/intel-ucode.cpio /boot/initrd-${KVERSION}.gz > /boot/initrd-${KVERSION}_ucode.gz

# Symlink the final initrd.
ln -sf initrd-${KVERSION}_ucode.gz initrd.gz

I use the SBo variant of Intel microcode, for now.

Final question. What have I missed?
Will this actually then override the obsolete microcode on the CPU or only that part which is causing threats.
Until I try it I quess I won't know if it causes any other microcode changes that affect other parts of the system, like the HDD, Ethernet or the USB onboard reader to stop functioning. So this weekend I'll give it a try.
OH-- how to make a backup? I would think my backbup initrd for 4.4.88 should be ok since it won't load new microcode. Right?

Petri Kaukasoina · 01-06-2018, 03:48 AM

intel-microcode (20171117) from slackbuilds.org puts the microcode to /boot/intel-ucode.cpio. If you use generic kernel + initrd, rename /etc/mkinitrd.conf.sample to /etc/mkinitrd.conf and uncomment line with MICROCODE_ARCH="/boot/intel-ucode.cpio". Then running mkinitrd will automatically include the microcode to the initrd. (This was added as a patch in 14.2, Jun 29 2017.)

You can make a backup lilo entry with the old initrd.

(Or, if you don't use initrd, add ' initrd=/boot/intel-ucode.cpio' in lilo.conf to load the microcode directly instead of the real initrd.)

Try

Code:

grep microcode /proc/cpuinfo

before and after to see if the microcode version has changed.

This will not do anything to your ethernet firmware etc.

zakame · 01-06-2018, 06:02 AM

I just usually do this:

Code:

# install iucode_tool, install/update intel-microcode packages from SBo, then
/usr/share/mkinitrd/mkinitrd_command_generator.sh --run /boot/vmlinuz-generic -a '-P /boot/intel-ucode.cpio' | sh

This will generate a combined /boot/initrd.gz from the selected kernel modules needed for boot + the intel-ucode.cpio.

Then proceed to use the generated initrd as usual on your preferred bootloader.

In my case, I automate this in /usr/libexec/slackpkg/functions.d/z-lookkernel.sh for kernel upgrades.

mralk3 · 01-06-2018, 03:12 PM

A quick rundown... I posted this some time ago in another thread, I believe, but cannot find it now.

EDIT: IMPORTANT: You must install iucode_tool from SBo, and immediately after you install that, install intel-microcode. If you do not first do this, then /boot/intel-ucode.cpio will not be present, and the following directions do not work.

Here is what my mkinitrd.conf looks like with the intel microcode in use:

Code:

#
# See "man mkinitrd.conf" for details on the syntax of this file
#
SOURCE_TREE="/boot/initrd-tree"
CLEAR_TREE="1"
OUTPUT_IMAGE="/boot/initrd.gz"
#KERNEL_VERSION="$(uname -r)"
KERNEL_VERSION="4.14.11"
KEYMAP="us"
MODULE_LIST="jbd2:mbcache:ext4:i915"
ROOTDEV="/dev/sda2"
ROOTFS="ext4"
RESUMEDEV="/dev/sda1"
UDEV="1"
MICROCODE_ARCH="/boot/intel-ucode.cpio"
WAIT="1"

And here is what the relevant part of my lilo.conf looks like:

Code:

image = /boot/vmlinuz-generic
  initrd = /boot/initrd.gz
  root = /dev/sda2
  label = Generic
  read-only
image = /boot/vmlinuz
  initrd = /boot/intel-ucode.cpio
  root = /dev/sda2
  label = Huge 
  read-only

I am running Slackware64-current. When there is a kernel upgrade I update KERNEL_VERSION in my mkinitrd.conf and then I run as root:

Code:

mkinitrd -F -c && lilo -v

This allows kernel-generic and kernel-huge to use the latest intel micorcode, assuming I have kept it up to date from ponce's SBo-git repository..

To check if everything is working, a reboot is necessary, and then:

Code:

root@localhost:~# grep microcode /var/log/dmesg 
[    0.000000] microcode: microcode updated early to revision 0x22, date = 2017-01-27
[    3.817920] microcode: sig=0x306c3, pf=0x10, revision=0x22
[    3.818348] microcode: Microcode Update Driver: v2.2.

--
This is my processor:

Code:

root@localhost:~# lscpu | grep "Model name"
Model name:          Intel(R) Core(TM) i7-4810MQ CPU @ 2.80GHz

bamunds · 01-06-2018, 05:07 PM

Quote:

Originally Posted by Petri Kaukasoina

intel-microcode (20171117) from slackbuilds.org puts the microcode to /boot/intel-ucode.cpio. If you use generic kernel + initrd, rename /etc/mkinitrd.conf.sample to /etc/mkinitrd.conf and uncomment line with MICROCODE_ARCH="/boot/intel-ucode.cpio". Then running mkinitrd will automatically include the microcode to the initrd. (This was added as a patch in 14.2, Jun 29 2017.)

I've never created a mkinitrd.conf so I'll check the man page before proceeding.
To clarify you are referring to mkinitrd-1.4.10_x86_64-1_slack14.2 was patched, or at least that is where I found the patch in the changelog. It appears from ls /var/log/packages, that I did install that update. So next is to read the man page. I'm not clear why you qualified this for "generic kernel", wouldn't it work with any kernel referenced in the .conf file? Also what is the effect if using the mkinitrd_command_generator.sh? From reading the shell script still I think it use mkinitrd to generate the output, but I want to verify that it isn't going to bypass the /boot/intel-cpio if one is also using a mkinitrd.conf with that setting set?

Quote:

Originally Posted by Petri Kaukasoina

You can make a backup lilo entry with the old initrd.

Already have done this for safety in past. Thanks.

Quote:

Originally Posted by Petri Kaukasoina

(Or, if you don't use initrd, add ' initrd=/boot/intel-ucode.cpio' in lilo.conf to load the microcode directly instead of the real initrd.)

This confuses me. I do use a initrd because of LVM/LUKS, but I still want to understand if you are referring to the same lilo.conf entry that mralk3 suggested in post 4?

Thanks for the hints to make this easier going forward.

Darth Vader · 01-06-2018, 05:25 PM

Look, if you concatenate several initrds, the kernel is smart enough to find out every one and load them.

/boot/intel-ucode.cpio is just an initrd which contains these Intel firmware.

So, you concatenate it to your own initrd, then on final, the kernel will find them properly.

bamunds · 01-06-2018, 05:32 PM

Quote:

Originally Posted by mralk3

A quick rundown... I posted this some time ago in another thread, I believe, but cannot find it now.

Thank you for posting it again.

Quote:

Originally Posted by mralk3

Here is what my mkinitrd.conf looks like with the intel microcode in use:

Code:

#
# See "man mkinitrd.conf" for details on the syntax of this file
#
SOURCE_TREE="/boot/initrd-tree"
CLEAR_TREE="1"
OUTPUT_IMAGE="/boot/initrd.gz"
#KERNEL_VERSION="$(uname -r)"
KERNEL_VERSION="4.14.11"
KEYMAP="us"
MODULE_LIST="jbd2:mbcache:ext4:i915"
ROOTDEV="/dev/sda2"
ROOTFS="ext4"
RESUMEDEV="/dev/sda1"
UDEV="1"
MICROCODE_ARCH="/boot/intel-ucode.cpio"
WAIT="1"

I plan to read the man page for mkinitrd.conf to understand all the possible inputs. If I use the .conf do I need to list all the modules which are needed in the module_list entry? Is there a line length limit and does "" accept more entries on next line?

Quote:

Originally Posted by mralk3

And here is what the relevant part of my lilo.conf looks like:

Code:

image = /boot/vmlinuz-generic
  initrd = /boot/initrd.gz
  root = /dev/sda2
  label = Generic
  read-only
image = /boot/vmlinuz
  initrd = /boot/intel-ucode.cpio
  root = /dev/sda2
  label = Huge 
  read-only

This doesn't make any sense. The intel-ucode.cpio needs to be loaded before any other part of the initrd per documents on using Intel microcode and the man page for iucode_tool. Why does your "Huge" only point to the intel-ucode.cpio, doesn't it need a standard initrd.gz?

Quote:

Originally Posted by mralk3

I am running Slackware64-current. When there is a kernel upgrade I update KERNEL_VERSION in my mkinitrd.conf and then I run as root:

Code:

mkinitrd -F -c && lilo -v

This allows kernel-generic and kernel-huge to use the latest intel micorcode, assuming I have kept it up to date from ponce's SBo-git repository..

To check if everything is working, a reboot is necessary, and then:

Code:

root@localhost:~# grep microcode /var/log/dmesg 
[    0.000000] microcode: microcode updated early to revision 0x22, date = 2017-01-27
[    3.817920] microcode: sig=0x306c3, pf=0x10, revision=0x22
[    3.818348] microcode: Microcode Update Driver: v2.2.

--
This is my processor:

Code:

root@localhost:~# lscpu | grep "Model name"
Model name:          Intel(R) Core(TM) i7-4810MQ CPU @ 2.80GHz

Thanks for the suggestions. I'll do some more reading on the mkinitrd.conf configuration.
Here are my current microcode results.

Code:

root@Hicrest1:~# lscpu | grep "Model name"
Model name:            Intel(R) Pentium(R) D CPU 2.80GHz
root@Hicrest1:~# grep microcode /var/log/dmesg
[    0.731704] microcode: CPU0 sig=0xf47, pf=0x10, revision=0x3
[    0.731843] microcode: CPU1 sig=0xf47, pf=0x10, revision=0x3
[    0.732038] microcode: Microcode Update Driver: v2.01 <tigran@aivazian.fsnet.co.uk>, Peter Oruba
root@Hicrest1:~# grep microcode /proc/cpuinfo
microcode       : 0x3
microcode       : 0x3

It appears the driver was updated in 14.2 is still at v2.01, and currently I don't have an early update being applied. I appreciate the examples of what it will look like after getting the microcode upgraded. If all my hardware is currently running correctly, does it make sense to upgrade the microcode to the 20171117 version? I suppose one reason might be to see if it works before waiting for the latest with the Meltdown fix.

Ultimately my understanding is that both microcode and kernel code need to be upgraded to resolve both the Meltdown and maybe Spectre threats. SO I'm waiting on the kernel correction for 4.4 line and will probably have to wait for the microcode too, if Intel even goes back to my older CPU. For now simply working to get this all work out and understood. Which is exactly what all the responses are helping me do. Thanks everyone, I keep learning and learning. More suggestions or corrections to my understanding are appreciated.

bamunds · 01-06-2018, 05:47 PM

Quote:

Originally Posted by Darth Vader

...the kernel is smart enough to find out every one and load them.

I don't want to take your "look" the wrong way but this statement doesn't fit logic of lilo. Lilo tells the boot loader which initrd you want to load and ignores the other initrd files of the lilo.conf. The concatenate of initrd's would have to be IN the same initrd as you select for the bootloader to load. Yes or no?

Quote:

Originally Posted by Darth Vader

/boot/intel-ucode.cpio is just an initrd which contains these Intel firmware.

So, you concatenate it to your own initrd, then on final, the kernel will find them properly.

Which I thought was the reason you suggested to make the initrd and then

Code:

 # cat /boot/intel-ucode.cpio /boot/initrd-kernelxxxxx.gz > /boot/initrd.gz

Although I'm not sure this ensures that the intel-ucode is loaded first. Did you feel I misunderstood something from my responses to others? You maybe very familiar with your way, but it is new to me and I'm just learning and learning this new area of microcode and how to load latest Intel microcode to a old CPU. I'm seeking advice to simply be careful and not bork my system.

Darth Vader · 01-06-2018, 05:57 PM

From the lilo POV, that /boot/initrd.gz file is just an initrd (it have no clue about content), which it will map to kernel, when it is properly specified.

Right this concatenated file which contains the both initrd, you should specify to lilo.

And yes, the kernel will find and load first the firmware one.

BTW, SYSLINUX is smarter than LILO, on this aspect, because you can specify multiple initrd files.

PS. And please forgive my English, I am not native speaker.

bamunds · 01-06-2018, 11:59 PM

@kjhambrick
Thanks again for your comments and example output in the Latest Kernel thread. Can you tell me which method of microcode updating you used and if you are using an initrd or not, per my question in #518?

You examples of how dmesg will display the updated code are very helpful in your #517 post on the other thread. I hope to use the latest kernel 4.4.110, which implements some Kaiser solutions, along with the latest 20171117 microcode and now I'll know what to pull from dmesg and what result to check to verify the task completed correctly.

kjhambrick · 01-07-2018, 09:06 AM

Quote:

Originally Posted by bamunds

@kjhambrick
Thanks again for your comments and example output in the Latest Kernel thread. Can you tell me which method of microcode updating you used and if you are using an initrd or not, per my question in #518?

You examples of how dmesg will display the updated code are very helpful in your #517 post on the other thread. I hope to use the latest kernel 4.4.110, which implements some Kaiser solutions, along with the latest 20171117 microcode and now I'll know what to pull from dmesg and what result to check to verify the task completed correctly.

<<cut-n-pasted from the latest kernel release thread>>

Quote:

Originally Posted by bamunds

Yes it did help. Especially helpful are you microcode dmesg outputs showing the microcode dates of your CPU which were loaded. However I am confused about which method you used for updating the microcode. Are you saying you're updating the microcode.dat (now deprecated) or are you using the iucode_tool to build the /boot/intel-ucode.cpio and then cat'ing it into a initrd.gz? Can the updating comments please be taken to the separate thread title "How to update Intel microcode" at https://www.linuxquestions.org/quest...de-4175621053/. Thanks.

bamunds --

I use the iucode_tool and the /boot/intel-ucode.cpio initrd file.

So that I don't bork things when I install a new kernel, I wrote a little wrapper script to write a script that invokes Alien Bob's /usr/share/mkinitrd/mkinitrd_command_generator.sh and then prepends the /boot/intel-ucode.cpio initrd file into the resulting initrd for the Generic Kernel.

The script and a typical session is below my .sig if you want it ( the script is .do-mkinitrd_command_generator.sh ).

When all is said and done, I end up with two initrd files, one for Generic Kernel without the intel-ucode.cpio file and one with the intel-ucode file.

Note that I 'defanged' the install step -- .do-mkinitrd_command_generator.sh prints the cp command but does not execute it.

I always cut-n-paste the cp command after I look at the output ...

Note that the OutDir Varb should be edited for your tastes and system,

Anyhow ... Don't forget to edit /etc/lilo.conf ( or elilo or grub ) after installing the new initrd file in /boot/ !

These are the stanzas for the 4.4.110 Generic and Huge Kernels along with a reminder for me.

Code:

#
######################################################################
# NOTE:  HUGE Kernel initrd = /boot/intel-ucode.cpio for ucode patch #
######################################################################
#
image    = /boot/vmlinuz-generic-4.4.110.kjh
  root   = /dev/sda3
  initrd = /boot/initrd-generic-4.4.110.kjh-ucode.gz
  label  = Linux44110G.kjh
  read-only
image    = /boot/vmlinuz-huge-4.4.110.kjh
  root   = /dev/sda3
  initrd = /boot/intel-ucode.cpio
  label  = Linux44110H.kjh
  read-only

Normally the Huge Kernel needs no initrd file.

However it does need one to load the intel microcode.

HTH.

-- kjh

I name my some of my scripts with a leading dot so that I can clean the directory with an `rm *` but not touch the scripts and configs.

.do-mkinitrd_command_generator.sh is one such script because I configured it to write the new initrd files in the `dirname $0` directory.

This is .do-mkinitrd_command_generator.sh

Code:

#!/bin/sh
#
WriteIt=0
DoUCode=1
UCodeFile="/boot/intel-ucode.cpio"

OutDir="/root/tmp/update-logs/initrd"        # edit me !  This is where stuff is written

[ "$1" = "-w" ] && WriteIt=1 && shift 

[ $# -lt 1 ] && echo "usage:  `basename $0` [ -w ] KernelVersion" >&2 && exit 1

[ "$DoUCode" = "1" -a ! -f "$UCodeFile" ] && echo "cannot find $UCodeFile ... ABORT" && exit 2

Version="$1"

UCodeInit="initrd-generic-$Version-ucode.gz"

[ ! -f "/boot/vmlinuz-generic-$Version" ] && echo "cannot find a generic kernel version $Version" >&2 && exit 3

/usr/share/mkinitrd/mkinitrd_command_generator.sh \
   -k $Version \
   -a          \
   "-o $OutDir/initrd-generic-$Version.gz"    |
   if [ "$WriteIt" != "1" ]
   then
      cat
   else
      cat > "do-mkinitrd-$Version.sh"
   fi

   if [ "$DoUCode" = "1" ]
   then
      echo "#"
      echo "# prepending the latest intel microcode as $UCodeInit"
      echo "#"
      echo "cat $UCodeFile $OutDir/initrd-generic-$Version.gz > $OutDir/$UCodeInit"
      echo "#"
      echo "echo \"# all done.\""
      echo "ls -la $OutDir/initrd-generic-$Version.gz $OutDir/$UCodeInit"
      echo "echo \"# \""
      echo "echo \"cp -vp $OutDir/initrd-generic-$Version.gz $OutDir/$UCodeInit /boot/\""
    # echo "echo \"# \""
    # echo "echo \"# check around ... if all went well, invoke the following cp command.\""
    # echo "echo \"# \""
    # echo "echo \"# cp -p $OutDir/initrd-generic-$Version.gz $OutDir/$UCodeInit /boot/\""
   fi |
   if [ "$WriteIt" != "1" ]
   then
      cat
   else
      cat >> "do-mkinitrd-$Version.sh"
      chmod 700 "do-mkinitrd-$Version.sh"

      echo "#"
      echo "# do-mkinitrd-$Version.sh is ready to run"
   fi

So ... after installing a new kernel and before I run lilo, I make a new initrd including the intel-ucode.cpio file.

My newest kernel is 4.4.110.kjh ...

Here is a session.

Code:

cd /root/tmp/update-logs/initrd
sh .do-mkinitrd_command_generator.sh -w 4.4.110.kjh
#
# do-mkinitrd-4.4.110.kjh.sh is ready to run

The .do-mkinitrd_command_generator.sh -w 4.4.110.kjh` command wrote a script to create two initrd files:

1. a Generic initrd that does not include the intel-ucode.cpio file
2. an initrd that includes the intel-ucode.cpio file and the Generic initrd ( #1 )

The generated script ( do-mkinitrd-4.4.110.kjh.sh ) is below ...

Continuing ... run the generated script ...

Code:

# sh do-mkinitrd-4.4.110.kjh.sh

OK: /lib/modules/4.4.110.kjh/kernel/drivers/usb/host/xhci-hcd.ko added.
OK: /lib/modules/4.4.110.kjh/kernel/drivers/usb/host/xhci-pci.ko added.
:
<<snip a number of kernel module lines>>
:
OK: /lib/modules/4.4.110.kjh/kernel/fs/mbcache.ko added.
OK: /lib/modules/4.4.110.kjh/kernel/fs/ext4/ext4.ko added.
42762 blocks

/root/tmp/update-logs/initrd/initrd-generic-4.4.110.kjh.gz created.
Be sure to run lilo again if you use it.
# all done.
-rw-r--r-- 1 root root 9202493 Jan  7 07:43 /root/tmp/update-logs/initrd/initrd-generic-4.4.110.kjh-ucode.gz
-rw-r--r-- 1 root root 7615293 Jan  7 07:43 /root/tmp/update-logs/initrd/initrd-generic-4.4.110.kjh.gz
# 
cp -vp /root/tmp/update-logs/initrd/initrd-generic-4.4.110.kjh.gz /root/tmp/update-logs/initrd/initrd-generic-4.4.110.kjh-ucode.gz /boot/

The last line above ( cp -vp ... ) is the command that would copy the two initrd files into /boot/

Don't forget to install your initrd files before you run lilo !

this is the generated script that actually makes the two initrd files:

Code:

#
# mkinitrd_command_generator.sh revision 1.45
#
# This script will now make a recommendation about the command to use
# in case you require an initrd image to boot a kernel that does not
# have support for your storage or root filesystem built in
# (such as the Slackware 'generic' kernels').
# A suitable 'mkinitrd' command will be:

mkinitrd -c -k 4.4.110.kjh -f ext4 -r /dev/sda3 -m xhci-pci:ohci-pci:ehci-pci:xhci-hcd:uhci-hcd:ehci-hcd:hid:usbhid:i2c-hid:hid_generic:hid-cherry:hid-logitech:hid-logitech-dj:hid-logitech-hidpp:hid-lenovo:hid-microsoft:hid_multitouch:jbd2:mbcache:ext4 -u -o /root/tmp/update-logs/initrd/initrd-generic-4.4.110.kjh.gz
#
# prepending the latest intel microcode as initrd-generic-4.4.110.kjh-ucode.gz
#
cat /boot/intel-ucode.cpio /root/tmp/update-logs/initrd/initrd-generic-4.4.110.kjh.gz > /root/tmp/update-logs/initrd/initrd-generic-4.4.110.kjh-ucode.gz
#
echo "# all done."
ls -la /root/tmp/update-logs/initrd/initrd-generic-4.4.110.kjh.gz /root/tmp/update-logs/initrd/initrd-generic-4.4.110.kjh-ucode.gz
echo "# "
echo "cp -vp /root/tmp/update-logs/initrd/initrd-generic-4.4.110.kjh.gz /root/tmp/update-logs/initrd/initrd-generic-4.4.110.kjh-ucode.gz /boot/"

This is the directory where I do the deed ... needs to be cleaned again but because the script is a dot-file, cleanup is simply: `rm *`

Code:

# ls -la

total 114772
drwxr-xr-x 2 root root   12288 Jan  7 07:43 ./
drwxr-xr-x 6 root root    4096 Jan  5 10:24 ../
-rwxr-xr-x 1 root root    1689 Sep 27 05:22 .do-mkinitrd_command_generator.sh*
-rwx------ 1 root root    1198 Dec  9 17:18 do-mkinitrd-4.4.105.kjh.sh*
-rwx------ 1 root root    1198 Dec 17 04:59 do-mkinitrd-4.4.106.kjh.sh*
-rwx------ 1 root root    1198 Dec 21 13:10 do-mkinitrd-4.4.107.kjh.sh*
-rwx------ 1 root root    1198 Dec 25 12:54 do-mkinitrd-4.4.108.kjh.sh*
-rwx------ 1 root root    1198 Jan  2 15:02 do-mkinitrd-4.4.109.kjh.sh*
-rwx------ 1 root root    1198 Jan  7 07:42 do-mkinitrd-4.4.110.kjh.sh*
-rwx------ 1 root root    1241 Sep 16 05:54 do-mkinitrd-4.4.88.sh*
-rw-r--r-- 1 root root 9202097 Dec  9 17:18 initrd-generic-4.4.105.kjh-ucode.gz
-rw-r--r-- 1 root root 7614897 Dec  9 17:18 initrd-generic-4.4.105.kjh.gz
-rw-r--r-- 1 root root 9202048 Dec 17 04:59 initrd-generic-4.4.106.kjh-ucode.gz
-rw-r--r-- 1 root root 7614848 Dec 17 04:59 initrd-generic-4.4.106.kjh.gz
-rw-r--r-- 1 root root 9202505 Dec 21 13:10 initrd-generic-4.4.107.kjh-ucode.gz
-rw-r--r-- 1 root root 7615305 Dec 21 13:10 initrd-generic-4.4.107.kjh.gz
-rw-r--r-- 1 root root 9202496 Dec 25 12:54 initrd-generic-4.4.108.kjh-ucode.gz
-rw-r--r-- 1 root root 7615296 Dec 25 12:54 initrd-generic-4.4.108.kjh.gz
-rw-r--r-- 1 root root 9202522 Jan  2 15:02 initrd-generic-4.4.109.kjh-ucode.gz
-rw-r--r-- 1 root root 7615322 Jan  2 15:02 initrd-generic-4.4.109.kjh.gz
-rw-r--r-- 1 root root 9202493 Jan  7 07:43 initrd-generic-4.4.110.kjh-ucode.gz
-rw-r--r-- 1 root root 7615293 Jan  7 07:43 initrd-generic-4.4.110.kjh.gz
-rw-r--r-- 1 root root 8917615 Sep 16 05:54 initrd-generic-4.4.88-ucode.gz
-rw-r--r-- 1 root root 7614063 Sep 16 05:54 initrd-generic-4.4.88.gz

magicm · 01-07-2018, 09:35 AM

I just want to clarify (or correct) an impression that I have. If one sets up a mkinitrd.conf file which has an entry for MICROCODE_ARCH, I'm assuming that the output of mkinitrd -F will be what is to be specified in the lilo initrd entry (say for a standard Slackware 'generic' kernel).

For example, if there are entries
OUTPUT_IMAGE="/boot/initrd.gz"
and
MICROCODE_ARCH="/boot/intel-ucode.cpio"
I'm assuming that conceptually
cat /boot/intel-ucode.cpio {an internal form of initrd.gz} > /boot/initrd.gz

Well, (slight embarrassment); I actually decided to read the mkinitrd script, and my impressions is correct. But I figured I'd post this here in case anyone else was unclear about it.

bamunds · 01-08-2018, 12:12 AM

@kjhambrick, thank you for the great write-up and examples. I wasn't aware the huge kernel didn't need an initrd. I'm studying your script to see where I need to change it to allow me to use it every couple of months with the latest 4.4.x kernel, rather than with Pat's latest official release. I like the idea of scripts! Although I'm not a programmer I seem to be able to read and understand the logic of them, although the variables sometimes confuse me. Is there a reason you haven't used a mkinitrd.conf for some of the variables? Darth Vader suggested modifying that file to assure the intel-ucode.cpio is actually included in the initrd, which makes sense. I'll be working on this more tomorrow. Again thanks. Cheers

kjhambrick · 01-08-2018, 08:17 AM

Quote:

Originally Posted by bamunds

@kjhambrick, thank you for the great write-up and examples. I wasn't aware the huge kernel didn't need an initrd.

bamunds --

The HUGE Kernel does not need an initrd UNLESS you need to load the intel-ucode.cpio file or maybe some module that Pat did not compile into HUGE ...

I used to run HUGE because I was lazy ( no need for an initrd ) and because I was old and set in my ways

But since the Intel ME Bug and now that I need to load intel-ucode.cpio, I no longer run HUGE, I've gone GENERIC.

Quote:

I'm studying your script to see where I need to change it to allow me to use it every couple of months with the latest 4.4.x kernel, rather than with Pat's latest official release. I like the idea of scripts! Although I'm not a programmer I seem to be able to read and understand the logic of them, although the variables sometimes confuse me.

Yes, a lot of my admin scripts are simply cut-n-paste lists of commands that worked for me copied to a text file.

Sometimes I clean them up a little and add variables or flags but quite often they're just the working sequence of commands in a text file.

I like scripts in these cases so I don't forget steps or mis-type a command ...

Quote:

Is there a reason you haven't used a mkinitrd.conf for some of the variables? Darth Vader suggested modifying that file to assure the intel-ucode.cpio is actually included in the initrd, which makes sense. I'll be working on this more tomorrow. Again thanks. Cheers

Yes, there are better ways to do what I am doing now ( /etc/mkinitrd.conf ) and there is also a -P option for mkinitrd so that you can pass the microcode cpio archive to mkinitrd ( man mkinitrd ).

But the scripts work for me and being old and set in my ways, I'll keep doing it the way I do it until it breaks

HTH

-- kjh

BratPit · 01-08-2018, 11:14 AM

Quote:

Originally Posted by kjhambrick

bamunds --

The HUGE Kernel does not need an initrd UNLESS you need to load the intel-ucode.cpio file or maybe some module that Pat did not compile into HUGE ...

I used to run HUGE because I was lazy ( no need for an initrd ) and because I was old and set in my ways

But since the Intel ME Bug and now that I need to load intel-ucode.cpio, I no longer run HUGE, I've gone GENERIC.

-- kjh

Solution for HUGE but not only .

Recompile with this options /change to your firmware module name/

Quote:

Device Drivers --->
Generic Driver Options --->[*] Include in-kernel firmware blobs in kernel binary
(intel-ucode/06-3c-03) External firmware blobs to build into the kernel binary
(/lib/firmware/) Firmware blobs root directory

if you do not know which microcode module is for your processor:

Quote:

iucode_tool -S -l /lib/firmware/intel-ucode/*
iucode_tool: system has processor(s) with signature 0x000306c3
[...]
microcode bundle 49: /lib/firmware/intel-ucode/06-3c-03
[...]
selected microcodes:
049/001: sig 0x000306c3, pf_mask 0x32, 2017-12-10, rev 0x0023, size 22528

, and it autoload early like from initrd

I do not know if this option is in 4.4 kernel but in 4.9 is and work.

BratPit · 01-08-2018, 11:14 AM

Quote:

Originally Posted by kjhambrick

bamunds --

The HUGE Kernel does not need an initrd UNLESS you need to load the intel-ucode.cpio file or maybe some module that Pat did not compile into HUGE ...

I used to run HUGE because I was lazy ( no need for an initrd ) and because I was old and set in my ways

But since the Intel ME Bug and now that I need to load intel-ucode.cpio, I no longer run HUGE, I've gone GENERIC.

-- kjh

Solution for HUGE but not only .

Recompile with this options /change to your firmware module name/

Quote:

Device Drivers --->
Generic Driver Options --->[*] Include in-kernel firmware blobs in kernel binary
(intel-ucode/06-3c-03) External firmware blobs to build into the kernel binary
(/lib/firmware/) Firmware blobs root directory

if you do not know which microcode module is for your processor:

Quote:

iucode_tool -S -l /lib/firmware/intel-ucode/*
iucode_tool: system has processor(s) with signature 0x000306c3
[...]
microcode bundle 49: /lib/firmware/intel-ucode/06-3c-03
[...]
selected microcodes:
049/001: sig 0x000306c3, pf_mask 0x32, 2017-12-10, rev 0x0023, size 22528

, and it autoload early like from initrd

I do not know if this option is in 4.4 kernel but in 4.9 is and work.