LinuxQuestions.org
Latest LQ Deal: Linux Power User Bundle
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices


Reply
  Search this Thread
Old 01-05-2018, 10:51 PM   #1
bamunds
Member
 
Registered: Sep 2013
Location: Mounds View MN
Distribution: Slackware64-14.2 Multilib
Posts: 426

Rep: Reputation: 95
How to load new Intel microcode


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 View Post
@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?

Last edited by bamunds; 01-06-2018 at 11:51 PM. Reason: newest information.
 
Old 01-06-2018, 03:48 AM   #2
Petri Kaukasoina
Member
 
Registered: Mar 2007
Posts: 286

Rep: Reputation: 143Reputation: 143
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.

Last edited by Petri Kaukasoina; 01-06-2018 at 04:05 AM.
 
8 members found this post helpful.
Old 01-06-2018, 06:02 AM   #3
zakame
Member
 
Registered: Apr 2012
Distribution: Debian, Ubuntu, Slackware
Posts: 227

Rep: Reputation: 135Reputation: 135
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.
 
6 members found this post helpful.
Old 01-06-2018, 03:12 PM   #4
mralk3
Member
 
Registered: May 2015
Distribution: Slackware, Debian, CentOS, FreeBSD
Posts: 910

Rep: Reputation: 320Reputation: 320Reputation: 320Reputation: 320
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

Last edited by mralk3; 01-10-2018 at 01:54 PM.
 
2 members found this post helpful.
Old 01-06-2018, 05:07 PM   #5
bamunds
Member
 
Registered: Sep 2013
Location: Mounds View MN
Distribution: Slackware64-14.2 Multilib
Posts: 426

Original Poster
Rep: Reputation: 95
Quote:
Originally Posted by Petri Kaukasoina View Post
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 View Post
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 View Post
(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.

Last edited by bamunds; 01-06-2018 at 05:11 PM.
 
Old 01-06-2018, 05:25 PM   #6
Darth Vader
Senior Member
 
Registered: May 2008
Location: Romania
Distribution: DARKSTAR Linux 2008.1
Posts: 1,968

Rep: Reputation: 698Reputation: 698Reputation: 698Reputation: 698Reputation: 698Reputation: 698
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.

Last edited by Darth Vader; 01-06-2018 at 05:27 PM.
 
Old 01-06-2018, 05:32 PM   #7
bamunds
Member
 
Registered: Sep 2013
Location: Mounds View MN
Distribution: Slackware64-14.2 Multilib
Posts: 426

Original Poster
Rep: Reputation: 95
Quote:
Originally Posted by mralk3 View Post
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 View Post
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 View Post
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 View Post
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.
 
Old 01-06-2018, 05:47 PM   #8
bamunds
Member
 
Registered: Sep 2013
Location: Mounds View MN
Distribution: Slackware64-14.2 Multilib
Posts: 426

Original Poster
Rep: Reputation: 95
Quote:
Originally Posted by Darth Vader View Post
...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 View Post
/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.
 
Old 01-06-2018, 05:57 PM   #9
Darth Vader
Senior Member
 
Registered: May 2008
Location: Romania
Distribution: DARKSTAR Linux 2008.1
Posts: 1,968

Rep: Reputation: 698Reputation: 698Reputation: 698Reputation: 698Reputation: 698Reputation: 698
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.
 
Old 01-06-2018, 11:59 PM   #10
bamunds
Member
 
Registered: Sep 2013
Location: Mounds View MN
Distribution: Slackware64-14.2 Multilib
Posts: 426

Original Poster
Rep: Reputation: 95
@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.

Last edited by bamunds; 01-07-2018 at 12:05 AM.
 
Old 01-07-2018, 09:06 AM   #11
kjhambrick
Senior Member
 
Registered: Jul 2005
Location: Round Rock, TX
Distribution: Slackware64 14.2 + Multilib
Posts: 1,132

Rep: Reputation: 544Reputation: 544Reputation: 544Reputation: 544Reputation: 544Reputation: 544
Quote:
Originally Posted by bamunds View Post
@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 View Post
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
 
Old 01-07-2018, 09:35 AM   #12
magicm
Member
 
Registered: May 2003
Distribution: Slackware
Posts: 113

Rep: Reputation: 41
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.
 
Old 01-08-2018, 12:12 AM   #13
bamunds
Member
 
Registered: Sep 2013
Location: Mounds View MN
Distribution: Slackware64-14.2 Multilib
Posts: 426

Original Poster
Rep: Reputation: 95
@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
 
Old 01-08-2018, 08:17 AM   #14
kjhambrick
Senior Member
 
Registered: Jul 2005
Location: Round Rock, TX
Distribution: Slackware64 14.2 + Multilib
Posts: 1,132

Rep: Reputation: 544Reputation: 544Reputation: 544Reputation: 544Reputation: 544Reputation: 544
Quote:
Originally Posted by bamunds View Post
@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
 
Old 01-08-2018, 11:14 AM   #15
BratPit
Member
 
Registered: Jan 2011
Posts: 222

Rep: Reputation: 79
Quote:
Originally Posted by kjhambrick View Post
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.

Last edited by BratPit; 01-08-2018 at 11:29 AM.
 
1 members found this post helpful.
Old 01-08-2018, 11:14 AM   #16
BratPit
Member
 
Registered: Jan 2011
Posts: 222

Rep: Reputation: 79

Quote:
Originally Posted by kjhambrick View Post
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.

Last edited by BratPit; 01-08-2018 at 11:29 AM.
 
1 members found this post helpful.
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
[SOLVED] Is it possible to update intel microcode using kernel-huge and grub2, without initrd? lagavulin16 Slackware 5 01-03-2018 10:27 AM
intel-microcode-20170707 kjhambrick Slackware 1 07-15-2017 09:04 AM
Lenovo Thinkpad x220 - Proprietary Driver for Microcode for Intel processor? wh33t Linux - Hardware 2 06-15-2016 12:41 PM
intel-microcode error Soapm Linux - Newbie 3 06-25-2015 02:37 AM
Intel IA32 CPU microcode...What is it Jester888 Linux - General 1 02-09-2007 12:30 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware

All times are GMT -5. The time now is 08:43 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration