aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorRobb Romans <FMJ@us.ibm.com>2005-12-02 14:29:26 -0700
committerRobb Romans <FMJ@us.ibm.com>2005-12-02 14:29:26 -0700
commit57bd31e3673b07922094c29b58857eb13e1ddfba (patch)
treef4af98e7262f2e8c4523a1d8af2b7112e67b0dc4
parent36d4b5080347247c7d459ef8d9d5d4165f76f687 (diff)
downloadxen-57bd31e3673b07922094c29b58857eb13e1ddfba.tar.gz
xen-57bd31e3673b07922094c29b58857eb13e1ddfba.tar.bz2
xen-57bd31e3673b07922094c29b58857eb13e1ddfba.zip
Small cleanup for distro chapters.
Signed-off-by: Robb Romans <FMJ@us.ibm.com>
-rw-r--r--docs/src/user/debian.tex12
-rw-r--r--docs/src/user/fedora.tex109
2 files changed, 67 insertions, 54 deletions
diff --git a/docs/src/user/debian.tex b/docs/src/user/debian.tex
index db9bea6bf8..ba5667c50b 100644
--- a/docs/src/user/debian.tex
+++ b/docs/src/user/debian.tex
@@ -8,8 +8,8 @@ requiring the host system to have any Debian-specific software (such as
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 @@ mkswap /path/swapimage
\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 @@ debootstrap --arch i386 sarge /mnt/disk \
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 @@ umount /mnt/disk
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 --git a/docs/src/user/fedora.tex b/docs/src/user/fedora.tex
index a0975aed19..5ea79d05d4 100644
--- a/docs/src/user/fedora.tex
+++ b/docs/src/user/fedora.tex
@@ -1,61 +1,66 @@
-\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:
-
-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.
-
-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}}:
-
-\begin{quote}
- \begin{small}\begin{verbatim}
+\chapter{Installing Xen on Red~Hat or Fedora~Core}
+
+\section{Tips}
+Here are a few pointers about using Xen / XenLinux on a Red~Hat or
+Fedora~Core distribution:
+
+\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}}.
+
+\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.
+
+\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.
+
+\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}
#!/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.
-
-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.
+ 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.
+
+\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