Bug 234681 - qemu -kernel vmlinuz -initrd initrd.img doesn't work
Summary: qemu -kernel vmlinuz -initrd initrd.img doesn't work
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: qemu
Version: 6
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: David Woodhouse
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 191488 (view as bug list)
Depends On:
Blocks: 237879
TreeView+ depends on / blocked
 
Reported: 2007-03-31 05:48 UTC by Scott Tsai
Modified: 2007-11-30 22:12 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2007-04-01 19:28:16 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
initrd loading patch for 0.9.0 (2.59 KB, patch)
2007-04-01 14:23 UTC, Scott Tsai
no flags Details | Diff

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?


Note You need to log in before you can comment on or make changes to this bug.