diff options
-rw-r--r-- | howto/subhurd.html | 89 | ||||
-rw-r--r-- | hurd/subhurd.mdwn | 3 | ||||
-rw-r--r-- | hurd/subhurd/running_a_subhurd.mdwn | 42 |
3 files changed, 43 insertions, 91 deletions
diff --git a/howto/subhurd.html b/howto/subhurd.html deleted file mode 100644 index 54aa3b3c..00000000 --- a/howto/subhurd.html +++ /dev/null @@ -1,89 +0,0 @@ -<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN" - "http://www.w3.org/TR/REC-html40/strict.dtd"> - -<HTML> - <HEAD> - <TITLE>GNU Hurd - Free Software Foundation (FSF)</TITLE> - <LINK REV="made" HREF="mailto:web-hurd@gnu.org"> - </HEAD> - -<BODY BGCOLOR="#000000" LINK="#8888EE" VLINK="#9F00DD" ALINK="#000088"> -<IMAGE SRC="/graphics/hurd_sm_mf_invert.jpg"> -<TABLE width="100%" border="0" cellspacing="0" cellpadding="20"> -<TR> -<TD ALIGN="LEFT" VALIGN="TOP"> -<A HREF="../hurd.html#contents"><STRONG>The GNU Hurd</STRONG></A><BR> -<p> -<a href="/software/hurd/whatis/">Whatis?</a><br> -<a href="/software/hurd/howto/">Howto?</a><br> -</p> - -<P> -<!---A HREF="mirrors.html#contents">Mirrors</A><BR---> -<A HREF="../acknowledgements.html#contents">Acknowledgements</A><BR> -<!---A HREF="copyright.html#contents">Copyright Notice</A---> -</TD> -<TD ALIGN="LEFT" VALIGN="TOP" TEXT="#000000" BGCOLOR="#FFFFFF"> -<h1>Running a Subhurd</h1> -<p class="author">By Roland McGrath</p> -<p>The most useful thing you can do when trying to troubleshoot the boot -sequence of the Hurd is try to run your the system in a -sub-hurd, while watching it using ps and gdb from the working hurd. Since -the sub-hurd is never going to make it all the way up, you don't even -really need to make a separate filesystem for it; you can just boot the -sub-hurd read-only on your main root filesystem if you like.</p> - -<p>The way to boot the sub-hurd is with `boot'. I would suggest something -like this: boot -d -I -Tdevice /boot/servers.boot hd0s6</p> - -<p>The -d says to pause before the start-up of each server and wait for you to -hit return, which gives you time to go attach gdb to the task before it -starts running. The -I says to leave the terminal signals normal, so -hitting C-z will suspend boot rather than sending a C-z to the virtual -console device of the sub-hurd. (Note that suspending boot does not -suspend the sub-hurd, just boot itself; boot acts as the server for device -access from the sub-hurd, so the sub-hurd's attempts to write to its -console or open devices block while boot is suspended.)</p> - -<p>When you do `ps -A' on the main hurd, the sub-hurd tasks will appear as -unknown processes. You can figure out which is which just by looking at -the order of unknown processes that appear with higher PIDs than the boot -process. They appear in the order you see in the "bootstrap: ..." -messages, i.e. the first unknown after boot will be ext2fs.static, the -second exec, then init, then proc.</p> - - -<HR> - -Return to <A HREF="/home.html" TARGET="_parent">GNU's home page</A>. -<P> - -Please send FSF & GNU inquiries & questions to - -<A HREF="mailto:gnu@gnu.org"><EM>gnu@gnu.org</EM></A>. -There are also <A HREF="/home.html#ContactInfo" TARGET="_parent">other ways to -contact</A> the FSF. -<P> - -Please send comments on these web pages to - -<A HREF="mailto:web-hurd@gnu.org"><EM>web-hurd@gnu.org</EM></A>, -send other questions to -<A HREF="mailto:gnu@gnu.org"><EM>gnu@gnu.org</EM></A>. -<P> -Copyright (C) 1998, 1999, 2007 Free Software Foundation, Inc., -59 Temple Place - Suite 330, Boston, MA 02111, USA -<P> -Verbatim copying and distribution of this entire article is -permitted in any medium, provided this notice is preserved.<P> -Updated: -<!-- hhmts start --> -$Date$ $Author$ -<!-- hhmts end --> -<HR> -</TD> -</TR> -</TABLE> - -</BODY> -</HTML> diff --git a/hurd/subhurd.mdwn b/hurd/subhurd.mdwn index 8816e312..d2b80cf9 100644 --- a/hurd/subhurd.mdwn +++ b/hurd/subhurd.mdwn @@ -118,5 +118,4 @@ characteristic thread counts. Read about using a subhurd for [[debugging_purposes|debugging/subhurd]]. -Roland's [tutorial](http://www.gnu.org/software/hurd/howto/subhurd.html) on -setting up sub-hurds. +Roland's tutorial about [[running_a_subhurd]]. diff --git a/hurd/subhurd/running_a_subhurd.mdwn b/hurd/subhurd/running_a_subhurd.mdwn new file mode 100644 index 00000000..5d9693cd --- /dev/null +++ b/hurd/subhurd/running_a_subhurd.mdwn @@ -0,0 +1,42 @@ +[[meta copyright="Copyright © 1998, 1999, 2007, 2008 Free Software Foundation, +Inc."]] + +[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled +[[GNU_Free_Documentation_License|/fdl]]."]]"""]] + +[[meta title="Running a Subhurd"]] + +By Roland McGrath. + +The most useful thing you can do when trying to troubleshoot the boot +sequence of the Hurd is try to run your the system in a +sub-hurd, while watching it using ps and gdb from the working hurd. Since +the sub-hurd is never going to make it all the way up, you don't even +really need to make a separate filesystem for it; you can just boot the +sub-hurd read-only on your main root filesystem if you like. + +The way to boot the sub-hurd is with `boot`. I would suggest something +like this: + + boot -d -I -Tdevice /boot/servers.boot hd0s6 + +The -d says to pause before the start-up of each server and wait for you to +hit return, which gives you time to go attach gdb to the task before it +starts running. The -I says to leave the terminal signals normal, so +hitting C-z will suspend boot rather than sending a C-z to the virtual +console device of the sub-hurd. (Note that suspending boot does not +suspend the sub-hurd, just boot itself; boot acts as the server for device +access from the sub-hurd, so the sub-hurd's attempts to write to its +console or open devices block while boot is suspended.) + +When you do `ps -A` on the main hurd, the sub-hurd tasks will appear as +unknown processes. You can figure out which is which just by looking at +the order of unknown processes that appear with higher PIDs than the boot +process. They appear in the order you see in the "bootstrap: ..." +messages, i.e. the first unknown after boot will be ext2fs.static, the +second exec, then init, then proc. |