[DOC] Update item on FAQ

[DOC] Update item on FAQ

[Anthony Liguori]

It's not quite clear how to go about this so hopefully whoever maintains 
the FAQ is on this list.

As part of closing bug #156, it would be nice to add a sentence on item 
4.8 (The initrd that came with my distro does not...) to include the 
following sentences:

"Some distros (notably SLES9) have a mkinitrd that adds garbage to the 
end of the initrd.  These initrds will not work with Xen.  To correct 
this problem, you should gunzip the initrd, and then gzip it again."

Thanks,

Anthony Liguori

Re: [DOC] Update item on FAQ

[M.A. Williamson]

>As part of closing bug #156, it would be nice to add a sentence on item 
>4.8 (The initrd that came with my distro does not...) to include the 
>following sentences:
>
>"Some distros (notably SLES9) have a mkinitrd that adds garbage to the 
>end of the initrd.  These initrds will not work with Xen.  To correct 
>this problem, you should gunzip the initrd, and then gzip it again."

!?!?!

What's in the garbage?  Presumably it's there for some reason?  *intrigued*

Cheers,
Mark

>
>Thanks,
>
>Anthony Liguori
>
>_______________________________________________
>Xen-devel mailing list
>Xen-devel@lists.xensource.com
>http://lists.xensource.com/xen-devel
>

Re: [DOC] Update item on FAQ

[Gerd Knorr]

>> "Some distros (notably SLES9) have a mkinitrd that adds garbage to the 
>> end of the initrd.  These initrds will not work with Xen.  To correct 
>> this problem, you should gunzip the initrd, and then gzip it again."
> 
> !?!?!
> 
> What's in the garbage?  Presumably it's there for some reason?

Sure it is, it is the image for the fancy console screen.  Doesn't hurt 
when it isn't present.  And as vesafb doesn't work with xenified linux 
kernels it isn't used anyway.  Easiest way to permanently get rid of it 
is "rpm -e bootsplash" (i.e. mkinitrd will stop appending the image to 
the initrd then).  Nevertheless I don't see why it causes trouble, the 
domain builder should simply take the ramdisk blob and pass it as-is to 
the kernel, no?

   Gerd

Re: [DOC] Update item on FAQ

[Anthony Liguori]

Gerd Knorr wrote:

>>> "Some distros (notably SLES9) have a mkinitrd that adds garbage to 
>>> the end of the initrd.  These initrds will not work with Xen.  To 
>>> correct this problem, you should gunzip the initrd, and then gzip it 
>>> again."
>>
>>
>> !?!?!
>>
>> What's in the garbage?  Presumably it's there for some reason?
>
>
> Sure it is, it is the image for the fancy console screen.  Doesn't 
> hurt when it isn't present.  And as vesafb doesn't work with xenified 
> linux kernels it isn't used anyway.

Ah, that makes sense.  Perhaps it's common enough then that we should 
work around it.

> Easiest way to permanently get rid of it is "rpm -e bootsplash" (i.e. 
> mkinitrd will stop appending the image to the initrd then).  
> Nevertheless I don't see why it causes trouble, the domain builder 
> should simply take the ramdisk blob and pass it as-is to the kernel, no?

Unfortunately it doesn't.  It actually decompresses the initrd before 
passing it to the kernel.  I'm not sure why we decompress it, anyone 
know why?

Regards,

Anthony Liguori

>   Gerd
>

Re: [DOC] Update item on FAQ

[Molle Bestefich]

Gerd Knorr wrote:
> Nevertheless I don't see why it causes trouble, the domain builder
> should simply take the ramdisk blob and pass it as-is to the kernel, no?

Another thing that's broken is initramfs (cpio) images.
Results in "RAMDISK: Couldn't find valid RAM disk image starting at
0", every time.

Anthony Liguori wrote:
> It actually decompresses the initrd before passing it to the kernel.

Presumably that's also why initramfs images doesn't work.
Extremely unhelpful of Xen to not at least bark out an error message
if un-gzipping fails.

(I've spent 4-5 hours today just looking at the darn thing, trying to
figure out why there's no RAM disk image at 0.  I live, I learn,
although that is a couple of hours spent in frustration that I'd like
to have back ;-).  Perhaps you guys could help some other poor lusers
out by changing this behaviour.)

Re: [DOC] Update item on FAQ

[Charles Duffy]

Molle Bestefich wrote:
> Gerd Knorr wrote:
> 
>>Nevertheless I don't see why it causes trouble, the domain builder
>>should simply take the ramdisk blob and pass it as-is to the kernel, no?
> 
> 
> Another thing that's broken is initramfs (cpio) images.
> Results in "RAMDISK: Couldn't find valid RAM disk image starting at
> 0", every time.

No -- I've been using those with xen.unstable for quite some time, and 
they work fine. Linux copes nicely with these whether or not they're 
gzipped.

Well, sort of fine; they're very twitchy about the cpio format, but 
that's the case upstream as well. For instance, the cpio image 
*absolutely must* include . (as opposed to just containing the files 
under its root directory), and there are only two cpio format variants 
that are supported (I use newc).