initrd change breaks binary compatibility

initrd change breaks binary compatibility

[John Levon]

This change in 3.0.3-testing-rc3:

changeset:   11728:30f13007be3f
user:        kfraser@localhost.localdomain
date:        Mon Oct 09 13:50:00 2006 +0100
files:       tools/libxc/xc_linux_build.c
description:
[XEND] No need to decompress the initrd when building a domain.

breaks binary compatibility. In particular, it breaks Solaris, which
expects both grub and xen to uncompress the initrd for us. And it does
seem odd to differ from grub's behaviour needlessly.

I don't know what causes the broken Linux initrd's that the commit
message refers to, but it seems they need to be fixed another way.

regards,
john

Re: initrd change breaks binary compatibility

[Anthony Liguori]

John Levon wrote:
> This change in 3.0.3-testing-rc3:
> 
> changeset:   11728:30f13007be3f
> user:        kfraser@localhost.localdomain
> date:        Mon Oct 09 13:50:00 2006 +0100
> files:       tools/libxc/xc_linux_build.c
> description:
> [XEND] No need to decompress the initrd when building a domain.
> 
> breaks binary compatibility. In particular, it breaks Solaris, which
> expects both grub and xen to uncompress the initrd for us. And it does
> seem odd to differ from grub's behaviour needlessly.
> 
> I don't know what causes the broken Linux initrd's that the commit
> message refers to, but it seems they need to be fixed another way.

I suspect that we're actually broken here.  I think the way we determine 
the uncompressed size (by reading the last couple bytes) is not 
something that can, in generally, be safely relied upon.

We could work around this by decompressing the initrd and dynamically 
expanding the buffer we're decompressing to as needed.

Regards,

Anthony Liguori

> regards,
> john

Re: Re: initrd change breaks binary compatibility

[Keir Fraser]

On 10/10/06 9:31 pm, "Anthony Liguori" <aliguori@us.ibm.com> wrote:

>> I don't know what causes the broken Linux initrd's that the commit
>> message refers to, but it seems they need to be fixed another way.
> 
> I suspect that we're actually broken here.  I think the way we determine
> the uncompressed size (by reading the last couple bytes) is not
> something that can, in generally, be safely relied upon.
> 
> We could work around this by decompressing the initrd and dynamically
> expanding the buffer we're decompressing to as needed.

Yes, we'll do this after 3.0.3-0. It's just a little bit too tricky to slip
in for the release. Unfortunately we have seen some (SLES9) initrd images
with this issue. Presumably they get built in a way that ends up padding
them to a multiple of a 'block' or something like that. It can be fixed by
laundering the initrd through gzip, of course.

 -- Keir

Re: Re: initrd change breaks binary compatibility

[Keir Fraser]

On 10/10/06 10:34 pm, "John Levon" <levon@movementarian.org> wrote:

>>> I suspect that we're actually broken here.  I think the way we determine
>>> the uncompressed size (by reading the last couple bytes) is not
>>> something that can, in generally, be safely relied upon.
>>> 
>>> We could work around this by decompressing the initrd and dynamically
>>> expanding the buffer we're decompressing to as needed.
>> 
>> Yes, we'll do this after 3.0.3-0. It's just a little bit too tricky to slip
>> in for the release.
> 
> Does this mean the current change will be reverted?

Yes, that's now done.

 -- Keir

Re: Re: initrd change breaks binary compatibility

[John Levon]

On Tue, Oct 10, 2006 at 09:42:11PM +0100, Keir Fraser wrote:

> >> I don't know what causes the broken Linux initrd's that the commit
> >> message refers to, but it seems they need to be fixed another way.
> > 
> > I suspect that we're actually broken here.  I think the way we determine
> > the uncompressed size (by reading the last couple bytes) is not
> > something that can, in generally, be safely relied upon.
> > 
> > We could work around this by decompressing the initrd and dynamically
> > expanding the buffer we're decompressing to as needed.
> 
> Yes, we'll do this after 3.0.3-0. It's just a little bit too tricky to slip
> in for the release.

Does this mean the current change will be reverted?

regards,
john