I just grabbed the F21 beta cloud image from:
http://download.fedoraproject.org/pub/fedora/linux/releases/test/21-Beta/Clo...
It looks like the initramfs on this image is corrupt; it appears to be an uncompressed CPIO archive with truncated content:
# zcat initramfs-3.17.1-302.fc21.x86_64.img | cpio -it gzip: initramfs-3.17.1-302.fc21.x86_64.img: not in gzip format cpio: premature end of archive
# cpio -it < initramfs-3.17.1-302.fc21.x86_64.img . kernel kernel/x86 kernel/x86/microcode kernel/x86/microcode/AuthenticAMD.bin early_cpio 44 blocks
If I generate a new image with 'dracut -f', I get something that looks a lot more sane...
# dracut -f # zcat initramfs-3.17.1-302.fc21.x86_64.img | cpio -it [...671 lines of output...]
The image still boots correctly in my OpenStack environment but I suspect this will cause problems for someone.
On Tue, Nov 11, 2014 at 12:17 PM, Lars Kellogg-Stedman lars@redhat.com wrote:
I just grabbed the F21 beta cloud image from:
http://download.fedoraproject.org/pub/fedora/linux/releases/test/21-Beta/Clo...
It looks like the initramfs on this image is corrupt; it appears to be an uncompressed CPIO archive with truncated content:
# zcat initramfs-3.17.1-302.fc21.x86_64.img | cpio -it gzip: initramfs-3.17.1-302.fc21.x86_64.img: not in gzip format cpio: premature end of archive
# cpio -it < initramfs-3.17.1-302.fc21.x86_64.img . kernel kernel/x86 kernel/x86/microcode kernel/x86/microcode/AuthenticAMD.bin early_cpio 44 blocks
That's actually showing the early microcode payload that is used by the kernel. It's prepended to the normal initramfs. What does lsinitrd have for output? It should look something like:
[jwboyer@lando linux]$ lsinitrd /boot/initramfs-3.17.2-300.fc21.x86_64.img Image: /boot/initramfs-3.17.2-300.fc21.x86_64.img: 18M ======================================================================== Early CPIO image ======================================================================== drwxr-xr-x 3 root root 0 Oct 30 14:26 . -rw-r--r-- 1 root root 2 Oct 30 14:26 early_cpio drwxr-xr-x 3 root root 0 Oct 30 14:26 kernel drwxr-xr-x 3 root root 0 Oct 30 14:26 kernel/x86 drwxr-xr-x 2 root root 0 Oct 30 14:26 kernel/x86/microcode -rw-r--r-- 1 root root 19456 Oct 30 14:26 kernel/x86/microcode/GenuineIntel.bin ======================================================================== Version: dracut-038-30.git20140903.fc21
Arguments: -f
dracut modules: bash i18n <lots of output after>
If it doesn't look like that, then something is indeed odd.
If I generate a new image with 'dracut -f', I get something that looks a lot more sane...
# dracut -f # zcat initramfs-3.17.1-302.fc21.x86_64.img | cpio -it [...671 lines of output...]
The image still boots correctly in my OpenStack environment but I suspect this will cause problems for someone.
Could you fpaste that output somewhere? Dracut should still default to creating an initramfs with the early ucode payload.
josh
On Tue, Nov 11, 2014 at 12:24:02PM -0500, Josh Boyer wrote:
If it doesn't look like that, then something is indeed odd.
The output of "lsinitrd" does, indeed, look more sane...but now I am confused by the fact that running "dracut -f" does not seem to result in the same thing (an initramfs image with the early microcode stuff prepended).
For reference, here is "lsinitrd" after first booting the image:
http://chunk.io/f/020888d2bd174f98b181449f19695569
And here is "lsinitrd" after running "dracut -f":
http://chunk.io/f/508cc5da54f24a28bf55ff04b68e6b88
On Tue, Nov 11, 2014 at 1:10 PM, Lars Kellogg-Stedman lars@redhat.com wrote:
On Tue, Nov 11, 2014 at 12:24:02PM -0500, Josh Boyer wrote:
If it doesn't look like that, then something is indeed odd.
The output of "lsinitrd" does, indeed, look more sane...but now I am confused by the fact that running "dracut -f" does not seem to result in the same thing (an initramfs image with the early microcode stuff prepended).
OK, I think I figured this out.
The images created in koji have the microcode_ctl package installed. That is what provides the microcode, so when the initramfs is created it has the early ucode prepended. The cloud image itself, however, does not have microcode_ctl so when dracut -f is run it can't include the microcode. That's fine in a cloud image because the host OS/kernel should be doing the microcode loading anyway on the physical CPUs.
I think everything is working fine here.
josh
-
Josh Boyer -
Lars Kellogg-Stedman