From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [Fwd: Installing from distribution CDs] Date: Tue, 08 Feb 2005 19:00:15 -0600 Message-ID: <4209609F.6010404@us.ibm.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit In-Reply-To: Sender: xen-devel-admin@lists.sourceforge.net Errors-To: xen-devel-admin@lists.sourceforge.net List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , List-Archive: To: Ian Pratt Cc: Anthony Liguori , Jared Rhine , xen-devel@lists.sourceforge.net, ian.pratt@cl.cam.ac.uk List-Id: xen-devel@lists.xenproject.org I posted a patch on 2/4. Does anyone have a problem with that patch? Regards, Ian Pratt wrote: >Have we got concensus about how to handle this? (and hence a definitive >patch). > >Requiring people to change there config command lines is probably OK >provided that we're making it closer to standard Linux behaviour. > >Ian > > > >>-----Original Message----- >>From: Anthony Liguori [mailto:anthony@codemonkey.ws] >>Sent: 03 February 2005 02:17 >>To: Ian Pratt >>Cc: Anthony Liguori; Jared Rhine; xen-devel@lists.sourceforge.net >>Subject: Re: [Xen-devel] [Fwd: Installing from distribution CDs] >> >>Ian Pratt wrote: >> >> >> >>>Thanks for looking into this. I wander if it's something to >>> >>> >>do with the >> >> >>>way xen packages up the module as an initrd for dom0? Maybe >>> >>> >>there's some >> >> >>>difference between an initrd and a ramdisk? >>> >>> >>> >>> >>Didn't have time this afternoon but I was able to look into >>it more this >>evening and I found the culprit. In arch/i386/kernel/setup.c >>there was >>the following line around L1363: >> >> ROOT_DEV = MKDEV(RAMDISK_MAJOR,0); >>/*old_decode_dev(ORIG_ROOT_DEV);*/ >> >>This defaults the root device to /dev/ram0 instead of trying >>to get it >>from the boot loader. I'm not sure why this there (perhaps a part of >>early development?). I've attached a patch that puts back the >>old_decode_dev call and the behavior becomes exactly what >>you'd expect: >>if no root= is specified, initrd still works but if /linuxrc >>exits you >>get a VFS error because no root= is specified. >> >>This is what Linux would normally do. >> >>It's very important to note though that applying this patch >>means that >>if people had ramdisk=... lines in their configs and didn't have >>root=/dev/ram0, their machines won't boot anymore. >> >>A solution would be to add an initrd option to the configuration file >>and have the ramdisk= option default the root device to /dev/ram0. >> >>I've tested this patch on a couple day old copy of xen-unstable. I'm >>curious to know what the source of this was though because I >>don't feel >>very comfortable with just restoring something that was >>obviously taken >>out for a reason.. >> >>Regards, >>Anthony Liguori >> >>Signed-off-by: Anthony Liguori >> >> >> > > > ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click