[Pkg-xen-devel] Bug#785187: Bug#785187: xen-hypervisor-4.5-amd64: Option ucode=scan is not working

[Ian Campbell]

On Thu, 2015-05-14 at 22:45 +0200, Stephan Seitz wrote:
> On Wed, May 13, 2015 at 11:57:55AM -0400, Konrad Rzeszutek Wilk wrote:
> >> > according to the documentation the option ucode=scan should tell XEN to
> >> > look for a microcode update in an uncompressed initrd.
> >> >
> >> > While I don’t use the Debian kernel the tools to generate the initrd are
> >> > part of Debian. The command „cpio -i < /boot/initrd.img-4.0.2-Dom0”
> >> > creates the directory structure „kernel/x86/microcode/GenuineIntel.bin”,
> >> > so I think the initrd is allright.
> >Is the initramfs compressed? The scanning code can't deal if the 
> 
> [stse at osgiliath]: file /boot/initrd.img-4.0.2-Dom0 
> /boot/initrd.img-4.0.2-Dom0: ASCII cpio archive (SVR4 with no CRC)
> 
> I don’t think the initrd is compressed.
> 
> http://lists.xen.org/archives/html/xen-users/2014-05/msg00053.html says 
> that I have to use „cpio -H newc” not „cpio -o c”, but I don’t know how 
> the Debian tools create the initrd.

The intel-microcode package contains:
/usr/share/initramfs-tools/hooks/intel_microcode
which will be called during initamfs generation.

It seems to call iucode_tool, from the iucode-tool package. That's a
binary tool which seems to include its own cpio writer implementation,
I've no idea if that is like a 'newc' or not.

However:
ijc at dagon:tmp$ find iucode-tool/ | cpio -o > normal.cpio
828 blocks
ijc at dagon:tmp$ find iucode-tool/ | cpio -o -H newc > newc.cpio
840 blocks
ijc at dagon:tmp$ file *.cpio
newc.cpio:   ASCII cpio archive (SVR4 with no CRC)
normal.cpio: cpio archive

So the fact that yours reports the same as newc.cpio makes me reasonably
confident it is in the correct form.

So I think the issue must be elsewhere.

In iucode_tool.c I found:
        /* Gross hack to work around a Linux kernel bug: for file
         * entries, force file data into a 16-byte alignment by
         * appending NULs to the file name.  Verified to be compatible
         * with GNU pax, and GNU cpio */
        s = (size) ? (16 - (*pos + bufsize) % 16) % 16 : 0;

I wonder if perhaps this confuses Xen? I doubt it somehow.

Here's an idea. First extract the real initrd from the back half of the
initrd:
        ijc at dagon:tmp$ cat /boot/initrd.img | ( cpio -t >&2 ; cat ) > initrd.real
        kernel
        kernel/x86
        kernel/x86/microcode
        kernel/x86/microcode/GenuineIntel.bin
        16 blocks
        ijc at dagon:tmp$ file initrd.real 
        initrd.real: gzip compressed data, last modified: Sun Apr 19 16:31:17 2015, from Unix
        ijc at dagon:tmp$ zcat initrd.real | cpio -t | head -n 5
        .
        etc
        etc/ld.so.conf.d
        etc/ld.so.conf.d/fakeroot-x86_64-linux-gnu.conf
        etc/ld.so.conf.d/x86_64-linux-gnu.conf

Now you can experiment with regenerating the ucode bit with whatever
commands are recommended and reconcatenating the two. If that works then
we know there is some incompatibility between iucode-tools's output and
Xen's cpio reader (could be a bug in either or both I think). 

Ian.