On Mon, Jan 11, 2010 at 5:27 PM, Jeff Mahoney <jeffm@suse.com> wrote:
I don't really think that's the best place to start though. I'm not sure which order pvgrub tries kernel types, but it may be that it's decided that it's not a compressed vmlinux already.
That's a good question ... Looking now at this recent patch, http://xenbits.xen.org/staging/xen-unstable.hg?rev/a687c4d35fdd IIUC, the order of attempted decompression is: gzip, bzip, then lzma ... + ret = xc_dom_try_gunzip(dom, &dom->kernel_blob, &dom->kernel_size); ... + ret = xc_try_bzip2_decode(dom, &dom->kernel_blob, &dom->kernel_size); ... + ret = xc_try_lzma_decode(dom, &dom->kernel_blob, &dom->kernel_size); but that's AFTER the error i see ("kernel is not a bzImage"), as a result of earlier code, - if ( verbose ) - xc_dom_panic(XC_INVALID_KERNEL, "%s: kernel is not a bzImage\n", - __FUNCTION__); + xc_dom_panic(XC_INVALID_KERNEL, "%s: kernel is not a bzImage\n", + __FUNCTION__); Given your explanation above, and the apparent fact that AFTER that panic occurs, at (ENTER) at console the boot *continues* to completion, I think I'm not seeing a decompression problem at all, but rather something earlier ... So, I've got something to work with. IN any case, I'm still unsure WHY the -xen and !-xen cases are built differently,
arch type name x86-* compressed bzImage x86-xen compressed vmlinuz
Thanks. -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org