RE: [Xen-devel] [Fwd: Installing from distribution CDs]

["Ian Pratt" <m+Ian.Pratt@xxxxxxxxxxxx>]

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@xxxxxxxxxxxxx] 
> Sent: 03 February 2005 02:17
> To: Ian Pratt
> Cc: Anthony Liguori; Jared Rhine; xen-devel@xxxxxxxxxxxxxxxxxxxxx
> 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_ide95&alloc_id396&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel