[SOLVED] intel-ucode update - implementation?

mcloaked · 2014-10-12 17:40:09

There is a new intel-ucode package in testing and it will be released soon - this is going to require some intervention to get the microcode update on boot. Is there going to be some advice for adding in the additional initrd lines for different bootloaders/bootmanagers?

For example if I understand correctly for rEFInd it will need an amendment to the refind_linux.conf or perhaps if you have menuentry stanzas then additional initrd sections can be added in the refind.conf?

Does anyone know if there is a recommended way to do this for rEFInd, and for other bootloaders that are in common use?

Last edited by mcloaked (2014-10-23 15:32:06)

Spider.007 · 2014-10-12 17:51:23

Where did you find that it is going to require manual intervention? I'm pretty sure the kernel has handled all ucode updates so far?

mcloaked · 2014-10-12 17:55:34

If you have recently updated with testing enabled you will find the pacman log with lines like:

(3/9) upgrading intel-ucode                                       [####################################] 100%
Intel CPU ucode upgrades are no longer performed by the firmware loader.
If you want to update the Intel CPU ucode on boot, add the file
 /boot/intel-ucode.img
as the first initrd to your bootloader.

For more information, see https://wiki.archlinux.org/index.php/Microcode#Enabling_Intel_Microcode_Updates
(4/9) upgrading linux

Additionally Thomas Bachler has started a thread on the arch mailing list about the new version of intel-ucode and a few issues. This applies for version intel-ucode 20140913-1. It seems that particularly for Haswell CPUs the new microcode removes a particular instruction that can crash the system if the microcode is not updated before the kernel loads. Hence the need for loading the updated microcode early in the boot sequence.

Last edited by mcloaked (2014-10-12 17:59:36)

graysky · 2014-10-12 21:00:56

Following the advice on the wiki to double load the .img files works for grub (just a space separating them two images is fine in my experience). What is the recommended method to have /usr/bin/grub-mkconfig handle it automatically?

initrd  /intel-ucode.img /initramfs-linux-custom.img

brain0 · 2014-10-13 15:53:33

graysky wrote:

Following the advice on the wiki to double load the .img files works for grub (just a space separating them two images is fine in my experience). What is the recommended method to have /usr/bin/grub-mkconfig handle it automatically?
initrd  /intel-ucode.img /initramfs-linux-custom.img

Please extend the wiki once you figure it out. It looks like the same mechanism will be used for AMD updates soon btw.

brain0 · 2014-10-13 15:55:17

mcloaked wrote:

For example if I understand correctly for rEFInd it will need an amendment to the refind_linux.conf or perhaps if you have menuentry stanzas then additional initrd sections can be added in the refind.conf?
Does anyone know if there is a recommended way to do this for rEFInd, and for other bootloaders that are in common use?

Doesn't refind merely load Linux via the EFI stub loader? If so, simply appending two initrd= options is enough (with EFI stub, Linux loads the initrd images from the ESP itself instead of expecting them from the bootloader).

progandy · 2014-10-13 16:32:33

I have a question. Why don't you install the microcode to e.g.
/usr/lib/initcpio/ucode/kernel/x86/microcode/GenuineIntel.bin
/usr/lib/initcpio/ucode/kernel/x86/microcode/GenuineAMD.bin
Then, mkinitcpio looks for bin files in the ucode directory and creates a cpio with all found microcode images.
Then it does a "cat /tmp/ucode.img /tmp/initramfs-linux > /boot/initramfs-linux.img"
No changes in the bootloader are required.
Edit: maybe add a configuration option like UCODE=(GenuineIntel.bin GenuineAMD.bin) to override automatic searches.

Last edited by progandy (2014-10-13 16:35:31)

mcloaked · 2014-10-13 16:41:51

progandy, that sounds reasonable and, if that works, are the developers seeing this, and could this be done when updating to the new intel-ucode with a post install scriptlet avoiding the need for manual configuring? If not does this need a flyspray report to make the suggestion visible to developers?

The directories would need to be created under /usr/lib/initcpio/ and presumably your suggestion assumes that mkinitcpio would then automatically search the new directory?

Last edited by mcloaked (2014-10-13 16:44:52)

Scimmia · 2014-10-13 16:44:53

They may or may not see suggestions made here. They have a higher chance of seeing them on the arch-general mailing list, but that may be missed as well. A feature request on the bug tracker is your best bet.

nomorewindows · 2014-10-13 16:45:49

progandy wrote:

I have a question. Why don't you install the microcode to e.g.
/usr/lib/initcpio/ucode/kernel/x86/microcode/GenuineIntel.bin
/usr/lib/initcpio/ucode/kernel/x86/microcode/GenuineAMD.bin
Then, mkinitcpio looks for bin files in the ucode directory and creates a cpio with all found microcode images.
Then it does a "cat /tmp/ucode.img /tmp/initramfs-linux > /boot/initramfs-linux.img"
No changes in the bootloader are required.
Edit: maybe add a configuration option like UCODE=(GenuineIntel.bin GenuineAMD.bin) to override automatic searches.

That's all the initramfs images are anyway, why not just add it this way suggested? Not sure if syslinux supports two initramfs, but it might. Just add all files needed to BINARIES in mkinticpio.conf regardless of where they are located.

Last edited by nomorewindows (2014-10-13 16:47:03)

brain0 · 2014-10-13 17:18:23

progandy wrote:

I have a question. Why don't you install the microcode to e.g.
/usr/lib/initcpio/ucode/kernel/x86/microcode/GenuineIntel.bin
/usr/lib/initcpio/ucode/kernel/x86/microcode/GenuineAMD.bin
Then, mkinitcpio looks for bin files in the ucode directory and creates a cpio with all found microcode images.
Then it does a "cat /tmp/ucode.img /tmp/initramfs-linux > /boot/initramfs-linux.img"
No changes in the bootloader are required.
Edit: maybe add a configuration option like UCODE=(GenuineIntel.bin GenuineAMD.bin) to override automatic searches.

It was a possibility, but actually causes more work. First, it changes the way mkinitcpio works, which isn't bad, but rather ugly. Instead of one image, you must now generate two images. Second, disabling the ucode update in case of trouble would now be impossible. Third, what you propose breaks lsinitcpio - in case your usual image is compressed, lsinitcpio (and every similar tool) will only show the ucode image and not the main image. This can all be done, but adding a drop-in initramfs to enable in the bootloader was the simpler solution.

brain0 · 2014-10-13 17:23:41

nomorewindows wrote:

Not sure if syslinux supports two initramfs, but it might.

It does. See the wiki for instructions.

nomorewindows wrote:

Just add all files needed to BINARIES in mkinticpio.conf regardless of where they are located.

That won't work. Ucode updates are very special in the way they are handled. Since the ucode is updated extremely early in the boot process, most kernel functions and structures are still unavailable. If I understood it right, the early ucode loading process contains a lightweight cpio parser that can read uncompressed cpio archives and stops reading when it encounters the filename kernel/x86/microcode/{GenuineIntel,AuthenticAMD.bin} (note that the filename MUST be exactly like this, no leading ./ or similar, so mkinitcpio breaks here, too). This means no decompression and the process is probably dead slow, so the file better be at the beginning of the image.

The actual decompression of the initramfs to rootfs happens later, when the VFS is available.

mcloaked · 2014-10-13 17:27:09

nomorewindows wrote:

progandy wrote:
I have a question. Why don't you install the microcode to e.g.
/usr/lib/initcpio/ucode/kernel/x86/microcode/GenuineIntel.bin
/usr/lib/initcpio/ucode/kernel/x86/microcode/GenuineAMD.bin
Then, mkinitcpio looks for bin files in the ucode directory and creates a cpio with all found microcode images.
Then it does a "cat /tmp/ucode.img /tmp/initramfs-linux > /boot/initramfs-linux.img"
No changes in the bootloader are required.
Edit: maybe add a configuration option like UCODE=(GenuineIntel.bin GenuineAMD.bin) to override automatic searches.
That's all the initramfs images are anyway, why not just add it this way suggested? Not sure if syslinux supports two initramfs, but it might. Just add all files needed to BINARIES in mkinticpio.conf regardless of where they are located.

If this method (adding the image to the BINARIES line in mkinitcpio.conf) works then I guess it would be bootloader agnostic and work with all bootloaders/managers?

Last edited by mcloaked (2014-10-13 17:27:38)

progandy · 2014-10-13 18:08:32

mcloaked wrote:

If this method (adding the image to the BINARIES line in mkinitcpio.conf) works then I guess it would be bootloader agnostic and work with all bootloaders/managers?

brain0 already answered the question. adding to BINARIES doesn't work and concatenating two cpio images is ugly and requires ugly special handling in many tools working with the images. Since sending two initrd images to the kernel works, it is a cleaner solution and it only involves a bit more work for the administrator (one small configuration change).

Edit: If you are forced to use a bootloader that does not support multiple images, you can always create it manually with cat and use the result instead of the original.

Last edited by progandy (2014-10-13 18:16:35)

graysky · 2014-10-13 19:15:47

brain0 wrote:

graysky wrote:
Following the advice on the wiki to double load the .img files works for grub (just a space separating them two images is fine in my experience). What is the recommended method to have /usr/bin/grub-mkconfig handle it automatically?
initrd  /intel-ucode.img /initramfs-linux-custom.img
Please extend the wiki once you figure it out. It looks like the same mechanism will be used for AMD updates soon btw.

https://bugs.archlinux.org/task/42354

I also emailed Keshav who originally patched grub-mkconfig to work with our initramfs images directing him to that FS.

mcloaked · 2014-10-13 20:54:10

It seems that it might be best if the method(s) to handle this for the main bootloaders and bootmanagers (grub, gummiboot, refind, syslinux) was worked out and notified to users before the new intel-ucode moves from testing to extra.

graysky · 2014-10-13 21:26:16

mcloaked wrote:

It seems that it might be best if the method(s) to handle this for the main bootloaders and bootmanagers (grub, gummiboot, refind, syslinux) was worked out and notified to users before the new intel-ucode moves from testing to extra.

That is most certainly going to be the case.

mcloaked · 2014-10-21 14:46:46

One possible way towards a solution is the suggested script in the file at https://www.kernel.org/doc/Documentatio … rocode.txt that would provide a method that would allow creating a combined initrd img file to be used to replace the normal initrd, and avoid the need to use two initrd files in the config files? It would be worth testing? Would this in principle work for all bootloaders/bootmanagers? Maybe if this was done as a post-install scriptlet when the kernel updates could that be a route to a solution that might not need changes to any of the bootloaders?

graysky · 2014-10-21 14:52:31

There is already an assigned fs for grub. Don't think messing with mkinitcpio is the right strategy.

adoa · 2014-10-22 21:54:44

graysky wrote:

What is the recommended method to have /usr/bin/grub-mkconfig handle it automatically?

That was exactly my question, when I saw the message in the news. According to the wiki, it is not recommended to manually change the grub.cfg.

rumpelsepp · 2014-10-22 22:29:37

adoa wrote:

That was exactly my question, when I saw the message in the news. According to the wiki, it is not recommended to manually change the grub.cfg.

Here is the FS with an attached patch: https://bugs.archlinux.org/task/42354

bulletmark · 2014-10-22 23:15:48

Not sure where to write this but this thread is possibly appropriate. I saw the microcode updates news post today by Thomas Bachler so I went to the referenced wiki page and followed exactly the procedure for an intel cpu + gummiboot. Rebooted my PC and it failed to boot with a "Failed to open intel-ucode.img" message. Had to boot up my laptop and research how to interrupt and edit gummiboot before I could recover my pc.

The problem turns out that I needed to update to today's new kernel update (3.17.1-1) and then after that install the intel-ucode package before the /boot/intel-ucode.img file gets installed. Perhaps the news item should be updated with this warning?

Last edited by bulletmark (2014-10-22 23:16:38)

usprey · 2014-10-23 00:36:12

bulletmark wrote:

Not sure where to write this but this thread is possibly appropriate. I saw the microcode updates news post today by Thomas Bachler so I went to the referenced wiki page and followed exactly the procedure for an intel cpu + gummiboot. Rebooted my PC and it failed to boot with a "Failed to open intel-ucode.img" message. Had to boot up my laptop and research how to interrupt and edit gummiboot before I could recover my pc.
The problem turns out that I needed to update to today's new kernel update (3.17.1-1) and then after that install the intel-ucode package before the /boot/intel-ucode.img file gets installed. Perhaps the news item should be updated with this warning?

The wiki page linked in the news item explicitly states which intel-ucode version the information applies to.
You're welcome to update the wiki if you don't think it is clear enough...

cro · 2014-10-23 12:29:16

Can this also work with Grub 1 (aka Legacy Grub)?
I just got a kernel panic.
I'm still not fully prepared to migrate my old system to Grub 2 (aka Grub). Legacy Grub works fine and I don't have the time and the nerves.

mcloaked · 2014-10-23 14:45:26

I have just updated my system to the new kernel and new microcode packages (linux 3.17.1-1 intel-ucode 20140913-1). This system boots with rEFInd. The /boot/refind_linux.conf file was edited to include the microcode image file as an initrd= entry with lines as

# cat /boot/refind_linux.conf
"Boot to X" "root=PARTUUID=b0c9c220-0f8d-49c1-b306-873d2519ce47 rw rootfstype=ext4 add_efi_memmapinitrd=/boot/intel-ucode.img initrd=/boot/initramfs-linux.img systemd.unit=graphical.target"
"Boot to console" "root=PARTUUID=b0c9c220-0f8d-49c1-b306-873d2519ce47 rw rootfstype=ext4 add_efi_memmap initrd=/boot/intel-ucode.img initrd=/boot/initramfs-linux.img systemd.unit=multi-user.target"
"Boot Fallback to console" "root=PARTUUID=b0c9c220-0f8d-49c1-b306-873d2519ce47 rw rootfstype=ext4 add_efi_memmap initrd=/boot/intel-ucode.img initrd=/boot/initramfs-linux-fallback.img systemd.unit=multi-user.target"

The system boots in the same time as previously with kernel 3.16 and the journal log confirms early microcode update.

# journalctl -b | grep microcode
Oct 23 15:41:56 localhost kernel: CPU0 microcode updated early to revision 0x1b, date = 2014-05-29
Oct 23 15:41:56 localhost kernel: CPU1 microcode updated early to revision 0x1b, date = 2014-05-29
Oct 23 15:41:56 localhost kernel: microcode: CPU0 sig=0x306a9, pf=0x2, revision=0x1b
Oct 23 15:41:56 localhost kernel: microcode: CPU1 sig=0x306a9, pf=0x2, revision=0x1b
Oct 23 15:41:56 localhost kernel: microcode: CPU2 sig=0x306a9, pf=0x2, revision=0x1b
Oct 23 15:41:56 localhost kernel: microcode: CPU3 sig=0x306a9, pf=0x2, revision=0x1b
Oct 23 15:41:56 localhost kernel: microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba

So the updated kernel works fine for early microcode update, with the small amendment to the refind_linux.conf file as the rEFInd author suggested it would. I have tested this on three different machines all of which use rEFInd to boot. It is presumed that the latest microcode for the CPU in this machine is dated correctly as 2014-05-29.

Last edited by mcloaked (2014-10-23 14:50:48)

Arch Linux

#1 2014-10-12 17:40:09

[SOLVED] intel-ucode update - implementation?

#2 2014-10-12 17:51:23

Re: [SOLVED] intel-ucode update - implementation?

#3 2014-10-12 17:55:34

Re: [SOLVED] intel-ucode update - implementation?

#4 2014-10-12 21:00:56

Re: [SOLVED] intel-ucode update - implementation?

#5 2014-10-13 15:53:33

Re: [SOLVED] intel-ucode update - implementation?

#6 2014-10-13 15:55:17

Re: [SOLVED] intel-ucode update - implementation?

#7 2014-10-13 16:32:33

Re: [SOLVED] intel-ucode update - implementation?

#8 2014-10-13 16:41:51

Re: [SOLVED] intel-ucode update - implementation?

#9 2014-10-13 16:44:53

Re: [SOLVED] intel-ucode update - implementation?

#10 2014-10-13 16:45:49

Re: [SOLVED] intel-ucode update - implementation?

#11 2014-10-13 17:18:23

Re: [SOLVED] intel-ucode update - implementation?

#12 2014-10-13 17:23:41

Re: [SOLVED] intel-ucode update - implementation?

#13 2014-10-13 17:27:09

Re: [SOLVED] intel-ucode update - implementation?

#14 2014-10-13 18:08:32

Re: [SOLVED] intel-ucode update - implementation?

#15 2014-10-13 19:15:47

Re: [SOLVED] intel-ucode update - implementation?

#16 2014-10-13 20:54:10

Re: [SOLVED] intel-ucode update - implementation?

#17 2014-10-13 21:26:16

Re: [SOLVED] intel-ucode update - implementation?

#18 2014-10-21 14:46:46

Re: [SOLVED] intel-ucode update - implementation?

#19 2014-10-21 14:52:31

Re: [SOLVED] intel-ucode update - implementation?

#20 2014-10-22 21:54:44

Re: [SOLVED] intel-ucode update - implementation?

#21 2014-10-22 22:29:37

Re: [SOLVED] intel-ucode update - implementation?

#22 2014-10-22 23:15:48

Re: [SOLVED] intel-ucode update - implementation?

#23 2014-10-23 00:36:12

Re: [SOLVED] intel-ucode update - implementation?

#24 2014-10-23 12:29:16

Re: [SOLVED] intel-ucode update - implementation?

#25 2014-10-23 14:45:26

Re: [SOLVED] intel-ucode update - implementation?

Board footer