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
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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel
[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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel
Anthony Liguori
2005-Feb-02 14:57 UTC
Re: [Xen-devel] [Fwd: Installing from distribution CDs]
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
Anthony Liguori
2005-Feb-02 15:03 UTC
Re: [Xen-devel] [Fwd: Installing from distribution CDs]
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
[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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel
Anthony Liguori
2005-Feb-02 19:40 UTC
Re: [Xen-devel] [Fwd: Installing from distribution CDs]
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
Anthony Liguori
2005-Feb-02 20:04 UTC
Re: [Xen-devel] [Fwd: Installing from distribution CDs]
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
> 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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
Anthony Liguori
2005-Feb-03 02:16 UTC
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
Christian Limpach
2005-Feb-03 04:07 UTC
Re: [Xen-devel] [Fwd: Installing from distribution CDs]
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
Anthony Liguori
2005-Feb-03 04:52 UTC
Re: [Xen-devel] [Fwd: Installing from distribution CDs]
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
Christian Limpach
2005-Feb-03 10:54 UTC
Re: [Xen-devel] [Fwd: Installing from distribution CDs]
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
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_id396&op=click _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
Anthony Liguori
2005-Feb-09 01:00 UTC
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@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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
> 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_id396&op=click _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
Anthony Liguori
2005-Feb-09 02:11 UTC
Re: [Xen-devel] [Fwd: Installing from distribution CDs]
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel