diff options
author | Robb Romans <FMJ@us.ibm.com> | 2005-12-02 14:29:26 -0700 |
---|---|---|
committer | Robb Romans <FMJ@us.ibm.com> | 2005-12-02 14:29:26 -0700 |
commit | 57bd31e3673b07922094c29b58857eb13e1ddfba (patch) | |
tree | f4af98e7262f2e8c4523a1d8af2b7112e67b0dc4 | |
parent | 36d4b5080347247c7d459ef8d9d5d4165f76f687 (diff) | |
download | xen-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.tex | 12 | ||||
-rw-r--r-- | docs/src/user/fedora.tex | 109 |
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 |