Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

Bug 234681

Summary: qemu -kernel vmlinuz -initrd initrd.img doesn't work
Product: [Fedora] Fedora Reporter: Scott Tsai <scottt.tw>
Component: qemuAssignee: David Woodhouse <dwmw2>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: 6CC: bugzilla, hdegoede, markmc
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-04-01 19:28:16 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 237879    
Attachments:
Description Flags
initrd loading patch for 0.9.0 none

Description Scott Tsai 2007-03-31 05:48:23 UTC
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):
qemu-0.8.2-4.fc6

How reproducible:
always

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 initramfs...it 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

Comment 1 Hans de Goede 2007-04-01 08:10:32 UTC
I've been looking at upstream CVS, and I think that the patch that we actually
want / need for this is:
http://cvs.savannah.nongnu.org/viewcvs/qemu/hw/pc.c?root=qemu&r1=1.71&r2=1.72&makepatch=1&diff_format=u

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?


Comment 2 Hans de Goede 2007-04-01 08:14:42 UTC
*** Bug 191488 has been marked as a duplicate of this bug. ***

Comment 3 Scott Tsai 2007-04-01 14:21:39 UTC
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.

Comment 4 Scott Tsai 2007-04-01 14:23:24 UTC
Created attachment 151390 [details]
initrd loading patch for 0.9.0

Comment 5 David Woodhouse 2007-04-01 14:48:31 UTC
(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.



Comment 6 Hans de Goede 2007-04-01 19:28:16 UTC
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 7 Kasper Dupont 2007-06-12 20:04:40 UTC
I just ran into this bug. Why is the fix still only in RAWHIDE?