WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: Ian Pratt <m+Ian.Pratt@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] [Fwd: Installing from distribution CDs]
From: Anthony Liguori <anthony@xxxxxxxxxxxxx>
Date: Wed, 02 Feb 2005 20:16:36 -0600
Cc: Anthony Liguori <aliguori@xxxxxxxxxx>, Jared Rhine <jared@xxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxxx
Delivery-date: Thu, 03 Feb 2005 02:18:53 +0000
Envelope-to: xen+James.Bulpin@xxxxxxxxxxxx
In-reply-to: <A95E2296287EAD4EB592B5DEEFCE0E9D1236AB@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
List-archive: <http://sourceforge.net/mailarchive/forum.php?forum=xen-devel>
List-help: <mailto:xen-devel-request@lists.sourceforge.net?subject=help>
List-id: List for Xen developers <xen-devel.lists.sourceforge.net>
List-post: <mailto:xen-devel@lists.sourceforge.net>
List-subscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=subscribe>
List-unsubscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=unsubscribe>
References: <A95E2296287EAD4EB592B5DEEFCE0E9D1236AB@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-admin@xxxxxxxxxxxxxxxxxxxxx
User-agent: Mozilla Thunderbird 1.0 (X11/20041206)
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
--- linux-2.6.10-xen-sparse/arch/xen/i386/kernel/setup.c~       2005-01-25 
22:29:18.000000000 -0600
+++ linux-2.6.10-xen-sparse/arch/xen/i386/kernel/setup.c        2005-02-02 
18:54:52.722236000 -0600
@@ -1360,7 +1360,7 @@
                efi_enabled = 1;
 #endif
 
-       ROOT_DEV = MKDEV(RAMDISK_MAJOR,0); /*old_decode_dev(ORIG_ROOT_DEV);*/
+       old_decode_dev(ORIG_ROOT_DEV);
        drive_info = DRIVE_INFO;
        screen_info = SCREEN_INFO;
        edid_info = EDID_INFO;