|Summary:||qemu -kernel vmlinuz -initrd initrd.img doesn't work|
|Product:||[Fedora] Fedora||Reporter:||Scott Tsai <scottt.tw>|
|Component:||qemu||Assignee:||David Woodhouse <dwmw2>|
|Status:||CLOSED RAWHIDE||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||6||CC:||bugzilla, hdegoede, markmc|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2007-04-01 19:28:16 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
|Bug Depends On:|
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?