Bug 515831

(In reply to comment #0)

> Additional info:
> Fedora 11 installs just fine

Ah, that suggests its an F-12 bug then

Have we lost xen pv_ops support somehow or ... ?

From:

  http://www.redhat.com/archives/fedora-xen/2009-August/msg00001.html

  xc_dom_parse_image: called
  xc_dom_find_loader: trying ELF-generic loader ... failed
  xc_dom_find_loader: trying Linux bzImage loader ... failed
  xc_dom_find_loader: trying multiboot-binary loader ... failed
  xc_dom_core.c:495: panic: xc_dom_find_loader: no loader found

Okay, so it turns out the problem is

  # CONFIG_KERNEL_GZIP is not set
  # CONFIG_KERNEL_BZIP2 is not set
  CONFIG_KERNEL_LZMA=y

the change was introduced by:

  * Mon Jul 06 2009 Chuck Ebbert <cebbert>
  - Use LZMA for kernel compression on X86.

Xen's bzImage loaded can only handle compressed gzip, not compressed LZMA

Switching to LZMA means that Fedora kernels cannot be booted by any deployed or upstream versions of Xen; we really should switch this back to gzip

Moving back to F12Alpha - we can easily do this in time for Alpha

Okay, we had a bit of a discussion on #fedora-virt; updating here since it's on the alpha blocker list

The gist of the conversation was:

  - Switching from gzip to lzma means that Fedora 12 won't be usable on any
    currently existing xen deployments

  - This is analogous to the switch from vmlinuz to bzImage we made in Fedora 9,
    except there was a patch to support this upstream well in advance of the 
    change and this patch was at least adopted by RHEL in reasonable time

  - The difference here is that there isn't even upstream support yet, but we
    plan to resolve that

  - Suggestion is to delay switching to lzma until Fedora 13 so that upstream
    and enterprise distros have time to react

  - One argument against that is that Fedora shouldn't be held hostage to Xen's
    deficiencies, although since Fedora is changing an ABI here which was
    specifically added for Xen, I think it makes sense to give Xen time to catch
    up

  - Another argument is that lzma reduces the kernel size (e.g. vmlinuz 3.5M to
    2.8M) and this could help livecd, but I think that's a fairly minor size
    gain for dropping the ability to run on Xen

(In reply to comment #4)
> Okay, we had a bit of a discussion on #fedora-virt; updating here since it's on
> the alpha blocker list
> 
> The gist of the conversation was:
> 
>   - Switching from gzip to lzma means that Fedora 12 won't be usable on any
>     currently existing xen deployments
> 
>   - This is analogous to the switch from vmlinuz to bzImage we made in Fedora
> 9,
>     except there was a patch to support this upstream well in advance of the 
>     change and this patch was at least adopted by RHEL in reasonable time
> 
>   - The difference here is that there isn't even upstream support yet, but we
>     plan to resolve that
> 
>   - Suggestion is to delay switching to lzma until Fedora 13 so that upstream
>     and enterprise distros have time to react
> 
>   - One argument against that is that Fedora shouldn't be held hostage to Xen's
>     deficiencies, although since Fedora is changing an ABI here which was
>     specifically added for Xen, I think it makes sense to give Xen time to
> catch
>     up
> 
>   - Another argument is that lzma reduces the kernel size (e.g. vmlinuz 3.5M to
>     2.8M) and this could help livecd, but I think that's a fairly minor size
>     gain for dropping the ability to run on Xen  

Thanks Mark.  As we discussed earlier today on IRC, I am working on a patch to make the Xen domain builder understand bzip2 and lzma, which I will post upstream and for RHEL-5 when it's ready.  By delaying to F-13, that should give us time to get it into product, and give upstream time to get it in (maybe even in the stable 3.3 and 3.4 branches, depending on the invasiveness of the patch).

Chris Lalancette

At one point I had some patches to allow the domain builder to load a bzImage as-is and use its internal decompressor, specifically to deal with the case of the algorithm changing.  It turned out to be fairly complex in a pretty fragile piece of code, and there was general pushback because "the algorithm isn't changing" (about a year ago).

Incorporating lzma into the domain builder should be pretty straightforward, at least for usermode.  But I think the same libxc code is used by Xen for dom0 loading?

It would be nice, for completeness, to include support for the other possible algorithms too, though I'm not sure there's any reason to use them over lzma.

A build of the f12-alpha kernel with this disabled has been done.  We're testing it now for f12-alpha tagging.

Looks like kernel-2.6.31-0.125.4.2.rc5.git2.fc12 has been tagged and it contains this:

* Tue Aug 11 2009 Kyle McMartin <kyle>
- private-f12-2_6_31_rc5-imeanit: LZMA. OFF. I MEAN IT.

Just checking:

 - with the x86_64 kernel, the magic number is at offset 0x4069

   that's 0x200 + ((setup_sects=0x1e) * 0x200) + (payload_offset=0x269)

 - hexdump -C -n 2 -s 0x4069 vmlinuz-2.6.31-0.125.4.2.rc5.git2.fc12.x86_64
   00004069  1f 8b                                             |..|

 - hexdump -C -n 2 -s 0x4069 vmlinuz-2.6.31-0.118.rc5.fc12.x86_64
   00004069  5d 00                                             |].|

 - 1f 8b is gzip, 5d 00 is lzma

For anyone interested, I've filed a bz asking for lzma support in RHEL5 - bug #517049

This got disabled for the F12 Alpha build, but wasn't disabled in devel/ until now:

* Thu Aug 20 2009 Mark McLoughlin <markmc>
- Disable LZMA for xen (#515831)

Upstream xen now has support for lzma and bzip2. We're going to add these patches to Fedora 12 xen. See bug #518551

(In reply to comment #10)
> See bug #518551

Sorry, it's bug #518588