[Fwd: Installing from distribution CDs]

[Fwd: Installing from distribution CDs]

[Anthony Liguori]

[-- Attachment #1: Type: text/plain, Size: 238 bytes --]

Sorry, hit send instead of attach again.  Rest of patches included.
-- 
Anthony Liguori
Samba, Linux/Windows Interoperability
Linux Technology Center (LTC) - IBM Austin
E-mail: aliguori@us.ibm.com
Phone: (512) 838-1208
Tie Line: 678-1208

[-- Attachment #2: Forwarded message - Installing from distribution CDs --]
[-- Type: message/rfc822, Size: 6036 bytes --]

[-- Attachment #2.1.1: Type: text/plain, Size: 1924 bytes --]

Hi,

I recently tried to see what it would take in Xen to install a
distribution from a CD in domain > 0.  Here's my findings along with a
couple patches I used to find this.  These patches are proof of concepts
and quite ugly.

1) initrd support

Xen currently implements the ramdisk option which seems to simply pull
in a gzip'd file to a ramdisk and set that as the root.  Looking at the
initrd code in the kernel and reading through the man page, initrd is a
bit more complicated than that.

Among other things, the initrd process will check for a /linuxrc file
and execute it.  After execution, it will remount a new root and then
fall through to the normal init process.

SLES-9 at least uses linuxrc.  I imagine most distros do since it was
added specifically to help out distros.

2) CDROM support.  SLES-9 at least expects to have been booted from a
CDROM and looks for a /proc/sys/ entry to find out where that CDROM is. 
Right now Xen doesn't really support CDROMs.

The attached patches add /linuxrc to the init list (this will at least
let you get a bit into the installation process), add an old hack from
2.4 Xen to enable at least some response to MULTISESSION ioctls
(otherwise isofs won't mount the device), and also add a CDROM entry to
/proc/sys for hdc1.

A couple questions did come up though:

1) why isn't xen using the Linux initrd code?  The man page says that
initrd has unspecified features.  My fear is that some distros rely on
these features so reusing the initrd code would probably be best.

2) Have there been thoughts on how removable devices like CDROMs are
going to be supported?

BTW, you have to increase the ramdisk size to 64MB and add support for
minix to the kernel in order to boot off of  SLES cd.

Regards,

-- 
Anthony Liguori
Samba, Linux/Windows Interoperability
Linux Technology Center (LTC) - IBM Austin
E-mail: aliguori@us.ibm.com
Phone: (512) 838-1208
Tie Line: 678-1208

[-- Attachment #2.1.2: xen-sles9-fakecd.diff --]
[-- Type: text/x-patch, Size: 3433 bytes --]

diff -ur xen-2.0/linux-2.6.9-xen-sparse/drivers/xen/blkfront/vbd.c xen-2.0-new/linux-2.6.9-xen-sparse/drivers/xen/blkfront/vbd.c
--- xen-2.0/linux-2.6.9-xen-sparse/drivers/xen/blkfront/vbd.c	2005-01-03 21:46:11.000000000 -0600
+++ xen-2.0-new/linux-2.6.9-xen-sparse/drivers/xen/blkfront/vbd.c	2005-01-05 14:08:26.000000000 -0600
@@ -31,6 +31,8 @@
 
 #include "block.h"
 #include <linux/blkdev.h>
+#include <linux/sysctl.h>
+#include <linux/proc_fs.h>
 
 /*
  * For convenience we distinguish between ide, scsi and 'other' (i.e.
@@ -281,6 +283,98 @@
 	return NULL;
 }
 
+#define CDROM_STR_SIZE 1000
+static char info[CDROM_STR_SIZE];
+
+int cdrom_sysctl_info(ctl_table *ctl, int write, struct file * filp,
+                           void __user *buffer, size_t *lenp, loff_t *ppos)
+{
+        int pos;
+	
+	if (!*lenp || (*ppos && !write)) {
+		*lenp = 0;
+		return 0;
+	}
+
+	pos = sprintf(info,
+		      "CD-ROM information, Id: cdrom.c 3.20 2003/12/17\n"
+		      "\ndrive name:\t\thdc1\n"
+		      "drive speed:\t\t40\n"
+		      "drive # of slots:\t1\n"
+		      "Can close tray:\t\t0\n"
+		      "Can open tray:\t\t0\n"
+		      "Can lock tray:\t\t0\n"
+		      "Can change speed:\t0\n"
+		      "Can select disk:\t0\n"
+		      "Can read multisession:\t0\n"
+		      "Can read MCN:\t\t0\n"
+		      "Reports media changed:\t0\n"
+		      "Can play audio:\t\t0\n"
+		      "Can write CD-R:\t\t0\n"
+		      "Can write CD-RW:\t0\n"
+		      "Can read DVD:\t\t0\n"
+		      "Can write DVD-R:\t0\n"
+		      "Can write DVD-RAM:\t0\n"
+		      "Can read MRW:\t\t0\n"
+		      "Can write MRW:\t\t0\n"
+		      "Can write RAM:\t\t0\n"
+		      "\n");
+		
+        return proc_dostring(ctl, write, filp, buffer, lenp, ppos);
+}
+
+/* Place files in /proc/sys/dev/cdrom */
+static ctl_table cdrom_table[] = {
+	{
+		.ctl_name	= DEV_CDROM_INFO,
+		.procname	= "info",
+		.data		= &info, 
+		.maxlen		= CDROM_STR_SIZE,
+		.mode		= 0444,
+		.proc_handler	= &cdrom_sysctl_info,
+	},
+	{ .ctl_name = 0 }
+};
+
+static ctl_table cdrom_cdrom_table[] = {
+	{
+		.ctl_name	= DEV_CDROM,
+		.procname	= "cdrom",
+		.maxlen		= 0,
+		.mode		= 0555,
+		.child		= cdrom_table,
+	},
+	{ .ctl_name = 0 }
+};
+
+static ctl_table cdrom_root_table[] = {
+#ifdef CONFIG_PROC_FS
+	{
+		.ctl_name	= CTL_DEV,
+		.procname	= "dev",
+		.maxlen		= 0,
+		.mode		= 0555,
+		.child		= cdrom_cdrom_table,
+	},
+#endif /* CONFIG_PROC_FS */
+	{ .ctl_name = 0 }
+};
+static struct ctl_table_header *cdrom_sysctl_header;
+
+static void cdrom_sysctl_register(void)
+{
+	static int initialized;
+
+	if (initialized == 1)
+		return;
+
+	cdrom_sysctl_header = register_sysctl_table(cdrom_root_table, 1);
+	if (cdrom_root_table->ctl_name && cdrom_root_table->child->de)
+		cdrom_root_table->child->de->owner = THIS_MODULE;
+
+	initialized = 1;
+}
+
 /*
  * xlvbd_init_device - initialise a VBD device
  * @disk:              a vdisk_t describing the VBD
@@ -323,13 +417,20 @@
 		goto out;
 	}
 
+	printk(KERN_ALERT "XenLinux: init of %d %s\n", device, gd->disk_name);
+
 	if (VDISK_READONLY(xd->info))
 		set_disk_ro(gd, 1); 
 
+	if (!strcmp(gd->disk_name, "hdc1")) {
+	  xd->info = VDISK_TYPE_CDROM;
+	}
+
 	/* Some final fix-ups depending on the device type */
 	switch (VDISK_TYPE(xd->info)) { 
 	case VDISK_TYPE_CDROM:
 		gd->flags |= GENHD_FL_REMOVABLE | GENHD_FL_CD; 
+		cdrom_sysctl_register();
 		/* FALLTHROUGH */
 	case VDISK_TYPE_FLOPPY: 
 	case VDISK_TYPE_TAPE:

[-- Attachment #3: xen-sles9-linuxrc.diff --]
[-- Type: text/x-patch, Size: 378 bytes --]

--- xen-2.0-new/linux-2.6.9-xenU/init/main.c~	2005-01-11 14:43:52.000000000 -0600
+++ xen-2.0-new/linux-2.6.9-xenU/init/main.c	2005-01-11 14:44:46.168201000 -0600
@@ -745,6 +745,7 @@
 	if (execute_command)
 		run_init_process(execute_command);
 
+	run_init_process("/linuxrc");
 	run_init_process("/sbin/init");
 	run_init_process("/etc/init");
 	run_init_process("/bin/init");

[-- Attachment #4: xen-sles9-multisession.diff --]
[-- Type: text/x-patch, Size: 1079 bytes --]

diff -ur xen-2.0/linux-2.6.9-xen-sparse/drivers/xen/blkfront/blkfront.c xen-2.0-new/linux-2.6.9-xen-sparse/drivers/xen/blkfront/blkfront.c
--- xen-2.0/linux-2.6.9-xen-sparse/drivers/xen/blkfront/blkfront.c	2005-01-03 21:46:09.000000000 -0600
+++ xen-2.0-new/linux-2.6.9-xen-sparse/drivers/xen/blkfront/blkfront.c	2005-01-05 14:22:11.000000000 -0600
@@ -236,6 +236,7 @@
 int blkif_ioctl(struct inode *inode, struct file *filep,
                 unsigned command, unsigned long argument)
 {
+	int i;
     /*  struct gendisk *gd = inode->i_bdev->bd_disk; */
 
     DPRINTK_IOCTL("command: 0x%x, argument: 0x%lx, dev: 0x%04x\n",
@@ -247,6 +248,12 @@
         /* return ENOSYS to use defaults */
         return -ENOSYS;
 
+    case CDROMMULTISESSION:
+        DPRINTK("FIXME: support multisession CDs later\n");
+        for ( i = 0; i < sizeof(struct cdrom_multisession); i++ )
+            if ( put_user(0, (byte *)(argument + i)) ) return -EFAULT;
+        return 0;
+
     default:
         printk(KERN_ALERT "ioctl %08x not supported by Xen blkdev\n",
                command);

[-- Attachment #5: slesboot --]
[-- Type: text/plain, Size: 2870 bytes --]

#  -*- mode: python; -*-
#============================================================================
# Python configuration setup for 'xm create'.
# This script sets the parameters used when a domain is created using 'xm create'.
# You use a separate script for each domain you want to create, or 
# you can set the parameters for the domain on the xm command line.
#============================================================================

#----------------------------------------------------------------------------
# Kernel image file.
kernel = "/boot/vmlinuz-2.6.9-xenU"

# Optional ramdisk.
ramdisk = "/root/loader/initrd"

# The domain build function. Default is 'linux'.
#builder='linux'

# Initial memory allocation (in megabytes) for the new domain.
memory = 256

# A name for your domain. All domains must have different names.
name = "SLESBoot"

# Which CPU to start domain on? 
#cpu = -1   # leave to Xen to pick

#----------------------------------------------------------------------------
# Define network interfaces.

# Number of network interfaces. Default is 1.
#nics=1

# Optionally define mac and/or bridge for the network interfaces.
# Random MACs are assigned if not given.
#vif = [ 'mac=aa:00:00:00:00:11, bridge=xen-br0' ]

#----------------------------------------------------------------------------
# Define the disk devices you want the domain to have access to, and
# what you want them accessible as.
# Each disk entry is of the form phy:UNAME,DEV,MODE
# where UNAME is the device, DEV is the device name the domain will see,
# and MODE is r for read-only, w for read-write.

disk = [ 'phy:volumes/rhel3,sda1,w', 'file:/root/sles9.iso,hdc1,r' ]

#----------------------------------------------------------------------------
# Set the kernel command line for the new domain.
# You only need to define the IP parameters and hostname if the domain's
# IP config doesn't, e.g. in ifcfg-eth0 or via DHCP.
# You can use 'extra' to set the runlevel and custom environment
# variables used by custom rc scripts (e.g. VMID=, usr= ).

# Set if you want dhcp to allocate the IP address.
#dhcp="dhcp"
# Set netmask.
#netmask=
# Set default gateway.
#gateway=
# Set the hostname.
#hostname= "vm%d" % vmid

# Set root device.
#root = "/dev/sda2 rw"

# Root device for nfs.
#root = "/dev/nfs"
# The nfs server.
#nfs_server = '169.254.1.0'  
# Root directory on the nfs server.
#nfs_root   = '/full/path/to/root/directory'

# Sets runlevel 4.
extra = "4"

#----------------------------------------------------------------------------
# Set according to whether you want the domain restarted when it exits.
# The default is 'onreboot', which restarts the domain when it shuts down
# with exit code reboot.
# Other values are 'always', and 'never'.

#restart = 'onreboot'

#============================================================================

RE: [Fwd: Installing from distribution CDs]

[Ian Pratt]

Anthony, I don't understand the need for the following patch:

--- xen-2.0-new/linux-2.6.9-xenU/init/main.c~	2005-01-11
14:43:52.000000000 -0600
+++ xen-2.0-new/linux-2.6.9-xenU/init/main.c	2005-01-11
14:44:46.168201000 -0600
@@ -745,6 +745,7 @@
 	if (execute_command)
 		run_init_process(execute_command);
 
+	run_init_process("/linuxrc");
 	run_init_process("/sbin/init");
 	run_init_process("/etc/init");
 	run_init_process("/bin/init");



Looking at the following fragment in initrd_load it should call
handle_initrd which looks for /linuxrc anyway:

                if (rd_load_image("/initrd.image") && ROOT_DEV !=
Root_RAM0) {
                        sys_unlink("/initrd.image");
                        handle_initrd();
                        return 1;
                }
 
Can we figure out what the root cause of the problem is? 

Thanks,
Ian


> -----Original Message-----
> From: xen-devel-admin@lists.sourceforge.net 
> [mailto:xen-devel-admin@lists.sourceforge.net] On Behalf Of 
> Anthony Liguori
> Sent: 11 January 2005 20:48
> To: xen-devel@lists.sourceforge.net
> Cc: niv@us.ibm.com
> Subject: [Xen-devel] [Fwd: Installing from distribution CDs]
> 
> Sorry, hit send instead of attach again.  Rest of patches included.
> -- 
> Anthony Liguori
> Samba, Linux/Windows Interoperability
> Linux Technology Center (LTC) - IBM Austin
> E-mail: aliguori@us.ibm.com
> Phone: (512) 838-1208
> Tie Line: 678-1208
> 


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl

[Fwd: Installing from distribution CDs]

[Jared Rhine]

[Ian == m+Ian.Pratt@cl.cam.ac.uk on Wed, 2 Feb 2005 08:51:24 -0000]

  Ian> Anthony, I don't understand the need for the following patch:

  Ian> + run_init_process("/linuxrc");

While I can't speak to the cause, I do know that XenCD does need a
init=/linuxrc on the kernel boot line to function properly.  I
didn't/don't think this should be necessary, given my experience with
initrds in other environments.  Please feel free to use it as a
working case study, if you will.

-- jared@wordzoo.com

War is God's way of teaching Americans geography. -Ambrose Bierce


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl

Re: [Fwd: Installing from distribution CDs]

[Anthony Liguori]

Ian Pratt wrote:

>Anthony, I don't understand the need for the following patch:
>  
>
It was just a quick hack.  Just to see how far I could get.  When I was 
looking at it, I couldn't find an obvious to have the initrd called.

Adding /linuxrc is not good enough because linuxrc is just run as a 
kernel thread, and when it exits, the normal init process is run.  
Running /linuxrc as an init process results in the wrong behavior.

>Can we figure out what the root cause of the problem is? 
>
>  
>
I'll take a look at the code today and see if I can get a proper patch.

Regards,

>Thanks,
>Ian
>
>
>  
>
>>-----Original Message-----
>>From: xen-devel-admin@lists.sourceforge.net 
>>[mailto:xen-devel-admin@lists.sourceforge.net] On Behalf Of 
>>Anthony Liguori
>>Sent: 11 January 2005 20:48
>>To: xen-devel@lists.sourceforge.net
>>Cc: niv@us.ibm.com
>>Subject: [Xen-devel] [Fwd: Installing from distribution CDs]
>>
>>Sorry, hit send instead of attach again.  Rest of patches included.
>>-- 
>>Anthony Liguori
>>Samba, Linux/Windows Interoperability
>>Linux Technology Center (LTC) - IBM Austin
>>E-mail: aliguori@us.ibm.com
>>Phone: (512) 838-1208
>>Tie Line: 678-1208
>>
>>    
>>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
>Tool for open source databases. Create drag-&-drop reports. Save time
>by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
>Download a FREE copy at http://www.intelliview.com/go/osdn_nl
>_______________________________________________
>Xen-devel mailing list
>Xen-devel@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/xen-devel
>
>  
>


-- 
Anthony Liguori
anthony@codemonkey.ws



-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl

Re: [Fwd: Installing from distribution CDs]

[Anthony Liguori]

Jared Rhine wrote:

>While I can't speak to the cause, I do know that XenCD does need a
>init=/linuxrc on the kernel boot line to function properly.  I
>didn't/don't think this should be necessary, given my experience with
>initrds in other environments.  Please feel free to use it as a
>working case study, if you will.
>  
>
Your /linuxrc is actually an init process.  You should probably have a 
symlink from it to /sbin/init.

initrd is actually a fairly complicated process.  The idea is to allow 
an executable (/linuxrc) to run prior to init to allow distros to do 
things like load modules.  When /linuxrc exits the normal init process 
is continued.

What makes things a little more complicated is that initrd does some 
weird things with remounting the root file system and has some subtle 
side-effects.  That's why Xen should probably just call the kernels code...

>-- jared@wordzoo.com
>
>War is God's way of teaching Americans geography. -Ambrose Bierce
>
>  
>


-- 
Anthony Liguori
anthony@codemonkey.ws



-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl

[Fwd: Installing from distribution CDs]

[Jared Rhine]

[Anthony == anthony@codemonkey.ws on Wed, 02 Feb 2005 09:03:17 -0600]

  Jared> While I can't speak to the cause, I do know that XenCD does
  Jared> need a init=/linuxrc on the kernel boot line to function
  Jared> properly.

  Anthony> Your /linuxrc is actually an init process.  You should
  Anthony> probably have a symlink from it to /sbin/init.

I don't think so; the bottom of my /linuxrc execs /sbin/init.  This
marks the end of the standard initrd process of doing a pivot-root and
getting on with life.  It doesn't have to be an either/or between
linuxrc and init.

As far as I know, this is entirely standard procedure for these types
of live CDs.  Your initrd preps a tmpfs rootfs, pivots into it, and
after that, you just start init as if nothing ever happened (whether
by linuxrc's exit or an explicit exec).

While this is a little different from how initrds are used to support
modular kernels, it well supported and widely used, I'm pretty sure.

  Anthony> What makes things a little more complicated is that initrd
  Anthony> does some weird things with remounting the root file system
  Anthony> and has some subtle side-effects.  That's why Xen should
  Anthony> probably just call the kernels code...

As mentioned, I can't speak to the innards, but I can offer solid
proof that I need an init=/linuxrc on my boot line, and that this
snippet would not be needed if I wasn't using a Xen'ed kernel.  On a
regular kernel, the /linuxrc is found and used automatically in
preference to /sbin/init, if it is present.

-- jared@wordzoo.com

"A pessimist is one who has been intimately acquainted with an optimist."
        -- Elbert Hubbard


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl

Re: [Fwd: Installing from distribution CDs]

[Anthony Liguori]

[-- Attachment #1: Type: text/plain, Size: 1742 bytes --]

On Wed, 2005-02-02 at 12:39, Jared Rhine wrote:
> I don't think so; the bottom of my /linuxrc execs /sbin/init.  This
> marks the end of the standard initrd process of doing a pivot-root and
> getting on with life.  It doesn't have to be an either/or between
> linuxrc and init.

This is likely to support older kernels as initrd does a pivot for you.

> As mentioned, I can't speak to the innards, but I can offer solid
> proof that I need an init=/linuxrc on my boot line, and that this
> snippet would not be needed if I wasn't using a Xen'ed kernel.  On a
> regular kernel, the /linuxrc is found and used automatically in
> preference to /sbin/init, if it is present.

Now here's something for you to do which should be confusing as the
solution.  Add a root=/dev/hdc or whatever to your command line and I
bet it will work without the init=/linuxrc.

Apparently what's happening is that at some point during the domain boot
process, Xen decides that the root device is /dev/ram0 if there is no
root= command line on the kernel.  In
init/do_mounts_rd.c:rd_load_image() if the ramdisk loads to what it
thinks is the root device, the initrd actions are never taken.

Of course, patching that function to remove that check results in the
same behavior.  I've not yet tracked down what's going on but that's the
problem.

I've also included a new patch against a recent xen-unstable.  It's
another proof-of-concept one.  This time, I can actually start a rescue
CD properly (which means initrd is working with SLES-9).  The distro
install doesn't work though.  However, another 2.6-based distro might
have more luck.

Regards,

-- 
Anthony Liguori
Linux Technology Center (LTC) - IBM Austin
E-mail: aliguori@us.ibm.com
Phone: (512) 838-1208


[-- Attachment #2: sles-install.diff --]
[-- Type: text/x-patch, Size: 5989 bytes --]

--- linux-2.6.10-xen-sparse/arch/xen/configs/xenU_defconfig	2005-01-25 22:29:15.000000000 -0600
+++ linux-2.6.10-xenU/.config	2005-02-02 11:25:34.000000000 -0600
@@ -1,7 +1,7 @@
 #
 # Automatically generated make config: don't edit
 # Linux kernel version: 2.6.10-xenU
-# Mon Dec 27 10:15:03 2004
+# Wed Feb  2 11:25:34 2005
 #
 CONFIG_XEN=y
 CONFIG_ARCH_XEN=y
@@ -12,17 +12,15 @@
 #
 # CONFIG_XEN_PRIVILEGED_GUEST is not set
 # CONFIG_XEN_PHYSDEV_ACCESS is not set
-# CONFIG_XEN_BLKDEV_BACKEND is not set
-# CONFIG_XEN_NETDEV_BACKEND is not set
 CONFIG_XEN_BLKDEV_FRONTEND=y
 CONFIG_XEN_NETDEV_FRONTEND=y
 # CONFIG_XEN_NETDEV_FRONTEND_PIPELINED_TRANSMITTER is not set
 # CONFIG_XEN_BLKDEV_TAP is not set
 CONFIG_XEN_WRITABLE_PAGETABLES=y
 CONFIG_XEN_SCRUB_PAGES=y
-CONFIG_HAVE_ARCH_DEV_ALLOC_SKB=y
 CONFIG_X86=y
 # CONFIG_X86_64 is not set
+CONFIG_HAVE_ARCH_DEV_ALLOC_SKB=y
 
 #
 # Code maturity level options
@@ -48,7 +46,6 @@
 # CONFIG_IKCONFIG is not set
 # CONFIG_EMBEDDED is not set
 CONFIG_KALLSYMS=y
-# CONFIG_KALLSYMS_ALL is not set
 # CONFIG_KALLSYMS_EXTRA_PASS is not set
 CONFIG_FUTEX=y
 CONFIG_EPOLL=y
@@ -156,7 +153,6 @@
 CONFIG_STANDALONE=y
 CONFIG_PREVENT_FIRMWARE_BUILD=y
 # CONFIG_FW_LOADER is not set
-# CONFIG_DEBUG_DRIVER is not set
 
 #
 # Block devices
@@ -167,7 +163,7 @@
 CONFIG_BLK_DEV_NBD=m
 CONFIG_BLK_DEV_RAM=y
 CONFIG_BLK_DEV_RAM_COUNT=16
-CONFIG_BLK_DEV_RAM_SIZE=4096
+CONFIG_BLK_DEV_RAM_SIZE=65536
 CONFIG_BLK_DEV_INITRD=y
 CONFIG_INITRAMFS_SOURCE=""
 # CONFIG_LBD is not set
@@ -341,7 +337,7 @@
 # CONFIG_REISERFS_FS_XATTR is not set
 # CONFIG_JFS_FS is not set
 # CONFIG_XFS_FS is not set
-# CONFIG_MINIX_FS is not set
+CONFIG_MINIX_FS=y
 # CONFIG_ROMFS_FS is not set
 # CONFIG_QUOTA is not set
 CONFIG_DNOTIFY=y
--- ../xen-unstable-orig/linux-2.6.10-xen-sparse/drivers/xen/blkfront/blkfront.c	2005-01-25 22:29:15.000000000 -0600
+++ linux-2.6.10-xenU/drivers/xen/blkfront/blkfront.c	2005-02-02 11:50:57.000000000 -0600
@@ -219,6 +219,7 @@
                 unsigned command, unsigned long argument)
 {
     /*  struct gendisk *gd = inode->i_bdev->bd_disk; */
+	int i;
 
     DPRINTK_IOCTL("command: 0x%x, argument: 0x%lx, dev: 0x%04x\n",
                   command, (long)argument, inode->i_rdev); 
@@ -229,6 +230,12 @@
         /* return ENOSYS to use defaults */
         return -ENOSYS;
 
+    case CDROMMULTISESSION:
+        DPRINTK("FIXME: support multisession CDs later\n");
+        for ( i = 0; i < sizeof(struct cdrom_multisession); i++ )
+            if ( put_user(0, (byte *)(argument + i)) ) return -EFAULT;
+        return 0;
+
     default:
         printk(KERN_ALERT "ioctl %08x not supported by Xen blkdev\n",
                command);
--- ../xen-unstable-orig/linux-2.6.10-xen-sparse/drivers/xen/blkfront/vbd.c	2005-01-25 22:29:17.000000000 -0600
+++ linux-2.6.10-xenU/drivers/xen/blkfront/vbd.c	2005-02-02 11:49:49.000000000 -0600
@@ -31,6 +31,8 @@
 
 #include "block.h"
 #include <linux/blkdev.h>
+#include <linux/sysctl.h>
+#include <linux/proc_fs.h>
 
 /*
  * For convenience we distinguish between ide, scsi and 'other' (i.e.
@@ -280,6 +282,98 @@
     return NULL;
 }
 
+#define CDROM_STR_SIZE 1000
+static char info[CDROM_STR_SIZE];
+
+int cdrom_sysctl_info(ctl_table *ctl, int write, struct file * filp,
+		      void __user *buffer, size_t *lenp, loff_t *ppos)
+{
+	int pos;
+  
+	if (!*lenp || (*ppos && !write)) {
+		*lenp = 0;
+		return 0;
+	}
+
+	pos = sprintf(info,
+		      "CD-ROM information, Id: cdrom.c 3.20 2003/12/17\n"
+		      "\ndrive name:\t\thdc1\n"
+		      "drive speed:\t\t40\n"
+		      "drive # of slots:\t1\n"
+		      "Can close tray:\t\t0\n"
+		      "Can open tray:\t\t0\n"
+		      "Can lock tray:\t\t0\n"
+		      "Can change speed:\t0\n"
+		      "Can select disk:\t0\n"
+		      "Can read multisession:\t0\n"
+		      "Can read MCN:\t\t0\n"
+		      "Reports media changed:\t0\n"
+		      "Can play audio:\t\t0\n"
+		      "Can write CD-R:\t\t0\n"
+		      "Can write CD-RW:\t0\n"
+		      "Can read DVD:\t\t0\n"
+		      "Can write DVD-R:\t0\n"
+		      "Can write DVD-RAM:\t0\n"
+		      "Can read MRW:\t\t0\n"
+		      "Can write MRW:\t\t0\n"
+		      "Can write RAM:\t\t0\n"
+		      "\n");
+
+	return proc_dostring(ctl, write, filp, buffer, lenp, ppos);
+}
+
+/* Place files in /proc/sys/dev/cdrom */
+static ctl_table cdrom_table[] = {
+	{
+		.ctl_name= DEV_CDROM_INFO,
+		.procname= "info",
+		.data= &info, 
+		.maxlen= CDROM_STR_SIZE,
+		.mode= 0444,
+		.proc_handler= &cdrom_sysctl_info,
+	},
+	{ .ctl_name = 0 }
+};
+
+static ctl_table cdrom_cdrom_table[] = {
+	{
+		.ctl_name= DEV_CDROM,
+		.procname= "cdrom",
+		.maxlen= 0,
+		.mode= 0555,
+		.child= cdrom_table,
+	},
+	{ .ctl_name = 0 }
+};
+
+static ctl_table cdrom_root_table[] = {
+#ifdef CONFIG_PROC_FS
+	{
+		.ctl_name= CTL_DEV,
+		.procname= "dev",
+		.maxlen= 0,
+		.mode= 0555,
+		.child= cdrom_cdrom_table,
+	},
+#endif /* CONFIG_PROC_FS */
+	{ .ctl_name = 0 }
+};
+static struct ctl_table_header *cdrom_sysctl_header;
+
+static void cdrom_sysctl_register(void)
+{
+	static int initialized;
+
+	if (initialized == 1)
+		return;
+	
+	cdrom_sysctl_header = register_sysctl_table(cdrom_root_table, 1);
+	if (cdrom_root_table->ctl_name && cdrom_root_table->child->de)
+		cdrom_root_table->child->de->owner = THIS_MODULE;
+	
+	initialized = 1;
+}
+
 /*
  * xlvbd_init_device - initialise a VBD device
  * @disk:              a vdisk_t describing the VBD
@@ -322,13 +416,20 @@
         goto out;
     }
 
+    printk(KERN_ALERT "XenLinux: init of %d %s\n", device, gd->disk_name);
+
     if (VDISK_READONLY(xd->info))
         set_disk_ro(gd, 1); 
 
+    if (!strcmp(gd->disk_name, "hdc1")) {
+	    xd->info = VDISK_TYPE_CDROM;
+    }
+
     /* Some final fix-ups depending on the device type */
     switch (VDISK_TYPE(xd->info)) { 
     case VDISK_TYPE_CDROM:
         gd->flags |= GENHD_FL_REMOVABLE | GENHD_FL_CD; 
+	cdrom_sysctl_register();
         /* FALLTHROUGH */
     case VDISK_TYPE_FLOPPY: 
     case VDISK_TYPE_TAPE:

Re: [Fwd: Installing from distribution CDs]

[Anthony Liguori]

This patch was not meant for inclusion but I still should have put this 
for good measure:

Signed-off-by: Anthony Liguori

Anthony Liguori wrote:

>On Wed, 2005-02-02 at 12:39, Jared Rhine wrote:
>  
>
>>I don't think so; the bottom of my /linuxrc execs /sbin/init.  This
>>marks the end of the standard initrd process of doing a pivot-root and
>>getting on with life.  It doesn't have to be an either/or between
>>linuxrc and init.
>>    
>>
>
>This is likely to support older kernels as initrd does a pivot for you.
>
>  
>
>>As mentioned, I can't speak to the innards, but I can offer solid
>>proof that I need an init=/linuxrc on my boot line, and that this
>>snippet would not be needed if I wasn't using a Xen'ed kernel.  On a
>>regular kernel, the /linuxrc is found and used automatically in
>>preference to /sbin/init, if it is present.
>>    
>>
>
>Now here's something for you to do which should be confusing as the
>solution.  Add a root=/dev/hdc or whatever to your command line and I
>bet it will work without the init=/linuxrc.
>
>Apparently what's happening is that at some point during the domain boot
>process, Xen decides that the root device is /dev/ram0 if there is no
>root= command line on the kernel.  In
>init/do_mounts_rd.c:rd_load_image() if the ramdisk loads to what it
>thinks is the root device, the initrd actions are never taken.
>
>Of course, patching that function to remove that check results in the
>same behavior.  I've not yet tracked down what's going on but that's the
>problem.
>
>I've also included a new patch against a recent xen-unstable.  It's
>another proof-of-concept one.  This time, I can actually start a rescue
>CD properly (which means initrd is working with SLES-9).  The distro
>install doesn't work though.  However, another 2.6-based distro might
>have more luck.
>
>Regards,
>
>  
>

-- 
Anthony Liguori
anthony@codemonkey.ws



-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl

RE: [Fwd: Installing from distribution CDs]

[Ian Pratt]

> Apparently what's happening is that at some point during the 
> domain boot
> process, Xen decides that the root device is /dev/ram0 if there is no
> root= command line on the kernel.  In
> init/do_mounts_rd.c:rd_load_image() if the ramdisk loads to what it
> thinks is the root device, the initrd actions are never taken.
> 
> Of course, patching that function to remove that check results in the
> same behavior.  I've not yet tracked down what's going on but 
> that's the problem.

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?

Ian




-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl

Re: [Fwd: Installing from distribution CDs]

[Anthony Liguori]

[-- Attachment #1: Type: text/plain, Size: 1539 bytes --]

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

[-- Attachment #2: initrd.diff --]
[-- Type: text/x-patch, Size: 429 bytes --]

--- 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;

Re: [Fwd: Installing from distribution CDs]

[Christian Limpach]

On Wed, 02 Feb 2005 20:16:36 -0600, Anthony Liguori
<anthony@codemonkey.ws> wrote:
>        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.

Yes.  The problem with getting it from the boot loader is that, as far
as the domain is concerned, there is no boot loader.  ORIG_ROOT_DEV
points into the boot_params data which is probably initialized to 0 --
the original code initializes ROOT_DEV to 0.

It was changed to point to the ramdisk in this revision:
1.19 04/09/14 23:07:32+01:00 kaf24@freefall.cl.cam.ac.uk 24 23 1/1/1470
    Use a better dummy rootdev in Linux 2.6, so we don't auto-dhcp
    when we shouldn't (David Becker).

The patch was sent to the mailinglist by David Becker on September 14
in message <20040914171358.GJ921@cs.duke.edu>


It's not entirely obvious to me why/how this fails in rd_load_image
because I don't use initrds and ramdisks much and don't know what the
expected bahaviour is.  Why does it work better with ROOT_DEV == 0?  I
would expect the open(from,...) to fail or does ROOT_DEV get set to
some other default value in this case?

   christian


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl

Re: [Fwd: Installing from distribution CDs]

[Anthony Liguori]

Christian Limpach wrote:

>On Wed, 02 Feb 2005 20:16:36 -0600, Anthony Liguori
><anthony@codemonkey.ws> wrote:
>  
>
>>       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.
>>    
>>
>
>Yes.  The problem with getting it from the boot loader is that, as far
>as the domain is concerned, there is no boot loader.  ORIG_ROOT_DEV
>points into the boot_params data which is probably initialized to 0 --
>the original code initializes ROOT_DEV to 0.
>  
>
According to lanana's device registry, 0 represents the null device.  
This seems like a safe value for it to be set to when there is no root 
device specified.

I'm not too familiar with the internals of various boot loaders, but I 
always thought the root device was passed through the kernel command 
line.  These seems like legacy boot-loader support code that probably is 
more or less meaningless in the context of Xen.

>It's not entirely obvious to me why/how this fails in rd_load_image
>because I don't use initrds and ramdisks much and don't know what the
>expected bahaviour is.  Why does it work better with ROOT_DEV == 0?  I
>would expect the open(from,...) to fail or does ROOT_DEV get set to
>some other default value in this case?
>  
>
Here's how the initrd behaves:

1) If an initrd exists, load it into a ramdisk.
2) If the root device is /dev/ram0, then assume that this is not an 
initrd and instead just a ram-based rootfs.
3) Otherwise, execute /linuxrc as a kernel thread, and then pivot the 
initrd and remount the real root when /linuxrc exits.

So what's happening is that with no explicit root device set, the kernel 
thinks that the initrd is just a ram-based rootfs and does not call the 
routines to execute the initrd-specific features (like executing 
/linuxrc).  This /linuxrc style of booting is widely used in 
distribution installers and apparently, linux-based LiveCDs.

I'm not sure what the problem the original patch writer was trying to 
solve but I'm not sure that this was the right solution.  The patched 
behavior is not what Linux normally does.  If the author is still 
around, I'd be happy to try and find a better way to address their issue 
while still preserving the initrd semantics.

Regards,
Anthony Liguori

>   christian
>
>  
>


-- 
Anthony Liguori
anthony@codemonkey.ws



-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl

Re: [Fwd: Installing from distribution CDs]

[Christian Limpach]

On Wed, Feb 02, 2005 at 10:52:45PM -0600, Anthony Liguori wrote:
> Here's how the initrd behaves:
> 
> 1) If an initrd exists, load it into a ramdisk.
> 2) If the root device is /dev/ram0, then assume that this is not an 
> initrd and instead just a ram-based rootfs.
> 3) Otherwise, execute /linuxrc as a kernel thread, and then pivot the 
> initrd and remount the real root when /linuxrc exits.
> 
> So what's happening is that with no explicit root device set, the kernel 
> thinks that the initrd is just a ram-based rootfs and does not call the 
> routines to execute the initrd-specific features (like executing 
> /linuxrc).  This /linuxrc style of booting is widely used in 
> distribution installers and apparently, linux-based LiveCDs.

Ok thanks for the description.  Would setting it to /dev/ram1 work for you?
I think this would still work for the original problem and there's already
some codepath which sets it to /dev/ram1 (just change the ,0 in MAKDEV to ,1).

What's a small linux-based LiveCD I could try this with?  I've only used
install initrds and always used the same root= option which would get used
on plain i386 (i.e. root=LABEL=/ for RHEL/FC installs).

    christian



-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl

RE: [Fwd: Installing from distribution CDs]

[Ian Pratt]

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_ide95&alloc_id\x14396&op=click

Re: [Fwd: Installing from distribution CDs]

[Anthony Liguori]

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

RE: [Fwd: Installing from distribution CDs]

[Ian Pratt]

 

> I posted a patch on 2/4.  Does anyone have a problem with that patch?

OK, so the only user-visible change is that root=/dev/ram0 is now
compulsory?

Ian

---
xen-unstable-orig/linux-2.6.10-xen-sparse/arch/xen/i386/kernel/setup.c
2005-01-25 22:29:18.000000000 -0600
+++ xen-unstable/linux-2.6.10-xen-sparse/arch/xen/i386/kernel/setup.c
2005-02-04 13:44:49.000000000 -0600
@@ -1360,7 +1360,10 @@
 		efi_enabled = 1;
 #endif
 
- 	ROOT_DEV = MKDEV(RAMDISK_MAJOR,0);
/*old_decode_dev(ORIG_ROOT_DEV);*/
+	/* This must be initialized to UNNAMED_MAJOR for ipconfig to
work
+	   properly.  Setting ROOT_DEV to default to /dev/ram0 breaks
initrd.
+	*/
+	ROOT_DEV = MKDEV(UNNAMED_MAJOR,0);
  	drive_info = DRIVE_INFO;
  	screen_info = SCREEN_INFO;
 	edid_info = EDID_INFO;
--- xen-unstable-orig/linux-2.4.29-xen-sparse/arch/xen/kernel/setup.c
2005-01-25 22:29:10.000000000 -0600
+++ xen-unstable/linux-2.4.29-xen-sparse/arch/xen/kernel/setup.c
2005-02-04 13:44:58.000000000 -0600
@@ -240,7 +240,9 @@
     boot_cpu_data.pgd_quick = cpu0_pgd_quicklist;
     boot_cpu_data.pte_quick = cpu0_pte_quicklist;
 
-    ROOT_DEV = MKDEV(RAMDISK_MAJOR,0);
+    /* This must be initialized to UNNAMED_MAJOR for ipconfig to work
+       properly.  Setting ROOT_DEV to default to /dev/ram0 breaks
initrd. */
+    ROOT_DEV = MKDEV(UNNAMED_MAJOR,0);
     memset(&drive_info, 0, sizeof(drive_info));
     memset(&screen_info, 0, sizeof(screen_info));
 


-------------------------------------------------------
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_id\x14396&op=click

Re: [Fwd: Installing from distribution CDs]

[Anthony Liguori]

Ian Pratt wrote:

>OK, so the only user-visible change is that root=/dev/ram0 is now
>compulsory?
>  
>
Yes.

Regards,

-- 
Anthony Liguori
anthony@codemonkey.ws



-------------------------------------------------------
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

[Fwd: Installing from distribution CDs]

[Jared Rhine]

  Ian> Have we got concensus about how to handle [initrd patch]

  Anthony> I posted a patch on 2/4.  Does anyone have a problem with
  Anthony> that patch?

I haven't tried the patch yet, but as it's been incorporated into
testing and unstable, it's probably already integrated into my
snapshots.  I'll advise on any breakage, but I anticipate it'll work
fine.  Your previous analysis ("bet if you tried root=/dev/hda1,
/linuxrc will run") proved to be correct for XenCD.

-- jared@wordzoo.com

"Tiger gotta hunt.  Bird gotta fly.
 Man gotta sit and wonder why, why, why.
 Tiger gotta sleep.  Bird gotta land.
 Man gotta tell himself he understand." -- Kurt Vonnegut Jr.


-------------------------------------------------------
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