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