boot rEFInd with two initrd files?

[mcloaked]

There is currently an update to intel-ucode (version version intel-ucode 20140913-1) that will require loading an additional initrd file as well as the normal linux initial ramdisk file so that the microcode updates early in the boot cycle. Will rEFInd handle two initrd files in the config files? In which case can this be done in refind.conf and/or refind_linux.conf?

There is a discussion in the arch linux forum on this issue at:
https://bbs.archlinux.org/viewtopic.php?id=188252

Since the new version of intel-ucode is about to be released it is important to know how to deal with it since there is a particular issue for Haswell cpus which for some distributions will cause a system crash unless the updated microcode is used early in the boot process before the kernel loads.

[Roderick W. Smith]

Currently, if the refind_linux.conf file specifies an initrd file, the auto-detection is ignored. This is done to simplify matters for Arch, which uses one initrd for normal booting and one for emergency use, without kernel version numbers. If a change requires use of two initrd files per kernel in Arch Linux, then you should be able to simply specify them both in refind_linux.conf. If such a change is required in other distributions, I may need to update rEFInd. I'll keep my eye on developments.

[mcloaked]

If in the current refind_linux.conf there is a line such as:

"Boot Fallback to console" "root=PARTUUID=f4b79029-10cc-4272-8d57-7e491ccd28a1 rw rootfstype=ext4 add_efi_memmap initrd=/boot/initramfs-linux-fallback.img systemd.unit=multi-user.target"

then does this mean that with the new intel-ucode.img in place in /boot after the intel-ucode package has been updated to the new version (20140913), then all that "should" be required to boot this kernel with early microcode loading would be:

1)

"Boot Fallback to console" "root=PARTUUID=f4b79029-10cc-4272-8d57-7e491ccd28a1 rw rootfstype=ext4 add_efi_memmap initrd=/boot/intel-ucode.img initrd=/boot/initramfs-linux-fallback.img systemd.unit=multi-user.target"

or would the following work as well:

2)

"Boot Fallback to console" "root=PARTUUID=f4b79029-10cc-4272-8d57-7e491ccd28a1 rw rootfstype=ext4 add_efi_memmap initrd=/boot/intel-ucode.img /boot/initramfs-linux-fallback.img systemd.unit=multi-user.target"

I am presuming that it would have to be defined using a line such as 1) but that 2) would not work?

Would adding the initrd line to stanzas in refind.conf be likely to work as an alternative? Again if so are two separate initrd lines required in that case or would you have to have a single initrd line with the two .img files in a single line?

[Gene C]

I have bnen unable to get microcode to update. My initrd line is in the boot stanza in /boot/efi/EFI/refind/refind.conf. Could use some help.

I added a second initrd line:
...
volume "root"
loader /boot/vmlinuz-linux
initrd /boot/intel-ucode.img
initrd /boot/initramfs-linux.img

Using arch kernel 3.17.1-1. With older kernel it automatically updated firmware - now it does not.

Older kernel:
dmesg | egrep 'microcode|ucode'
[ 4.553588] microcode: CPU0 sig=0x306c3, pf=0x2, revision=0x12
...
[ 5.002911] microcode: CPU7 sig=0x306c3, pf=0x2, revision=0x12
[ 5.002922] microcode: CPU7 sig=0x306c3, pf=0x2, revision=0x12
[ 5.003649] microcode: CPU7 updated to revision 0x1a, date = 2014-05-23
[ 5.003678] microcode: Microcode Update Driver: v2.00 tigran@aivazian.fsnet.co.uk, Pe

New Kernel with extra initrd line:
dmesg | egrep 'microcode|ucode'
...
[ 0.382409] microcode: CPU7 sig=0x306c3, pf=0x2, revision=0x12
[ 0.382446] microcode: Microcode Update Driver: v2.00 tigran@aivazian.fsnet.co.uk, Peter Oruba

[Gene C]

Tried with 3.18-rc1 kernel and microcode driver compiled into kernel:
CONFIG_MICROCODE=y
CONFIG_MICROCODE_INTEL=y
CONFIG_MICROCODE_AMD=y
CONFIG_MICROCODE_OLD_INTERFACE=y
CONFIG_MICROCODE_INTEL_EARLY=y
CONFIG_MICROCODE_AMD_EARLY=y
CONFIG_MICROCODE_EARLY=y

dmesg | egrep microcode looks same as above - no 'updated' line

[mcloaked]

I don't know if the suggested script in the file at https://www.kernel.org/doc/Documentation/x86/early-microcode.txt 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?

[Gene C]

That would be a test - but as a work around / solution that would require changing the Arch kernel package to build the combined initrd but only when booting with refind (not sure even how to do that frankly)

However, it sounds like refind (like most other boot loader/managers) is capable of reading 2 initrds and treating them the same as a combined initrd. So it would be good if we can get refind to do this properly without changing the kernel package.

Or naybe it doesn't work with refind?

[mcloaked]

I have just updated my arch linux 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.

[mcloaked]

It does indeed seem that having two initrd files is parsed correctly and loaded properly if the dual initrd files are defined in the lines in refind_linux.conf but there are situations where it becomes not possible to have a single refind_linux.conf for two separate kernels in a single directory. Yet unless the syntax was incorrect tests with the dual initrd files for each kernel specified in the menuentry stanzas in refind.conf appears not to lead to early microcode loading where one of the initrd files is the new intel-ucode.img file.

One example is where the user has two different sets of kernels with their own respective initrd files in arch linux. For example if there is the stock arch kernel as well as a custom built kernel which the owner wishes to boot for specific tests named for the general custom kernel.

Clearly if all those files are in the same /boot directory and only a single refind_linux.conf is permitted in that directory then the only way to distinguish which initrd should be used with the stock or custom kernel would be to either use a pair of subdirectories such as /boot/custom/ and /boot/stock with a different refind_linux.conf in both directories - but in order to boot these presumably a set of suitable stanzas would need to be written into refind.conf

If that was the case then with the current latest version of refind would the stanzas defining the two sets of boot files honour the dual initrd image files separately in the two subdirectories during the boot process where the first initrd .img file was the new intel-ucode.img file?

Tests appear to show that using two initrd lines in the refind.conf menuentry stanzas appears not to work where two different kernels and their respective initrd files are all within /boot/

One possibility that might work in this particular case, where the entries for two different kernels are defined by a menuentry manual stanza, may be to define the two initrd files in the options section rather than in the main initial part of the stanza but that would need to be tested to see if it works?
Maybe this could be part of the help files/comments for setting up the manual stanzas?

It would be nice to have a solution in this particular use case.

[mcloaked]

I have just seen a confirmation that adding in the additional microcode initrd to the end of the options line in a manual stanza does indeed work properly:

https://bbs.archlinux.org/viewtopic.php?pid=1468931#p1468931

It is good to see that this approach works but I guess it should be documented.

[Roderick W. Smith]

Mcloaked, the vast majority of Linux distributions place numbered kernels in a single directory, and I wrote rEFInd's initrd-matching code with this standard in mind. Arch is extremely unusual in the way it places named kernels and initrds in a single directory. In the past, Arch's approach has been easily handled by rEFInd by specifying the initrd files in refind_linux.conf -- that is, by having one line refer to one initrd file and a second line refer to a second initrd file. Placing multiple kernels with multiple initrd files (and the possibility of passing multiple initrd files to a single kernel) pushes this approach past the breaking point -- I suppose you could still use initrd specifications in refind_linux.conf, but with multiple kernels, some combinations would work only with some kernels, so some options just wouldn't work right.

In that case, the best approach is likely to be to forget about auto-matching and instead write manual boot stanzas. These are much more flexible, but they must be created manually for each scenario. (I suppose you could write a script to do it, similar to the scripts that GRUB uses for this purpose, but then you're back at the limitations of a programming language vs. a human mind.)

[mcloaked]

Thanks for the reply, Rod. In fact we did manage to resolve the situation when we needed two initrd img files for each kernel (one for the main image and one for the Intel microcode image in the new Intel way of early loading microcode at the time of kernel load) - and for the refind_linux entries it was straightforward to include the necessary two initrd files as per:

"Boot to X" "root=PARTUUID=xxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx rw rootfstype=ext4 add_efi_memmap initrd=/boot/intel-ucode.img initrd=/boot/initramfs-linux.img systemd.unit=graphical.target"

and for manual stanzas the key ingredient was knowing that the initrd main image file goes in the initrd line but that the second initrd image definition goes into the options line as per a refind.conf stanza such as:

menuentry "Arch Linux" {
icon EFI/refind/icons/os_arch.icns
volume root
loader /boot/vmlinuz-linux
initrd /boot/initramfs-linux.img
options "rw root=UUID=xxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx PARTUUID=xxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx initrd=/boot/intel-ucode.img "
ostype Linux
}

It was the syntax for doing it in refind.conf that was not obvious and we tried adding both to the initrd line without success as well as trying both in the options line without success but knowing that one is alone in the initrd line and the other adds to the options line was the vital piece of information. It would be useful to add that to the documentation somewhere?

Anyway early microcode update now works with both methods just fine in rEFInd.