This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours

Bug 237879

Summary: qemu -kernel vmlinuz -initrd initrd.img doesn't work
Product: [Fedora] Fedora Reporter: Daniel Berrange <berrange>
Component: kvmAssignee: Jeremy Katz <katzj>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: hdegoede, markmc
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-04-25 16:42:41 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Bug Depends On: 234681    
Bug Blocks:    

Description Daniel Berrange 2007-04-25 16:21:24 EDT
This problem also impacts the copy of the QEMU code which is in the KVM package&
is preventing libvirt/virt-manager from provisioning KVM hguests using an
initrd/kernel pair

+++ This bug was initially created as a clone of Bug #234681 +++

Description of problem:
qemu supports directly loading a linux kernel(-kernel) and an initial
ramdisk(-initrd) when emulating an i386. The initial ramdisk loading part does
not work in the current extras build.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. sudo qemu -kernel /boot/vmlinuz-2.6.20-1.2933.fc6 -initrd
/boot/initrd-2.6.20-1.2933.fc6.img -hda /bin/true

Actual results:
The kernel running inside qemu prints:
checking if image is isn't (bad gzip magic numbers); looks like
an initrd

Expected results:
Successful initramfs load.

Additional info:
The test case above works after the following patch.
It changes INITRD_LOAD_ADDR in hw/pc.c to make qemu load initial ramdisks at a
higher address.

--- hw/pc.c.orig        2007-02-06 07:01:54.000000000 +0800
+++ hw/pc.c     2007-03-31 13:46:41.000000000 +0800
@@ -32,7 +32,7 @@
 #define LINUX_BOOT_FILENAME "linux_boot.bin"
 #define KERNEL_LOAD_ADDR     0x00100000
-#define INITRD_LOAD_ADDR     0x00600000
+#define INITRD_LOAD_ADDR     0x00c00000
 #define KERNEL_PARAMS_ADDR   0x00090000
 #define KERNEL_CMDLINE_ADDR  0x00099000

-- Additional comment from on 2007-04-01 04:10 EST --
I've been looking at upstream CVS, and I think that the patch that we actually
want / need for this is:

Scott, can you test this?

David, is it ok with you if I do a new version with this patch once Scott has
confirmed that this fixed his problem?

-- Additional comment from on 2007-04-01 04:14 EST --
*** Bug 191488 has been marked as a duplicate of this bug. ***

-- Additional comment from on 2007-04-01 10:21 EST --
Hans, thanks a lot for the prompt response on a weekend.

The linked to patch works.
I'll attach a slightly modified patch that cleanly applies to qemu-0.9.0 where
the ram_addr_t type was not yet introduced.

-- Additional comment from on 2007-04-01 10:23 EST --
Created an attachment (id=151390)
initrd loading patch for 0.9.0

-- Additional comment from on 2007-04-01 10:48 EST --
(In reply to comment #1)
> David, is it ok with you if I do a new version with this patch once Scott has
> confirmed that this fixed his problem?

Absolutely; thanks.

-- Additional comment from on 2007-04-01 15:28 EST --
I've just finished building 0.9.0-2, which fixes this. It should show up in
extras-devel with the next push.

David, we might want to build this version for FC-6 too, but I'll leave that up
to you (to decide and do).
Comment 1 Jeremy Katz 2007-04-25 16:42:41 EDT
Committing and building for kvm-19-2