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):
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
The kernel running inside qemu prints:
checking if image is initramfs...it isn't (bad gzip magic numbers); looks like
Successful initramfs load.
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
--- 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
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?
*** Bug 191488 has been marked as a duplicate of this bug. ***
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.
Created attachment 151390 [details]
initrd loading patch for 0.9.0
(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?
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).
I just ran into this bug. Why is the fix still only in RAWHIDE?