SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
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.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
@keefaz I've tried to use that script and the first test is always failing as "couldn't find your kernel image in /boot,.."
My kernel responds to uname -r as '4.4.106-ba'. I saw where you suggested modifying line 113 of the script, but I've tried that and actually gone to a full 10 X's and it still doesn't recognize the kernel. The /boot/vmlinuz is a symlink to vmlinuz-custom-4.4.106 image on my machine. Any suggestions? Thanks
You have to use just 6 Xs for mktemp
Code:
man mktemp
...
The mktemp utility takes the given filename template and overwrites a
portion of it to create a unique filename. The template may be any
filename with six (6) `Xs' appended to it, for example
/tmp/tfile.XXXXXX.
For the kernel filename, just write it in the script after it tests for files in /boot, eg add this line
Thanks, the added image file did the trick. This is a nice script tool for testing, it should be added to the Greg K-H discussion about Meltdown and Spectre https://www.linuxquestions.org/quest...el-4175621133/so others are aware of it.
I'm actually kinda surprised that 4.1 isn't getting the updates (or maybe it is and I'm just not aware of it), because it won't be EOL until May 2018. Other than that, 4.4, 4.9, 4.14, and 4.15 are the only maintained kernels by kernel developers. All other kernels versions have been EOLed and probably won't see official updates for these vulnerabilities.
Hmm, Intel's latest microcode available is dated 20180108. Pulled it from their download site earlier linked in this thread. I then modified the intel-microcode.SlackBuild to reference the new file and executed the SlackBuild. That placed a new intel-ucode.cpio in /boot and built a package which was then installed. Then issued
and rebooted. But when dmesg is checked it doesn't show any new microcode loading. So checked the download and the 0xf47 file (0F-04-07) is included with a new date. On the Greg K-H thread it is noted that Intel is working on CPU's upto five years old.
Appears nothing new is loading at this time. Expected to see results with microcode date of 01/08/2018. The Intel releasenote mention resetting the reload, which the intel-microcode slackbuild does NOT mentioin. Did I miss a step?
Or will results only appear if new microcode is actually changed?
I've built and installed 2018-01-08 but I'm still building 4.4.111 so I'll boot it later.
This is my current running intel-ucode version from 2017-11-17:
Code:
# dmesg -t |grep -m1 microcode
microcode: CPU0 microcode updated early to revision 0xba, date = 2017-04-09
The release notes so show that I should bump from revision 0xba to 0xc2 ...
My new kernel is ready to install so here we go ... will report back.
EDIT: Back on the air with 4.4.111 + intel-microcode 2018-01-08 and the NVIDIA-Linux-x86_64-384.98.run blob.
My intel-ucode revision is now:
Code:
# dmesg -t |grep -m1 microcode
microcode: CPU0 microcode updated early to revision 0xc2, date = 2017-11-16
-- kjh
Code:
# cat releasenote
Intel Processor Microcode Package for Linux
20180108 Release
-- Updates upon 20171117 release --
IVT C0 (06-3e-04:ed) 428->42a
SKL-U/Y D0 (06-4e-03:c0) ba->c2
BDW-U/Y E/F (06-3d-04:c0) 25->28
HSW-ULT Cx/Dx (06-45-01:72) 20->21
Crystalwell Cx (06-46-01:32) 17->18
BDW-H E/G (06-47-01:22) 17->1b
HSX-EX E0 (06-3f-04:80) 0f->10
SKL-H/S R0 (06-5e-03:36) ba->c2
HSW Cx/Dx (06-3c-03:32) 22->23
HSX C0 (06-3f-02:6f) 3a->3b
BDX-DE V0/V1 (06-56-02:10) 0f->14
BDX-DE V2 (06-56-03:10) 700000d->7000011
KBL-U/Y H0 (06-8e-09:c0) 62->80
KBL Y0 / CFL D0 (06-8e-0a:c0) 70->80
KBL-H/S B0 (06-9e-09:2a) 5e->80
CFL U0 (06-9e-0a:22) 70->80
CFL B0 (06-9e-0b:02) 72->80
SKX H0 (06-55-04:b7) 2000035->200003c
GLK B0 (06-7a-01:01) 1e->22
-- Microcode update instructions --
This package contains Intel microcode files in two formats:
* microcode.dat
* intel-ucode directory
microcode.dat is in a traditional text format. It is still used in some
Linux distributions. It can be updated to the system through the old microcode
update interface which is avaialble in the kernel with
CONFIG_MICROCODE_OLD_INTERFACE=y.
To update the microcode.dat to the system, one need:
1. Ensure the existence of /dev/cpu/microcode
2. Write microcode.dat to the file, e.g.
dd if=microcode.dat of=/dev/cpu/microcode bs=1M
intel-ucode dirctory contains binary microcode files named in
family-model-stepping pattern. The file is supported in most modern Linux
distributions. It's generally located in the /lib/firmware directory,
and can be updated throught the microcode reload interface.
To update the intel-ucode package to the system, one need:
1. Ensure the existence of /sys/devices/system/cpu/microcode/reload
2. Copy intel-ucode directory to /lib/firmware, overwrite the files in
/lib/firmware/intel-ucode/
3. Write the reload interface to 1 to reload the microcode files, e.g.
echo 1 > /sys/devices/system/cpu/microcode/reload
Last edited by kjhambrick; 01-10-2018 at 06:42 AM.
Hmm, Intel's latest microcode available is dated 20180108. Pulled it from their download site earlier linked in this thread. I then modified the intel-microcode.SlackBuild to reference the new file and executed the SlackBuild. That placed a new intel-ucode.cpio in /boot and built a package which was then installed. Then issued
and rebooted. But when dmesg is checked it doesn't show any new microcode loading. So checked the download and the 0xf47 file (0F-04-07) is included with a new date. On the Greg K-H thread it is noted that Intel is working on CPU's upto five years old.
Appears nothing new is loading at this time. Expected to see results with microcode date of 01/08/2018. The Intel releasenote mention resetting the reload, which the intel-microcode slackbuild does NOT mentioin. Did I miss a step?
Or will results only appear if new microcode is actually changed?
Trouble shooting advice appreciated. Cheers
What do you have in your lilo.conf (or elilo.conf)? Do you have a reference to your initrd in there?
Hmm, Intel's latest microcode available is dated 20180108. Pulled it from their download site earlier linked in this thread. I then modified the intel-microcode.SlackBuild to reference the new file and executed the SlackBuild. That placed a new intel-ucode.cpio in /boot and built a package which was then installed. Then issued
and rebooted. But when dmesg is checked it doesn't show any new microcode loading. So checked the download and the 0xf47 file (0F-04-07) is included with a new date. On the Greg K-H thread it is noted that Intel is working on CPU's upto five years old.
Appears nothing new is loading at this time. Expected to see results with microcode date of 01/08/2018. The Intel releasenote mention resetting the reload, which the intel-microcode slackbuild does NOT mentioin. Did I miss a step?
Or will results only appear if new microcode is actually changed?
Trouble shooting advice appreciated. Cheers
bamunds --
I wonder what your CPU Family, Model, Stepping is ?
And is there a new file for that set of CPU Parameters in /lib/firmware/intel-ucode/ which was installed with your modified intel-microcode.SlackBuild ?
This is the file for my CPU ( i7 6700K ):
Code:
# ls -la /lib/firmware/intel-ucode/`./.get-my-cpu-f-m-s.sh`
-rw-r--r-- 1 root root 99328 Jan 10 06:25 /lib/firmware/intel-ucode/06-5e-03
Note the .get-my-cpu-f-m-s.sh script in the command line !
The script is below my sig.
This is the output for my CPU:
Code:
# ./.get-my-cpu-f-m-s.sh
06-5e-03
HTH
-- kjh
This is .get-my-cpu-f-m-s.sh ... it lives in my intel-microcode SlackBuild Directory:
Not much to it and my `gawk` programming style annoys purists, the fanciest thing it does is print the /proc/cpuinfo Family, Model, Stepping data as Hex.
Code:
!/bin/sh
gawk '
BEGIN {
FS = ":"
F = M = S = N = 0
# cpu family : 6
# model : 94
# stepping : 3
}
{
if ( match( $1, /^cpu family[\t ]*$/ ))
{
F = $2 +0
if (( ++N ) >= 3 )
{
exit( 0 )
}
next
}
if ( match( $1, /^model[\t ]*$/ ))
{
M = $2 +0
if (( ++N ) >= 3 )
{
exit( 0 )
}
next
}
if ( match( $1, /^stepping[\t ]*$/ ))
{
S = $2 +0
if (( ++N ) >= 3 )
{
exit( 0 )
}
next
}
if ( N >= 3 )
{
exit( 0 )
}
}
END {
if ( N >= 3 )
{
printf( "%02x-%02x-%02x\n", F, M, S )
exit 0
}
print ""
exit 1
}' /proc/cpuinfo
Hmm, Intel's latest microcode available is dated 20180108. Pulled it from their download site earlier linked in this thread. I then modified the intel-microcode.SlackBuild to reference the new file and executed the SlackBuild. That placed a new intel-ucode.cpio in /boot and built a package which was then installed. Then issued
and rebooted. But when dmesg is checked it doesn't show any new microcode loading. So checked the download and the 0xf47 file (0F-04-07) is included with a new date. On the Greg K-H thread it is noted that Intel is working on CPU's upto five years old.
Appears nothing new is loading at this time. Expected to see results with microcode date of 01/08/2018. The Intel releasenote mention resetting the reload, which the intel-microcode slackbuild does NOT mentioin. Did I miss a step?
Or will results only appear if new microcode is actually changed?
Or will results only appear if new microcode is actually changed?
Yes, depending on your CPU, you might not see new ucode loaded if there are no updates for it, even if you did build a new initrd with the new microcode release.
For example this is the output when I applied the latest Intel microcode (20180108):
Before that it was at 0x22. It was at 0x22 over more than few microcode updates so only if there's something applicable to your CPU, it will be updated, if not there will be no change even if you did everything properly with the initrd.
-- Microcode update instructions --
This package contains Intel microcode files in two formats:
* microcode.dat
* intel-ucode directory
microcode.dat is in a traditional text format. It is still used in some
Linux distributions. It can be updated to the system through the old microcode
update interface which is avaialble in the kernel with
CONFIG_MICROCODE_OLD_INTERFACE=y.
To update the microcode.dat to the system, one need:
1. Ensure the existence of /dev/cpu/microcode
2. Write microcode.dat to the file, e.g.
dd if=microcode.dat of=/dev/cpu/microcode bs=1M
intel-ucode dirctory contains binary microcode files named in
family-model-stepping pattern. The file is supported in most modern Linux
distributions. It's generally located in the /lib/firmware directory,
and can be updated throught the microcode reload interface.
To update the intel-ucode package to the system, one need:
1. Ensure the existence of /sys/devices/system/cpu/microcode/reload
2. Copy intel-ucode directory to /lib/firmware, overwrite the files in
/lib/firmware/intel-ucode/
3. Write the reload interface to 1 to reload the microcode files, e.g.
echo 1 > /sys/devices/system/cpu/microcode/reload
Method 1
Does not work at all for me. The output listed
Code:
[root@darkstar:~] # dd if=microcode.dat of=/dev/cpu/microcode bs=1M
dd: error writing '/dev/cpu/microcode': Invalid argument
1+0 records in
0+0 records out
0 bytes copied, 0.0441653 s, 0.0 kB/s
Method 2
Does work for me, but it reverts after reboot. The output listed
At this point you'll have a /boot/intel-ucode.cpio initrd file, something like this:
Code:
# ls -la /boot/intel-ucode.cpio
-rw-r--r-- 1 root root 1614848 Jan 10 06:25 /boot/intel-ucode.cpio
The /boot/intel-ucode.cpio file may be prepended to your existing, working initrd file(s) !
I am not exactly sure what you're doing in the first stanza of your lilo.conf ( your default ), but the 2nd entry looks familiar.
And to be safe, rather than replace you existing initrd file and lilo stanza, I would hedge my bets and make a new initrd for the one in your 2nd stanza:
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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.