From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [DOC] Update item on FAQ Date: Fri, 18 Nov 2005 10:44:54 -0600 Message-ID: <437E0506.6000108@us.ibm.com> References: <437CAB59.8060808@us.ibm.com> <437D8A68.2090306@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <437D8A68.2090306@suse.de> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Gerd Knorr Cc: xen-devel , mark.williamson@cl.cam.ac.uk List-Id: xen-devel@lists.xenproject.org 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 >