WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [DOC] Update item on FAQ

To: Gerd Knorr <kraxel@xxxxxxx>
Subject: Re: [Xen-devel] [DOC] Update item on FAQ
From: Anthony Liguori <aliguori@xxxxxxxxxx>
Date: Fri, 18 Nov 2005 10:44:54 -0600
Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, mark.williamson@xxxxxxxxxxxx
Delivery-date: Fri, 18 Nov 2005 16:45:07 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <437D8A68.2090306@xxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <437CAB59.8060808@xxxxxxxxxx> <Prayer.1.0.16.0511172030470.1562@xxxxxxxxxxxxxxxxxxxxxx> <437D8A68.2090306@xxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla Thunderbird 1.0.7 (X11/20051013)
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



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

<Prev in Thread] Current Thread [Next in Thread>