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 - 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


Attachments (Terms of Use)
initrd loading patch for 0.9.0 (deleted)
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.