From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [Fwd: Installing from distribution CDs] Date: Wed, 02 Feb 2005 22:52:45 -0600 Message-ID: <4201AE1D.3080108@codemonkey.ws> References: <42018984.8020309@codemonkey.ws> <3d8eece2050202200727518be6@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit In-Reply-To: <3d8eece2050202200727518be6@mail.gmail.com> Sender: xen-devel-admin@lists.sourceforge.net Errors-To: xen-devel-admin@lists.sourceforge.net List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , List-Archive: To: Christian.Limpach@cl.cam.ac.uk Cc: Ian Pratt , Anthony Liguori , xen-devel@lists.sourceforge.net List-Id: xen-devel@lists.xenproject.org Christian Limpach wrote: >On Wed, 02 Feb 2005 20:16:36 -0600, Anthony Liguori > 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