[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [Fwd: Installing from distribution CDs]
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@xxxxxxxxxxxxx] Sent: 03 February 2005 02:17To: 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 todo with theway xen packages up the module as an initrd for dom0? Maybethere's someDidn'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:difference between an initrd and a ramdisk?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 _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |