Xen devel - Oct 2006 - initrd change breaks binary compatibility

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

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

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

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

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



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

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



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

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

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel