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

> > 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 initramfs
is compressed - so you either have to glue the compressed initramfs and
the cpio with the microcode together (where the microcode has to go first).

On Wed, 2015-05-13 at 11:57 -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 successful use of "cpio -i < /boot/initrd.img" would suggest
not, I
don't think cpio knows how to decompress things by itself.

Ian.

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.

Shade and sweet water!

	Stephan

-- 
| Stephan Seitz          E-Mail: stse at fsing.rootsland.net |
| Public Keys: http://fsing.rootsland.net/~stse/keys.html |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3735 bytes
Desc: not available
URL:
<http://lists.alioth.debian.org/pipermail/pkg-xen-devel/attachments/20150514/75791c38/attachment.bin>

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.