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

[Ian Campbell <ijc@debian.org>]

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@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@dagon:tmp$ find iucode-tool/ | cpio -o > normal.cpio
828 blocks
ijc@dagon:tmp$ find iucode-tool/ | cpio -o -H newc > newc.cpio
840 blocks
ijc@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@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@dagon:tmp$ file initrd.real 
        initrd.real: gzip compressed data, last modified: Sun Apr 19 16:31:17 2015, from Unix
        ijc@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.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel