[Xen-changelog] Small cleanup for distro chapters.

[Xen patchbot -unstable <patchbot-unstable@xxxxxxxxxxxxxxxxxxx>]

# HG changeset patch
# User Robb Romans <FMJ@xxxxxxxxxx>
# Node ID 57d5f6c9b9ef3a8a15315e933e64b00923487305
# Parent  dceb2fcdab5bc623e79c13b302759c362caf9b26
Small cleanup for distro chapters.

Signed-off-by: Robb Romans <FMJ@xxxxxxxxxx>

diff -r dceb2fcdab5b -r 57d5f6c9b9ef docs/src/user/debian.tex
--- a/docs/src/user/debian.tex  Fri Dec  2 21:29:26 2005
+++ b/docs/src/user/debian.tex  Fri Dec  2 21:29:26 2005
@@ -8,8 +8,8 @@
 Here's some info on how to install Debian 3.1 (Sarge) for an
 unprivileged Xen domain:
 
+\section{Filesystem Setup}
 \begin{enumerate}
-
 \item Set up Xen and test that it's working, as described earlier in
   this manual.
 
@@ -35,7 +35,9 @@
 \begin{verbatim}
 mount -o loop /path/diskimage /mnt/disk
 \end{verbatim}
-
+\end{enumerate}
+\section{Bootstrapping}
+\begin{enumerate}
 \item Install \path{debootstrap}. Make sure you have debootstrap
   installed on the host. If you are running Debian Sarge (3.1 / testing)
   or unstable you can install it by running \path{apt-get install
@@ -48,7 +50,10 @@
             http://ftp.<countrycode>.debian.org/debian
 \end{verbatim}
   You may use any Debian mirror that you want.
+\end{enumerate}
 
+\section{Configuration}
+\begin{enumerate}
 \item When debootstrap completes successfully, modify settings:
 \begin{verbatim}
 chroot /mnt/disk /bin/bash
@@ -98,7 +103,10 @@
 disk = [ 'file:/path/diskimage,sda1,w', 'file:/path/swapimage,sda2,w' ]
 root = "/dev/sda1 ro"
 \end{verbatim}
+\end{enumerate}
 
+\section{Starting the New Domain}
+\begin{enumerate}
 \item Start the new domain
 \begin{verbatim}
 xm create -f domain_config_file
diff -r dceb2fcdab5b -r 57d5f6c9b9ef docs/src/user/fedora.tex
--- a/docs/src/user/fedora.tex  Fri Dec  2 21:29:26 2005
+++ b/docs/src/user/fedora.tex  Fri Dec  2 21:29:26 2005
@@ -1,61 +1,66 @@
-\chapter{Installing Xen on Red~Hat or Fedora Core}
+\chapter{Installing Xen on Red~Hat or Fedora~Core}
 
-When using Xen / XenLinux on a standard Linux distribution there are a
-couple of things to watch out for:
+\section{Tips}
+Here are a few pointers about using Xen / XenLinux on a Red~Hat or
+Fedora~Core distribution:
 
-Note that, because domains greater than 0 don't have any privileged
-access at all, certain commands in the default boot sequence will fail
-e.g.\ attempts to update the hwclock, change the console font, update
-the keytable map, start apmd (power management), or gpm (mouse
-cursor).  Either ignore the errors (they should be harmless), or
-remove them from the startup scripts.  Deleting the following links
-are a good start: {\path{S24pcmcia}}, {\path{S09isdn}},
-{\path{S17keytable}}, {\path{S26apmd}}, {\path{S85gpm}}.
+\begin{enumerate}
+\item Note that, because domains greater than~0 don't have any
+  privileged access at all, certain commands in the default boot
+  sequence will fail e.g.\ attempts to update the hwclock, change the
+  console font, update the keytable map, start apmd (power management),
+  or gpm (mouse cursor). Either ignore the errors (they should be
+  harmless), or remove them from the startup scripts. Deleting the
+  following links are a good start: {\path{S24pcmcia}},
+  {\path{S09isdn}}, {\path{S17keytable}}, {\path{S26apmd}},
+  {\path{S85gpm}}.
 
-If you want to use a single root file system that works cleanly for
-both domain~0 and unprivileged domains, a useful trick is to use
-different `init' run levels. For example, use run level 3 for
-domain~0, and run level 4 for other domains. This enables different
-startup scripts to be run in depending on the run level number passed
-on the kernel command line.
+\item If you want to use a single root file system that works cleanly
+  for both domain~0 and unprivileged domains, a useful trick is to use
+  different `init' run levels. For example, use run level 3 for
+  domain~0, and run level 4 for other domains. This enables different
+  startup scripts to be run in depending on the run level number passed
+  on the kernel command line.
 
-If using NFS root files systems mounted either from an external server
-or from domain0 there are a couple of other gotchas.  The default
-{\path{/etc/sysconfig/iptables}} rules block NFS, so part way through
-the boot sequence things will suddenly go dead.
+\item If using NFS root files systems mounted either from an external
+  server or from domain0 there are a couple of other gotchas. The
+  default {\path{/etc/sysconfig/iptables}} rules block NFS, so part way
+  through the boot sequence things will suddenly go dead.
 
-If you're planning on having a separate NFS {\path{/usr}} partition,
-the RH9 boot scripts don't make life easy - they attempt to mount NFS
-file systems way to late in the boot process. The easiest way I found
-to do this was to have a {\path{/linuxrc}} script run ahead of
-{\path{/sbin/init}} that mounts {\path{/usr}}:
+\item If you're planning on having a separate NFS {\path{/usr}}
+  partition, the RH9 boot scripts don't make life easy - they attempt to
+  mount NFS file systems way to late in the boot process. The easiest
+  way I found to do this was to have a {\path{/linuxrc}} script run
+  ahead of {\path{/sbin/init}} that mounts {\path{/usr}}:
 
-\begin{quote}
-  \begin{small}\begin{verbatim}
+  \begin{quote}
+    \begin{small}\begin{verbatim}
  #!/bin/bash
  /sbin/ipconfig lo 127.0.0.1
  /sbin/portmap
  /bin/mount /usr
  exec /sbin/init "$@" <>/dev/console 2>&1
 \end{verbatim}\end{small}
-\end{quote}
+  \end{quote}
 
 %% $ XXX SMH: font lock fix :-)
 
-The one slight complication with the above is that
-{\path{/sbin/portmap}} is dynamically linked against
-{\path{/usr/lib/libwrap.so.0}} Since this is in {\path{/usr}}, it
-won't work. This can be solved by copying the file (and link) below
-the {\path{/usr}} mount point, and just let the file be `covered' when
-the mount happens.
+  The one slight complication with the above is that
+  {\path{/sbin/portmap}} is dynamically linked against
+  {\path{/usr/lib/libwrap.so.0}} Since this is in {\path{/usr}}, it
+  won't work. This can be solved by copying the file (and link) below
+  the {\path{/usr}} mount point, and just let the file be `covered' when
+  the mount happens.
 
-In some installations, where a shared read-only {\path{/usr}} is being
-used, it may be desirable to move other large directories over into
-the read-only {\path{/usr}}. For example, you might replace
-{\path{/bin}}, {\path{/lib}} and {\path{/sbin}} with links into
-{\path{/usr/root/bin}}, {\path{/usr/root/lib}} and
-{\path{/usr/root/sbin}} respectively. This creates other problems for
-running the {\path{/linuxrc}} script, requiring bash, portmap, mount,
-ifconfig, and a handful of other shared libraries to be copied below
-the mount point --- a simple statically-linked C program would solve
-this problem.
+\item In some installations, where a shared read-only {\path{/usr}} is
+  being used, it may be desirable to move other large directories over
+  into the read-only {\path{/usr}}. For example, you might replace
+  {\path{/bin}}, {\path{/lib}} and {\path{/sbin}} with links into
+  {\path{/usr/root/bin}}, {\path{/usr/root/lib}} and
+  {\path{/usr/root/sbin}} respectively. This creates other problems for
+  running the {\path{/linuxrc}} script, requiring bash, portmap, mount,
+  ifconfig, and a handful of other shared libraries to be copied below
+  the mount point --- a simple statically-linked C program would solve
+  this problem.
+
+\end{enumerate}
\ No newline at end of file

_______________________________________________
Xen-changelog mailing list
Xen-changelog@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-changelog