# [SOLVED] microcode-data-20150121-r1 with USE=initramfs:panic

## bszente

Hi folks!

I'm writing here my problem, in hope that somebody will shed a light on my issue... It has been years since my last forum post...

Very brief description of the system:

Lenovo G510 with Core i7-4702MQ

EFI v2.31 by INSYDE Corp.

sys-kernel/gentoo-sources-4.1.6 on x86_64 booted directly with EFI stub loader, without any initramfs or GRUB, just plain kernel image

Everything was fine, system worked without any issues until the recent microcode-ctl and microcode-data package updates. Description of problem:

Upgrading to sys-apps/microcode-ctl-1.28-r1 the init scripts vanished

I carefully read the microcode-ctl-1.28-r1.ebuild

Followed exactly the steps described in the related Gentoo bug #528712#c41 comment

Result: kernel panic with unable to mount rootfs

Based on the detailed description in Gentoo bug #528712#c55 comment I realised it is the same situation as mine. And indeed, after including those missing 3 files in the microcode.cpio file, the kernel boots properly.

I issued a new Gentoo bug #558192 for this (from my point of view) incomplete microcode.cpio file, but according to the maintainer i'm clearly doing it wrong and the issue is with my system with no further explanation. So finally I took his advice, and I'm seeking help now here at Gentoo Forums, because I want to understand what is happening.

So my questions:

Is there anybody who managed to boot a stand-alone kernel with CONFIG_INITRAMFS_SOURCE set to /lib/firmware/microcode.cpio, as it is advised, but WITHOUT any external initramfs?

Do you have any hint/idea, what did I do wrong that in my (and other users as well) case does not work? However the kernel ramfs, rootfs and initramfs documentation clearly states that the initramfs must be populated and must have a certain format, thus it makes sense that by embedding microcode.cpio the kernel does not boot. On the other hand the maintainer states it works for him (without any further details/explanation) which apparently means i'm doing it wrong. But what am I doing wrong?   :Smile: 

Thank you.

Note: the panic happens as well with legacy BIOS machines using GRUB. So the BIOS or boot loader does not matter. The only thing I found that matters is the content of the embedded cpio archive.Last edited by bszente on Wed Sep 16, 2015 7:14 pm; edited 1 time in total

----------

## Fitzcarraldo

In the Gentoo amd64 installation on my Clevo W230SS laptop I don't use an initramfs either.

In this case should the path specified in CONFIG_INITRAMFS_SOURCE be relative or absolute? In other words, should it be specified as CONFIG_INITRAMFS_SOURCE="/lib/firmware/microcode.cpio" as SpanKY wrote in Comment #41 of Bug Report #528712, or should it be specified as CONFIG_INITRAMFS_SOURCE="/microcode.cpio"? The reason I ask is because early microcode updating works for me if I leave CONFIG_INITRAMFS_SOURCE="", copy the microcode cpio file to /boot/ and add the line 'initrd /microcode.cpio' to grub.cfg as explained in detail below.

Before doing anything at all, I checked the microcode version for my CPU (Intel Core i7-4810MQ @ 2.80GHz):

```
# grep microcode /proc/cpuinfo

microcode   : 0x12

microcode   : 0x12

microcode   : 0x12

microcode   : 0x12

microcode   : 0x12

microcode   : 0x12

microcode   : 0x12

microcode   : 0x12

# dmesg | grep microcode

[    0.262544] microcode: CPU0 sig=0x306c3, pf=0x10, revision=0x12

[    0.262641] microcode: CPU1 sig=0x306c3, pf=0x10, revision=0x12

[    0.262740] microcode: CPU2 sig=0x306c3, pf=0x10, revision=0x12

[    0.262841] microcode: CPU3 sig=0x306c3, pf=0x10, revision=0x12

[    0.262939] microcode: CPU4 sig=0x306c3, pf=0x10, revision=0x12

[    0.263038] microcode: CPU5 sig=0x306c3, pf=0x10, revision=0x12

[    0.263138] microcode: CPU6 sig=0x306c3, pf=0x10, revision=0x12

[    0.263236] microcode: CPU7 sig=0x306c3, pf=0x10, revision=0x12

[    0.263367] microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba
```

Fortunately I did not need to rebuild the kernel as I had already configured it back in April with a view to implementing early microcode updating:

```
# grep CONFIG_BLK_DEV_INITRD /usr/src/linux/.config

CONFIG_BLK_DEV_INITRD=y

# grep CONFIG_MICROCODE /usr/src/linux/.config

CONFIG_MICROCODE=y

CONFIG_MICROCODE_INTEL=y

# CONFIG_MICROCODE_AMD is not set

CONFIG_MICROCODE_OLD_INTERFACE=y

CONFIG_MICROCODE_INTEL_EARLY=y

# CONFIG_MICROCODE_AMD_EARLY is not set

CONFIG_MICROCODE_EARLY=y

# grep CONFIG_INITRAMFS_SOURCE /usr/src/linux/.config

CONFIG_INITRAMFS_SOURCE=""
```

Then I set the initramfs USE flag and unmasked the ~amd64 ebuilds created by SpanKY (microcode-ctl-1.28-r1.ebuild, microcode-data-20150121-r1.ebuild and iucode_tool-1.3.ebuild):

```
# cat /etc/portage/package.use/microcode-data

sys-apps/microcode-data initramfs

# cat /etc/portage/package.accept_keywords/microcode-data

sys-apps/microcode-data ~amd64

sys-apps/iucode_tool ~amd64

# cat /etc/portage/package.accept_keywords/microcode-ctl

sys-apps/microcode-ctl ~amd64
```

Then I merged the packages:

```
# emerge --ask microcode-ctl microcode-data
```

This resulted in the following files:

```
# ls -la /lib/firmware/microcode.cpio

-rw-r--r-- 1 root root 663552 Aug 26 15:06 /lib/firmware/microcode.cpio
```

```
# ls -la /lib/firmware/intel-ucode

total 768

drwxr-xr-x  2 root root  4096 Aug 26 15:06 .

drwxr-xr-x 62 root root 16384 Aug 26 15:06 ..

-rw-r--r--  1 root root  2048 Aug 26 15:06 06-03-02

-rw-r--r--  1 root root  6144 Aug 26 15:06 06-05-00

-rw-r--r--  1 root root  2048 Aug 26 15:06 06-05-01

-rw-r--r--  1 root root  6144 Aug 26 15:06 06-05-02

-rw-r--r--  1 root root  8192 Aug 26 15:06 06-05-03

-rw-r--r--  1 root root  2048 Aug 26 15:06 06-06-00

-rw-r--r--  1 root root  2048 Aug 26 15:06 06-06-05

-rw-r--r--  1 root root  6144 Aug 26 15:06 06-06-0a

-rw-r--r--  1 root root  6144 Aug 26 15:06 06-06-0d

-rw-r--r--  1 root root  2048 Aug 26 15:06 06-07-01

-rw-r--r--  1 root root  2048 Aug 26 15:06 06-07-02

-rw-r--r--  1 root root  2048 Aug 26 15:06 06-07-03

-rw-r--r--  1 root root 10240 Aug 26 15:06 06-08-01

-rw-r--r--  1 root root  4096 Aug 26 15:06 06-08-03

-rw-r--r--  1 root root 10240 Aug 26 15:06 06-08-06

-rw-r--r--  1 root root  6144 Aug 26 15:06 06-08-0a

-rw-r--r--  1 root root  6144 Aug 26 15:06 06-09-05

-rw-r--r--  1 root root  2048 Aug 26 15:06 06-0a-00

-rw-r--r--  1 root root  2048 Aug 26 15:06 06-0a-01

-rw-r--r--  1 root root  4096 Aug 26 15:06 06-0b-01

-rw-r--r--  1 root root  4096 Aug 26 15:06 06-0b-04

-rw-r--r--  1 root root  2048 Aug 26 15:06 06-0d-06

-rw-r--r--  1 root root  4096 Aug 26 15:06 06-0e-08

-rw-r--r--  1 root root  8192 Aug 26 15:06 06-0e-0c

-rw-r--r--  1 root root  8192 Aug 26 15:06 06-0f-02

-rw-r--r--  1 root root 12288 Aug 26 15:06 06-0f-06

-rw-r--r--  1 root root  8192 Aug 26 15:06 06-0f-07

-rw-r--r--  1 root root  4096 Aug 26 15:06 06-0f-0a

-rw-r--r--  1 root root 28672 Aug 26 15:06 06-0f-0b

-rw-r--r--  1 root root 12288 Aug 26 15:06 06-0f-0d

-rw-r--r--  1 root root 12288 Aug 26 15:06 06-16-01

-rw-r--r--  1 root root 20480 Aug 26 15:06 06-17-06

-rw-r--r--  1 root root  4096 Aug 26 15:06 06-17-07

-rw-r--r--  1 root root 24576 Aug 26 15:06 06-17-0a

-rw-r--r--  1 root root 14336 Aug 26 15:06 06-1a-04

-rw-r--r--  1 root root 10240 Aug 26 15:06 06-1a-05

-rw-r--r--  1 root root 15360 Aug 26 15:06 06-1c-02

-rw-r--r--  1 root root 20480 Aug 26 15:06 06-1c-0a

-rw-r--r--  1 root root  4096 Aug 26 15:06 06-1d-01

-rw-r--r--  1 root root  6144 Aug 26 15:06 06-1e-04

-rw-r--r--  1 root root  7168 Aug 26 15:06 06-1e-05

-rw-r--r--  1 root root  8192 Aug 26 15:06 06-25-02

-rw-r--r--  1 root root  3072 Aug 26 15:06 06-25-05

-rw-r--r--  1 root root 10240 Aug 26 15:06 06-26-01

-rw-r--r--  1 root root 10240 Aug 26 15:06 06-2a-07

-rw-r--r--  1 root root 16384 Aug 26 15:06 06-2d-06

-rw-r--r--  1 root root 17408 Aug 26 15:06 06-2d-07

-rw-r--r--  1 root root 13312 Aug 26 15:06 06-2f-02

-rw-r--r--  1 root root 12288 Aug 26 15:06 06-3a-09

-rw-r--r--  1 root root 21504 Aug 26 15:06 06-3c-03

-rw-r--r--  1 root root 14336 Aug 26 15:06 06-3d-04

-rw-r--r--  1 root root 13312 Aug 26 15:06 06-3e-04

-rw-r--r--  1 root root 11264 Aug 26 15:06 06-3e-06

-rw-r--r--  1 root root 15360 Aug 26 15:06 06-3e-07

-rw-r--r--  1 root root 28672 Aug 26 15:06 06-3f-02

-rw-r--r--  1 root root 20480 Aug 26 15:06 06-45-01

-rw-r--r--  1 root root 23552 Aug 26 15:06 06-46-01

-rw-r--r--  1 root root  4096 Aug 26 15:06 0f-00-07

-rw-r--r--  1 root root  6144 Aug 26 15:06 0f-00-0a

-rw-r--r--  1 root root  2048 Aug 26 15:06 0f-01-02

-rw-r--r--  1 root root  6144 Aug 26 15:06 0f-02-04

-rw-r--r--  1 root root  8192 Aug 26 15:06 0f-02-05

-rw-r--r--  1 root root  2048 Aug 26 15:06 0f-02-06

-rw-r--r--  1 root root  6144 Aug 26 15:06 0f-02-07

-rw-r--r--  1 root root  6144 Aug 26 15:06 0f-02-09

-rw-r--r--  1 root root  2048 Aug 26 15:06 0f-03-02

-rw-r--r--  1 root root  2048 Aug 26 15:06 0f-03-03

-rw-r--r--  1 root root  7168 Aug 26 15:06 0f-03-04

-rw-r--r--  1 root root 10240 Aug 26 15:06 0f-04-01

-rw-r--r--  1 root root  2048 Aug 26 15:06 0f-04-03

-rw-r--r--  1 root root  3072 Aug 26 15:06 0f-04-04

-rw-r--r--  1 root root  3072 Aug 26 15:06 0f-04-07

-rw-r--r--  1 root root  9216 Aug 26 15:06 0f-04-08

-rw-r--r--  1 root root  2048 Aug 26 15:06 0f-04-09

-rw-r--r--  1 root root  4096 Aug 26 15:06 0f-04-0a

-rw-r--r--  1 root root  3072 Aug 26 15:06 0f-06-02

-rw-r--r--  1 root root  6144 Aug 26 15:06 0f-06-04

-rw-r--r--  1 root root  2048 Aug 26 15:06 0f-06-05

-rw-r--r--  1 root root  2048 Aug 26 15:06 0f-06-08
```

(By the way, the file 06-3c-03 is the microcode file for my particular CPU: Family 06h, Model 03Ch, Stepping 03h, as determined from the CPU World Web site.) 

Then I copied to the boot directory the cpio file created when I merged the packages:

```
# cp /lib/firmware/microcode.cpio /boot/
```

Then I added an initrd line to /boot/grub/grub.cfg as shown below:

```
# grep -B 15 -A 1 initrd /boot/grub/grub.cfg

### BEGIN /etc/grub.d/10_linux ###

menuentry 'Gentoo GNU/Linux' --class gentoo --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-525a90f1-8ad2-44a3-ade3-20f18a0a9595' {

        load_video

        insmod gzio

        insmod part_msdos

        insmod ext2

        set root='hd0,msdos1'

        if [ x$feature_platform_search_hint = xy ]; then

          search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1  f6ffc085-66fe-4bbe-b080-cec355749f85

        else

          search --no-floppy --fs-uuid --set=root f6ffc085-66fe-4bbe-b080-cec355749f85

        fi

        echo    'Loading Linux 3.18.11-gentoo ...'

        linux   /vmlinuz-3.18.11-gentoo root=/dev/sda5 ro  drm_kms_helper.edid_firmware=edid/1920x1080_Clevo_W230SS.bin i915.modeset=1 rcutree.rcu_idle_gp_delay=1

        initrd /microcode.cpio

}
```

After rebooting:

```
# grep microcode /proc/cpuinfo

microcode       : 0x1c

microcode       : 0x1c

microcode       : 0x1c

microcode       : 0x1c

microcode       : 0x1c

microcode       : 0x1c

microcode       : 0x1c

microcode       : 0x1c

# dmesg | grep microcode

[    0.000000] CPU0 microcode updated early to revision 0x1c, date = 2014-07-03

[    0.049968] CPU1 microcode updated early to revision 0x1c, date = 2014-07-03

[    0.065070] CPU2 microcode updated early to revision 0x1c, date = 2014-07-03

[    0.080101] CPU3 microcode updated early to revision 0x1c, date = 2014-07-03

[    0.268736] microcode: CPU0 sig=0x306c3, pf=0x10, revision=0x1c

[    0.268838] microcode: CPU1 sig=0x306c3, pf=0x10, revision=0x1c

[    0.268935] microcode: CPU2 sig=0x306c3, pf=0x10, revision=0x1c

[    0.269034] microcode: CPU3 sig=0x306c3, pf=0x10, revision=0x1c

[    0.269131] microcode: CPU4 sig=0x306c3, pf=0x10, revision=0x1c

[    0.269230] microcode: CPU5 sig=0x306c3, pf=0x10, revision=0x1c

[    0.269329] microcode: CPU6 sig=0x306c3, pf=0x10, revision=0x1c

[    0.269448] microcode: CPU7 sig=0x306c3, pf=0x10, revision=0x1c

[    0.269570] microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba
```

Note that the line 'initrd /lib/firmware/microcode.cpio' in grub.cfg does not work for me. It has to be 'initrd /microcode.cpio' and the file has to be in /boot/:

```
# ls /boot

System.map-3.18.11-gentoo  config-3.18.11-gentoo  grub  lost+found  microcode.cpio  vmlinuz-3.18.11-gentoo
```

----------

## bszente

 *Fitzcarraldo wrote:*   

> In the Gentoo amd64 installation on my Clevo W230SS laptop I don't use an initramfs either.
> 
> In this case should the path specified in CONFIG_INITRAMFS_SOURCE be relative or absolute? In other words, should it be specified as CONFIG_INITRAMFS_SOURCE="/lib/firmware/microcode.cpio" as SpanKY wrote in Comment #41 of Bug Report #528712, or should it be specified as CONFIG_INITRAMFS_SOURCE="/microcode.cpio"? The reason I ask is because early microcode updating works for me if I leave CONFIG_INITRAMFS_SOURCE="", copy the microcode cpio file to /boot/ and add the line 'initrd /microcode.cpio' to grub.cfg as explained in detail below.
> 
> 

 

The CONFIG_INITRAMFS_SOURCE should be absolute, because it used at kernel build time. In the kernel build process that particular cpio file will be embedded in the kernel image itself. It has nothing to do with the initrd GRUB directive.

Your setup is working, because with CONFIG_INITRAMFS_SOURCE="" the kernel build process generates a dummy cpio archive (see /usr/src/linux/usr/initramfs_data.cpio.* file). Now the trick is that this archive contains the following files:

```
drwxr-xr-x   2 root     root            0 Aug 25 00:01 dev

crw-------   1 root     root       5,   1 Aug 25 00:01 dev/console

drwx------   2 root     root            0 Aug 25 00:01 root

```

Next, you specified for GRUB that it should load an external initramfs file from the boot partition, which is that microcode.cpio file. When your system boots, Grub loads this microcode.cpio file, but the kernel already has that embedded minimal cpio archive with /dev and /dev/console. Those two CPIO archives (the external microcode.cpio and embedded initramfs_data.cpio) are "merged", this is why it works for you. Will look like this:

```

drwxr-xr-x   2 root     root            0 Aug 25 00:01 dev

crw-------   1 root     root       5,   1 Aug 25 00:01 dev/console

drwxr-xr-x   2 root     root            0 Aug 18 21:03 kernel

drwxr-xr-x   2 root     root            0 Aug 18 21:03 kernel/x86

drwxr-xr-x   2 root     root            0 Aug 18 21:03 kernel/x86/microcode

-rw-r--r--   1 root     root       662528 Aug 18 21:03 kernel/x86/microcode/GenuineIntel.bin

drwx------   2 root     root            0 Aug 25 00:01 root

```

However my question was if including directly the microcode.cpio in kernel (CONFIG_INITRAMFS_SOURCE="/lib/firmware/microcode.cpio"), when that dummy cpio archive with /dev/ and /dev/console is NOT generated, should result in kernel panic or not? According to SpanKY it should not, it should boot properly. This is what I want to find out. How it is working for him?  :Smile:  Can you please try this? Thanks.

----------

## frostschutz

I am using a builtin initramfs (regular initramfs as handles mdadm, luks, lvm, ...).

For early microcode loading I'm passing a microcode as initrd in GRUB.

https://wiki.gentoo.org/wiki/Intel_microcode#Early_Microcode

early microcode is necessary for intel haswell where changing microcode also changes cpu flags - which no one can really handle when the system is already running.

early microcode is special, there is no code in the microcode initrd that would contain a tool or any instruction to load microcode - the kernel does that by itself - before everything else, even before it executes the built-in initramfs.

----------

## bszente

Hi!

 *frostschutz wrote:*   

> I am using a builtin initramfs (regular initramfs as handles mdadm, luks, lvm, ...).
> 
> For early microcode loading I'm passing a microcode as initrd in GRUB.
> 
> https://wiki.gentoo.org/wiki/Intel_microcode#Early_Microcode
> ...

 

I know that the way you described works, because you must have the proper initramfs structure in the embedded initramfs (i.e. /dev/console is not missing form the initramfs, right? check /usr/src/linux/usr/initramfs_data.cpio.* content).

If one embed in kernel ONLY the CONFIG_INITRAMFS_SOURCE="/lib/firmware/microcode.cpio initramfs WITHOUT any other external initramfs  should the kernel boot properly? According to SpanKY yes, but I could not managed to do it  :Smile:  This is what I want to figure out, how is that possible. See my first post, question 1.

----------

## Fitzcarraldo

bszente, in order to answer your question I rebuilt my kernel with CONFIG_INITRAMFS_SOURCE="/lib/firmware/microcode.cpio", deleted the line 'initrd /microcode' from grub.cfg, deleted the file /boot/microcode.cpio and rebooted. The kernel panicked, and the last two console lines were as follows:

```
[    3.142079] drm_kms_helper: panic occurred, switching back to text console

[    3.142879] ---[ end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(8,5)
```

Unless SpanKY explains how he managed to get the procedure he gave in Bug Report #528712, Comment #41 to work, it seems the normal behaviour when applying the steps he gave would be for the kernel to panic. Even Gentoo developer Daniel Pielmeier experienced a kernel panic when he applied SpanKY's steps (Bug Report #528712, Comment #54).

I have reverted to using CONFIG_INITRAMFS_SOURCE="", copying /lib/firmware/microcode.cpio to /boot/microcode.cpio again and re-adding the line 'initrd /microcode.cpio' in grub.cfg.

If you ever find out how to get SpanKY's steps to work, please let us know!

----------

## frostschutz

 *bszente wrote:*   

> If one embed in kernel ONLY the CONFIG_INITRAMFS_SOURCE="/lib/firmware/microcode.cpio initramfs WITHOUT any other external initramfs  should the kernel boot properly?

 

I would expect it to work. If it boots with/out initramfs (because you don't need one?), if the options are set correctly (microcode loading builtin and early option enabled), and if the microcode.cpio is built correctly, as explained in the wiki article for early microcode loading I linked to. But I can not easily try it on my fully encrypted system. The case of not needing initramfs (apart for the microcode) simply does not exist on any on my machines.

If it does not work it would mean that whatever special handling the kernel has for microcode only exists for externally passed data, not for builtin. Although that seems odd to me. It might be possible since not many people use the builtin stuff.

----------

## bszente

 *frostschutz wrote:*   

>  *bszente wrote:*   If one embed in kernel ONLY the CONFIG_INITRAMFS_SOURCE="/lib/firmware/microcode.cpio initramfs WITHOUT any other external initramfs  should the kernel boot properly? 
> 
> I would expect it to work. If it boots with/out initramfs (because you don't need one?), if the options are set correctly (microcode loading builtin and early option enabled), and if the microcode.cpio is built correctly, as explained in the wiki article for early microcode loading I linked to.

 

The wiki link, you have given uses exclusive external early microcode cpio. Which will work, as I explained in my second post of this thread (the kernel build process generates that dummy minimal CPIO archive with /dev/console that will be embedded in kernel). See my second post for details.

Fitzcarraldo, thanks for your time testing the kernel panic. I will dig deeper  :Smile: 

----------

## hceline

 *frostschutz wrote:*   

>  *bszente wrote:*   If one embed in kernel ONLY the CONFIG_INITRAMFS_SOURCE="/lib/firmware/microcode.cpio initramfs WITHOUT any other external initramfs  should the kernel boot properly? 
> 
> I would expect it to work. If it boots with/out initramfs (because you don't need one?), if the options are set correctly (microcode loading builtin and early option enabled), and if the microcode.cpio is built correctly, as explained in the wiki article for early microcode loading I linked to. But I can not easily try it on my fully encrypted system. The case of not needing initramfs (apart for the microcode) simply does not exist on any on my machines.
> 
> If it does not work it would mean that whatever special handling the kernel has for microcode only exists for externally passed data, not for builtin. Although that seems odd to me. It might be possible since not many people use the builtin stuff.

 

I can testify that it does not work if you use efi-stub-loader with no initramfs to begin with.

For this to work on a system that boots without initramfs you have to use a boot loader like grub. Because the efi-stub-loader can not use external initramfs, and including an initramfs in the kernel does not behave the same way as loading one trough a bootloader.

----------

## frostschutz

Some people here seem to be talking about adding it as builtin firmware instead of builtin initramfs http://comments.gmane.org/gmane.linux.kernel/1898819

But I haven't tried whether that would work... and I might have misread it. It's not clear to me (from the documentation) that this is possible in any case.

----------

## bszente

There is a conclusion now. Please see the last comments of Gentoo bug #558192 for details. Thank you everybody for the help.

----------

## Fitzcarraldo

Presumably there is a downside to specifying the microcode blob in the kernel configuration file, though? You would then have to rebuild the kernel each time Intel upgraded the microcode blob and you merge a new version of the package sys-apps/microcode-data. Whereas if you were to adopt the approach given in my first post, you would only need to copy the new microcode.cpio file to the boot directory:

```
# cp /lib/firmware/microcode.cpio /boot/
```

Anyway, out of interest I decided to rebuild the kernel to embed the microcode blob (I therefore also removed the line 'initrd /microcode.cpio' from grub.cfg).

```
Device Drivers  --->

    Generic Driver Options  --->

        (intel-ucode/06-3c-03)    External firmware blobs to build into the kernel binary

        (/lib/firmware) Firmware blobs root directory
```

```
# uname -r

3.18.11-gentoo
```

However the CPU microcode does not get updated when I reboot and, for some reason, my wired network connection no longer works (although my Wi-Fi connection still does).

If I use the file /lib/firmware/intel-ucode/06-3c-03 to create a file /boot/microcode.cpio manually, the CPU microcode is correctly updated at boot if I add the command 'initrd /microcode.cpio' in grub.cfg, so I know the file /lib/firmware/intel-ucode/06-3c-03 is the correct microcode blob.

What precisely is one supposed to enter in '() External firmware blobs to build into the kernel binary'?

----------

## bszente

 *Fitzcarraldo wrote:*   

> Presumably there is a downside to specifying the microcode blob in the kernel configuration file, though? You would then have to rebuild the kernel each time Intel upgraded the microcode blob and you merge a new version of the package sys-apps/microcode-data. Whereas if you were to adopt the approach given in my first post, you would only need to copy the new microcode.cpio file to the boot directory:
> 
> ```
> # cp /lib/firmware/microcode.cpio /boot/
> ```
> ...

 

Yes, I know it works that way, but I cannot/want to use GRUB and external Initramfs.

 *Fitzcarraldo wrote:*   

> Anyway, out of interest I decided to rebuild the kernel to embed the microcode blob (I therefore also removed the line 'initrd /microcode.cpio' from grub.cfg).
> 
> ```
> Device Drivers  --->
> 
> ...

 

Now that is a good question. I checked myself again, and you're right, the microcode does not get updated with this method. Apparently for AMD it works. I have to check the kernel sources to see if the intel microcode driver looks in embedded firmwares or just the initramfs file after the microcode?

PS: frostschutz's link is about this issue, perhaps that fix is not released yet. I will check it if it was merged into the kernel or not.

----------

## bszente

This is the relevant commit. This was released in kernel 4.2.0, previous kernels look in initramfs only.

----------

## bszente

So, I have upgraded to kernel 4.2.0 but I encountered this freeze even if I am on x86_64. So it seems, early microcode update from built in firmware does not work (yet). One must stick with (embedded) initramfs method. In embedded and no external initramfs case, don't forget to merge /lib/firmware/microcode.cpio with another CPIO archive that contains the necessary /root/ and /dev/console files.

----------

## bszente

Further information: Early microcode loading ignores microcode provided in embedded initramfs

So this means the following for Intel early microcode update: Embedded firmware method does not work (at least on my system I get that freeze bug - see my previous post).

 Built in initramfs method does not work at all.The only working solution is: external initramfs. If you cannot use external initramfs, than you are out of luck  :Smile: 

----------

## bszente

For those who use the EFI stub loader, the initrd= option must be used for external initramfs.

In my case, the EFI System Partition (ESP) is directly mounted to /boot:

```
/dev/sda1               /boot           vfat            noauto,noatime  0 2

```

I copied the microcode file to boot (ESP) partition:

```
# cp /lib/firmware/microcode.cpio /boot/
```

Then added the EFI boot entry like this:

```
# efibootmgr -c -L "Gentoo Linux" -l '\vmlinuz-4.2.0-gentoo-r1' -u 'root=/dev/md0 ro rootfstype=ext4 initrd=\microcode.cpio'

```

After reboot the microcode is updated:

```
$ dmesg | grep microcode

[    0.000000] microcode: CPU0 microcode updated early to revision 0x1c, date = 2014-07-03

[    0.000000] Command line: root=/dev/md0 ro rootfstype=ext4 snd-hda-intel.id=HDMI,PCH snd-hda-intel.index=1,0 initrd=\microcode.cpio

[    0.000000] Kernel command line: root=/dev/md0 ro rootfstype=ext4 snd-hda-intel.id=HDMI,PCH snd-hda-intel.index=1,0 initrd=\microcode.cpio

[    0.000000] microcode: CPU2 microcode updated early to revision 0x1c, date = 2014-07-03

[    0.000000] microcode: CPU4 microcode updated early to revision 0x1c, date = 2014-07-03

[    0.000000] microcode: CPU6 microcode updated early to revision 0x1c, date = 2014-07-03

[    0.000000] microcode: CPU0 sig=0x306c3, pf=0x10, revision=0x1c

[    0.000000] microcode: CPU1 sig=0x306c3, pf=0x10, revision=0x1c

[    0.000000] microcode: CPU2 sig=0x306c3, pf=0x10, revision=0x1c

[    0.000000] microcode: CPU3 sig=0x306c3, pf=0x10, revision=0x1c

[    0.000000] microcode: CPU4 sig=0x306c3, pf=0x10, revision=0x1c

[    0.000000] microcode: CPU5 sig=0x306c3, pf=0x10, revision=0x1c

[    0.000000] microcode: CPU6 sig=0x306c3, pf=0x10, revision=0x1c

[    0.000000] microcode: CPU7 sig=0x306c3, pf=0x10, revision=0x1c

[    0.000000] microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba

```

----------

