This commit is contained in:
gferg 2000-09-18 14:42:24 +00:00
parent e1e83610dc
commit deb6912f53
2 changed files with 103 additions and 606 deletions

View File

@ -6,7 +6,7 @@
<title>Chroot-BIND HOWTO
<author>Scott Wunsch, <tt>scott at wunsch.org</>
<date>v1.1, 24 June 2000
<date>v1.2, 16 September 2000
<abstract>
This document describes installing the BIND 8 nameserver to run in a chroot
jail and as a non-root user, to provide added security and minimise the
@ -73,7 +73,10 @@ url="http://www.losurs.org/docs/howto/Chroot-BIND.html">.
BIND is available from <url url="http://www.isc.org/" name="the Internet
Software Consortium"> at <url url="http://www.isc.org/bind.html">. As of this
writing, the current version of BIND is 8.2.2_P5.
writing, the current version of BIND8 is 8.2.2_P5. BIND 9.0.0 has just been
released, but I haven't even looked at it yet, so I don't know how much of this
document will be applicable. Unless you like living on the bleeding edge, you
may be better off staying with BIND8 for now.
<sect1>How?
@ -111,7 +114,10 @@ aware.
<p>
As mentioned in the introduction, it's not a good idea to run BIND as root. So,
before we begin, let's create a separate user for BIND. Note that you should
never use an existing user like <tt>nobody</> for this purpose.
never use an existing generic user like <tt>nobody</> for this purpose.
However, some distributions, such as SuSE and Linux Mandrake have started
providing a specific user (generally called <tt>named</>); you can simply adapt
this user for our purposes, if you like.
This requires adding a line something like the following to <tt>/etc/passwd</>:
<tscreen><verb>
@ -191,7 +197,7 @@ will be sufficient to put the necessary libraries in place:
</verb></tscreen>
As an alternative, you could simply build statically-linked versions of the BIND
binaries to put in your chroot jail. You should also copy <tt>ldconfig</> into
the jail, and run it to create an <tt>etc/ld.so.conf</> for the jail environment.
the jail, and run it to create an <tt>etc/ld.so.cache</> for the jail environment.
The following commands could take care of this:
<tscreen><verb>
# cp /sbin/ldconfig /chroot/named/bin/
@ -226,7 +232,7 @@ in the real <tt>/etc/group</> above.
<p>
Unlike a conventional jailbird, BIND can't just scribble its log entries on the
walls :-). Normally, BIND logs through <tt/syslogd/, the system logging daemon.
walls :-). Normally, BIND logs through <tt>syslogd</>, the system logging daemon.
However, this type of logging is performed by sending the log entries to the
special socket <tt>/dev/log</>. Since this is outside the jail, BIND can't use
it any more. Fortuantely, there are a couple options to work around this.
@ -235,11 +241,11 @@ it any more. Fortuantely, there are a couple options to work around this.
<p>
The ideal solution to this dilemma requires a reasonably recent version of
<tt/syslogd/ which supports the <tt/-a/ switch introduced by OpenBSD. Check the
manpage for your <tt/syslogd(8)/ to see if you have such a version.
<tt>syslogd</> which supports the <tt>-a</> switch introduced by OpenBSD. Check the
manpage for your <tt>syslogd(8)</> to see if you have such a version.
If you do, all you have to do is add the switch ``<tt>-a
/chroot/named/dev/log</>'' to the command line when you launch <tt/syslogd/. On
/chroot/named/dev/log</>'' to the command line when you launch <tt>syslogd</>. On
systems which use a full SysV-init (which includes most Linux distributions),
this is typically done in the file <tt>/etc/rc.d/init.d/syslog</>. For example,
on my Red Hat Linux system, I changed the line
@ -250,23 +256,34 @@ to
<tscreen><verb>
daemon syslogd -m 0 -a /chroot/named/dev/log
</verb></tscreen>
The simply restart <tt/syslogd/, either by killing it and launching it again, or
by using the SysV-init script to do it for you:
Then simply restart <tt>syslogd</>, either by killing it and launching it again,
or by using the SysV-init script to do it for you:
<tscreen><verb>
# /etc/rc.d/init.d/syslog stop
# /etc/rc.d/init.d/syslog start
</verb></tscreen>
I'm told that on SuSE systems, the best place to add this switch is in the
<tt>/etc/rc.config</> file. Changing the line
<tscreen><verb>
SYSLOGD_PARAMS=""
</verb></tscreen>
to read
<tscreen><verb>
SYSLOGD_PARAMS="-a /chroot/named/dev/log"
</verb></tscreen>
should do the trick.
Once it's been restarted, you should see a ``file'' in <tt>/chroot/named/dev</>
called <tt/log/, that looks something like this:
called <tt>log</>, that looks something like this:
<verb>srw-rw-rw- 1 root root 0 Mar 13 20:58 log</verb>
<sect2>The Other Solutions
<p>
If you have an older <tt/syslogd/, then you'll have to find another way to do
your logging. There are a couple programs out there, such as <tt/holelogd/,
If you have an older <tt>syslogd</>, then you'll have to find another way to do
your logging. There are a couple programs out there, such as <tt>holelogd</>,
which are designed to help by acting as a ``proxy'' and accepting log entries
from the chrooted BIND and passing them out to the regular <tt>/dev/log</>
socket.
@ -454,16 +471,16 @@ exit 0
<sect1>Configuration Changes
<p>
You will also have to add or change a few options in your <tt/named.conf/ to
You will also have to add or change a few options in your <tt>named.conf</> to
keep the various directories straight. In particular, you should add (or
change, if you already have them) the following directives in the <tt/options/
change, if you already have them) the following directives in the <tt>options</>
section:
<tscreen><code>
directory "/etc/namedb";
pid-file "/var/run/named.pid";
named-xfer "/bin/named-xfer";
</code></tscreen>
Since this file is being read by the <tt/named/ daemon, all the paths are of
Since this file is being read by the <tt>named</> daemon, all the paths are of
course relative to the chroot jail.
<sect>The End
@ -483,13 +500,23 @@ If you take a look at your logs, you should find the initialisation messages
that BIND spits out when it loads. (If not, there's a problem with your <ref
id="logging" name="logging configuration"> that you need to fix.) Amongst those
messages, BIND should tell you that it chrooted successfully, and that it is
running as the user and group <tt/named/. If not, you have a problem.
running as the user and group <tt>named</>. If not, you have a problem.
<sect1>That's It!
<p>
You can go take a nap now ;-).
<sect>Appendix - Thanks<label id="thanks">
<p>
I'd like to thank Lonny Selinger <tt>&lt;lonny at abyss.za.org&gt;</> for
"testing" this HOWTO and making sure that I didn't miss any steps. I'd also
like to thank Chirik <tt>&lt;chirik at CastleFur.COM&gt;</>, Dwayne Litzenberger
<tt>&lt;dlitz at cheerful.com&gt;</>, Phil Bambridge <tt>&lt;phil.b at
cableinet.co.uk&gt;</>, and others for pointing out errors, omissions, and other
useful advice to make this HOWTO even better.
<sect>Appendix - Document Distribution Policy<label id="legal">
<p>
@ -499,7 +526,7 @@ url="http://metalab.unc.edu/LDP/COPYRIGHT.html">.
This HOWTO is free documentation; you can redistribute it and/or modify it under
the terms of the LDP licence. It is distributed in the hope that it will be
useful, but <bf/without any warranty/; without even the impled warranty of
useful, but <bf>without any warranty</>; without even the impled warranty of
merchantability or fitness for a particular purpose. See the LDP licence for
more details.

View File

@ -6,13 +6,12 @@
<TITLE>From Power Up To Bash Prompt
<AUTHOR>Greg O'Keefe, <tt>gcokeefe@postoffice.utas.edu.au</tt>
<DATE>v0.7, April 2000
<DATE>v0.8, September 2000
<ABSTRACT>
This is a brief description of what happens in a Linux system, from the time
that you turn on the power, to the time that you log in and get a bash prompt.
It is organised by package to make it easier for people who want to build a
system from source code. Understanding this will be helpful when you need to
Understanding this will be helpful when you need to
solve problems or configure your system.
</ABSTRACT>
@ -45,7 +44,6 @@ I have included exercises in each section. If you actually do some of these,
you will learn much more than you could by just reading.
<P>
There are also links to source code downloads. The reason for this is that
I hope some readers will undertake the best Linux learning exercise that I
know of, which is building a system from source code.
Giambattista Vico, an Italian philosopher (1668-1744) said
@ -58,10 +56,14 @@ If you want to ``roll your own'', you should also see Gerard Beekmans'
<URL URL="http://www.linuxfromscratch.org" NAME="Linux From Scratch HOWTO"> (LFS).
LFS has detailed instructions on building a complete useable system from
source code. On the LFS website, you will also find a mailing list for people
building systems this way. What I have included in this document, is
instructions
(see <REF ID="building" NAME="Building a Minimal Linux System From Source">)
for building a ``toy'' system, purely as a learning exercise.
building systems this way.
The instructions that used to be part of this document
are now in a separate document ``Building a Minimal Linux System from Source Code'',
and can be found at
<URL URL="http://www.netspace.net.au/~gok/power2bash/"
NAME="From PowerUp to Bash Prompt home page">.
They explain how to
``toy'' system, purely as a learning exercise.
<P>
Packages are presented in the order in which they appear in the system
@ -122,7 +124,7 @@ Ask around, someone might give you some of the parts you need.
<P>
Check out, download compile and make a boot disk for
<URL URL="http://learning.taslug.org.au/resources" NAME=Unios>.
<URL URL="http://www.netspace.net.au/~gok/resources" NAME=Unios>.
(They used to have a home page at <URL URL="http://www.unios.org">,
but it disappeared)
This is just a bootable ``Hello World!'' program, consisting of just over 100
@ -143,7 +145,8 @@ Check out the source code for LILO's boot loader.
<P>
<ITEMIZE>
<ITEM>
<URL URL="http://www.linuxdoc.org/HOWTO/Unix-and-Internet-Fundamentals-HOWTO.html" NAME="The Unix and Internet Fundamentals HOWTO">
<URL URL="http://www.linuxdoc.org/HOWTO/Unix-and-Internet-Fundamentals-HOWTO.html"
NAME="The Unix and Internet Fundamentals HOWTO">
by Eric S. Raymond,
especially section 3, <EM>What happens when you switch on a computer?</EM>
@ -216,7 +219,8 @@ to make a five point loop. Fun!
<LABEL ID="lilo-links">
<ITEMIZE>
<ITEM>The lilo man page.
<ITEM>The Lilo package (see <REF ID="downloads" NAME="downloads">)
<ITEM>The Lilo package
(<URL URL="ftp://lrcftp.epfl.ch/pub/linux/local/lilo/" NAME="lilo">),
contains the ``LILO User's Guide''
<TT>lilo-u-21.ps.gz</TT> (or a later version).
You may already have this document though.
@ -326,7 +330,10 @@ Hack! See if you can make it spit out some extra messages or something.
<TT>make menuconfig</TT> or <TT>make xconfig</TT>
<ITEM> <URL URL="http://mirror.aarnet.edu.au/linux/LDP/LDP/"
NAME="The Linux Kernel (and other LDP Guides)">
<ITEM> Kernel source download see <REF ID="downloads" NAME="downloads">
<ITEM> source code, see
<URL URL="http://www.netspace.net.au/~gok/power2bash"
NAME="Building a Minimal Linux System from Source Code">
for urls
</ITEMIZE>
@ -400,7 +407,10 @@ a program that uses this library.
<SECT1>More Information
<P>
<ITEMIZE>
<ITEM>source code, see section <REF ID="downloads" NAME="downloads">
<ITEM> source code, see
<URL URL="http://www.netspace.net.au/~gok/power2bash"
NAME="Building a Minimal Linux System from Source Code">
for urls
</ITEMIZE>
@ -507,12 +517,15 @@ This is a good exercise in learning Bash shell scripting too, some of the script
<SECT1>More Information
<P>
<ITEMIZE>
<ITEM>see <REF ID="downloads" NAME="downloads"> for source code download url's
<ITEM>There are man pages for the <TT>inittab</TT> and <TT>fstab</TT> files.
Type (eg) <TT>man inittab</TT> into a shell to see it.
<ITEM>The Linux System Administrators Guide has a good
<URL URL="http://mirror.aarnet.edu.au/linux/LDP/LDP/"
NAME="section"> on init.
<ITEM> source code, see
<URL URL="http://www.netspace.net.au/~gok/power2bash"
NAME="Building a Minimal Linux System from Source Code">
for urls
</ITEMIZE>
@ -594,7 +607,9 @@ Check out the ext2 filesystem code in the Kernel.
<URL URL="http://mirror.aarnet.edu.au/linux/LDP/LDP/"
NAME="mirror">
<ITEM>The <TT>mount</TT> command is part of the util-linux package, there is a link
to it in <REF ID="downloads" NAME="downloads">.
to it in
<URL URL="http://www.netspace.net.au/~gok/power2bash"
NAME="Building a Minimal Linux System from Source Code">
<ITEM>man pages for <TT>mount</TT>, <TT>fstab</TT>, <TT>fsck</TT> and <TT>mke2fs</TT>
<ITEM>EXT2 File System Utilities
<URL URL="http://web.mit.edu/tytso/www/linux/e2fsprogs.html"
@ -858,11 +873,14 @@ Read shell scripts, look up stuff you don't understand.
<SECT1>More Information
<P>
<ITEMIZE>
<ITEM>source code download see <REF ID="downloads" NAME="downloads">
<ITEM>There is a ``Bash Reference Manual'' with this, which is comprehensive, but heavy going.
<ITEM>There is an O'Rielly book on Bash, not sure if it's good.
<ITEM>I don't know of any good free up to date bash tutorials. If you do, please
email me a url.
<ITEM> source code, see
<URL URL="http://www.netspace.net.au/~gok/power2bash"
NAME="Building a Minimal Linux System from Source Code">
for urls
</ITEMIZE>
@ -879,568 +897,6 @@ It has a full and up to date list of the packages that go into a Linux system
as well as instructions on how to build them.
<SECT>Building A Minimal Linux System From Source
<LABEL ID="building">
<P>
So far I have focussed on what the packages do. Here I will offer what clues
I can about making a minimal Linux system from source. This is a toy system
we are making here. If you want to build a real system to be used for real
work, see the
<URL URL="http://www.linuxfromscratch.org" NAME="Linux From Scratch HOWTO">.
<P>
It is possible to get a bash
prompt without installing everything I mention here. What I describe is
a base system, without nasty kludges, that can be built on easily.
<SECT1>What You Will Need
<P>
We will install a Linux distribution like Red Hat in one partition,
and use that to build a new Linux system in another partition.
I will call the system we are building the ``target'' and the
system we are using to build it with, the ``source'' (not to be
confused with <EM>source code</EM> which we will also be using.)
<P>
So you are going to need a machine with two spare partitions on it.
If you can, use a machine with nothing important on it.
You could use an existing Linux installation as the source system,
but I wouldn't recommend that. If you leave a parameter out of one
of the commands we will issue, you could accidentally install stuff to this
system. This could lead to incompatibilites and strife.
<P>
Older PC hardware, mostly 486's and earlier, have an annoying limitation
in their bios. They can not read from a hard disk past the first 512M.
This is not too much of a problem for Linux, because once it is up, it
does its own disk io, bypassing the bios.
But for Linux to get loaded by these old machines,
the kernel has to reside somewhere below 512M. If you have one of these machines
you will need to have a separate partition completely below the 512M
mark, to mount as <TT>/boot</TT> for any partitions that are over that
512M mark.
<P>
Last time I did this, I used Red Hat 6.1 as a source system. I installed
the base system plus
<ITEMIZE>
<ITEM>cpp
<ITEM>egcs
<ITEM>egcs-c++
<ITEM>patch
<ITEM>make
<ITEM>dev86
<ITEM>ncurses-devel
<ITEM>glibc-devel
<ITEM>kernel-headers
</ITEMIZE>
I also had X-window and Mozilla so I could read documentation easily,
but that's not really necessary. By the time I had finished working,
it had used about 350M of disk space. (Seems a bit high, I wonder why?)
<P>
The finished target system took 650M, but that includes all the source code and
intermediate build files. If space is tight, you should do a <TT>make clean</TT>
after each package is built. Still, this mind boggling bloat is a bit of a worry.
<P>
Finally, you are going to need the source code for the system we are going to
build. These are the ``packages'' that I have discussed in this document. These
can be obtained from a source cd, or from the internet. I'll give URL's for
the USA sites and for Australian mirrors.
<P>
<LABEL ID="downloads">
<ITEMIZE>
<ITEM>MAKEDEV
<URL URL="ftp://tsx-11.mit.edu/pub/linux/sources/sbin" NAME="USA">
Another
<URL URL="ftp://sunsite.unc.edu/pub/Linux/system/admin" NAME="USA">
site
<ITEM>Lilo
<URL URL="ftp://lrcftp.epfl.ch/pub/linux/local/lilo/" NAME="USA">,
<URL URL="ftp://mirror.aarnet.edu.au/pub/linux/metalab/system/boot/lilo/"
NAME="Australia">.
<ITEM>Linux Kernel
Use one of the mirrors listed at
<URL URL="http://www.kernel.org" NAME="home page">
rather than
<URL URL="ftp://ftp.kernel.org/pub/linux/kernel" NAME="USA">
because they are always overloaded.
<URL URL="ftp://kernel.mirror.aarnet.edu.au/pub/linux/kernel/"
NAME="Australia">
<ITEM>GNU libc
itself, and the linuxthreads addon are at
<URL URL="ftp://ftp.gnu.org/pub/gnu/glibc" NAME="USA">
<URL URL="ftp://mirror.aarnet.edu.au/pub/gnu/glibc" NAME="Australia">
<ITEM>GNU libc addons
You will also need the linuxthreads and libcrypt addons.
If libcrypt is not there it is because of some US export laws.
You can get it at
<URL URL="ftp://ftp.gwdg.de/pub/linux/glibc" NAME="libcrypt">
The linuxthreads addon is in the same places as libc itself
<ITEM>GNU ncurses
<URL URL="ftp://ftp.gnu.org/gnu/ncurses" NAME="USA">
<URL URL="ftp://mirror.aarnet.edu.au/pub/gnu/ncurses" NAME="Australia">
<ITEM>SysVinit
<URL URL="ftp://sunsite.unc.edu/pub/Linux/system/daemons/init"
NAME="USA">
<URL URL="ftp://mirror.aarnet.edu.au/pub/linux/metalab/system/daemons/init"
NAME="Australia">
<ITEM>GNU Bash
<URL URL="ftp://ftp.gnu.org/gnu/bash" NAME="USA">
<URL URL="ftp://mirror.aarnet.edu.au/pub/gnu/bash" NAME="Australia">
<ITEM>GNU sh-utils
<URL URL="ftp://ftp.gnu.org/gnu/sh-utils" NAME="USA">
<URL URL="ftp://mirror.aarnet.edu.au/pub/gnu/sh-utils"
NAME="Australia">
<ITEM>util-linux
<URL URL="ftp://ftp.win.tue.nl/pub/linux/utils/util-linux/"
NAME="Somewhere else">
<URL URL="ftp://mirror.aarnet.edu.au/pub/linux/metalab/system/misc"
NAME="Australia"> This package contains <TT>agetty</TT> and
<TT>login</TT>.
</ITEMIZE>
<P>
To sum up then, you will need:
<ITEMIZE>
<ITEM>A machine with two spare partitions of about 400M and 700M respectively
though you could probably get away with less
<ITEM>A Linux distribution (eg. a Red Hat cd) and a way of installing it
(eg. a cdrom drive)
<ITEM>The source code tarballs listed above
</ITEMIZE>
<P>
I'm assuming that you can install the source system yourself, without any
help from me. From here on, I'll assume that its done.
<P>
The first milestone in this little project is getting the kernel to boot up
and panic because it can't find an <TT>init</TT>. This means we are going to have
to install a kernel, and install lilo. To install lilo nicely though, we
will need the device files in the target <TT>/dev</TT> directory. Lilo
needs them to do the low level disk access necessary to write the boot
sector. MAKEDEV is the script that creates these device files.
(You can just copy them from the source system of course, but that's cheating!)
But first of all, we need a filesystem to put all of this into.
<SECT1>The Filesystem
<P>
Our new system is going to live in a file system. So first, we have to make
that file system using <TT>mke2fs</TT>. Then mount it somewhere. I'd suggest
<TT>/mnt/target</TT>. In what follows, I'll assume that this is where it is.
You could save yourself a bit of time by putting an
entry in <TT>/etc/fstab</TT> so that it mounts there automatically when the
source system comes up.
<P>
When we boot up the target system, the stuff that's now in <TT>/mnt/target</TT>
will be in <TT>/</TT>.
<P>
We need a directory structure on target. Have a look at the
File Heirarchy Standard (see section <REF ID="FHS" NAME="Filesystem">)
to work out what this should be, or just <TT>cd</TT>
to where the target is mounted and blindly do
<VERB>
mkdir bin boot dev etc home lib mnt root sbin tmp usr var
cd var; mkdir lock log run spool
cd ../usr; mkdir bin include lib local sbin share src
cd share/; mkdir man; cd man
mkdir man1 man2 man3 ... man9
</VERB>
Since the FHS and most packages disagree about where man pages should go,
we need a symlink
<VERB>
cd ..; ln -s share/man man
</VERB>
<SECT1>MAKEDEV
<P>
We will put the source code in the target <TT>/usr/src</TT> directory.
So for example, if your target file system is mounted on <TT>/mnt/target</TT>
and your tarballs are in <TT>/root</TT>, you would do
<VERB>
cd /mnt/target/usr/src
tar -xzvf /root/MAKEDEV-2.5.tar.gz
</VERB>
<P>
Don't be completely lame and copy the tarball to the place where you are going
to extract it ;->
<P>
Normally when you install software, you are installing it onto the system
that is running. We don't want to do that though, we want to install it
as though <TT>/mnt/target</TT> is the root filesystem. Different packages
have different ways of letting you do this. For MAKEDEV you do
<VERB>
ROOT=/mnt/target make install
</VERB>
<P>
You need to look out for these options in the README and INSTALL files
or by doing a <TT>./configure --help</TT>.
<P>
Have a look in MAKEDEV's <TT>Makefile</TT> to see what it does with the
<TT>ROOT</TT> varible that we set in that command. Then have a look
in the man page by doing <TT>man ./MAKEDEV.man</TT> to see how it
works. You'll find that the way to make our device files is to
<TT>cd /mnt/target/dev</TT> and do <TT>./MAKEDEV generic</TT>.
Do an <TT>ls</TT> to see all the wonderful device files it has made
for you.
<SECT1>Kernel
<P>
Next we make a kernel. I presume you've done this before, so I'll be brief.
It is easier to install lilo if the kernel
it is meant to boot is already there. Go back to the target <TT>usr/src</TT>
directory, and unpack the linux kernel source there. Enter the linux
source tree (<TT>cd linux</TT>) and configure the kernel
using your favourite method, for example <TT>make menuconfig</TT>.
You can make life slightly easier for yourself by configuring
a kernel without modules. If you configure any modules, then you
will have to edit the <TT>Makefile</TT>, find <TT>INSTALL_MOD_PATH</TT>
and set it to <TT>/mnt/target</TT>.
<P>
Now you can <TT>make dep</TT>, <TT>make bzImage</TT>, and if you configured
modules: <TT>make modules</TT>, <TT>make modules_install</TT>. Copy
the kernel <TT>arch/i386/boot/bzImage</TT> and the system map <TT>System.map</TT>
to the target boot directory <TT>/mnt/target/boot</TT>, and we are ready
to install lilo.
<SECT1>Lilo
<P>
Lilo comes with a neat script called <TT>QuickInst</TT>. Unpack the lilo
source into the target source directory, run this script with the command
<TT>ROOT=/mnt/target ./QuickInst</TT>. It will ask you questions about
how you want lilo installed.
<P>
Remember, since we have set <TT>ROOT</TT>,
to the target partition, you tell it file names relative to that. So
when it asks what kernel you want to boot by default, answer
<TT>/boot/bzImage</TT> <EM>not</EM> <TT>/mnt/target/boot/bzImage</TT>.
I found a little bug in the script, so it said
<VERB>
./QuickInst: /boot/bzImage: no such file
</VERB>
But if you just ignore it, it's ok.
<P>
Where should we get <TT>QuickInst</TT> to put the boot sector?
When we reboot we want to have the choice of booting into the source system
or the target system, or any other systems that are on this box.
And we want the instance of lilo that we are building now to load
the kernel of our new system. How are we going achieve both of these
things? Let's digress a little and look at how lilo boots DOS on a
dual boot Linux system. The <TT>lilo.conf</TT> file on such a system
probably looks something like this:
<P>
<VERB>
prompt
timeout = 50
default = linux
image = /boot/bzImage
label = linux
root = /dev/hda1
read-only
other = /dev/hda2
label = dos
</VERB>
<P>
If the machine is set up this way, then the master boot record gets read and
loaded by the bios, and it loads the lilo bootloader, which gives a prompt.
If you type in <TT>dos</TT> at the prompt, lilo loads the boot sector from
hda2, and it loads DOS.
<P>
What we are going to do is just the same, except that the boot sector in
hda2 is going to be another lilo boot sector - the one that <TT>QuickInst</TT>
is going to install. So the lilo from the Linux distribution will load the
lilo that we have built, and that will load the kernel that we have built.
You will see two lilo prompts when you reboot.
<P>
To cut a long story short, when <TT>QuickInst</TT> asks you where to put the
boot sector, tell it the device where your target filesystem is,
eg. <TT>/dev/hda2</TT>.
<P>
Now modify the <TT>lilo.conf</TT> on your source system, so it has
a line like
<VERB>
other = /dev/hda2
label = target
</VERB>
run lilo, and we should be able to do our first boot into the target system.
<SECT1>Glibc
<P>
Next we want to install <TT>init</TT>, but like almost every program that
runs under Linux, <TT>init</TT> uses library functions provided by the
GNU C library, glibc. So we will install that first.
<P>
Glibc is a very large and complicated package. It took 90 hours to build
on my old 386sx/16 with 8M RAM. But it only took 33 minutes on my Celeron
433 with 64M. I think memory is the main issue here. If you only have 8M
of RAM (or, shudder, less!) be prepared for a long build.
<P>
The glibc install documentation recommends building in a separate directory.
This enables you to start again easily, by just blowing that directory away.
You might also want to do that to save yourself about 265M of disk space!
<P>
Unpack the <TT>glibc-2.1.3.tar.gz</TT> (or whatever version) tarball into
<TT>/mnt/target/usr/src</TT>
as usual. Now, we need to unpack the ``add-ons'' into glibc's directory. So
<TT>cd glibc-2.1.3</TT>, and then unpack the <TT>glibc-crypt-2.1.3.tar.gz</TT>
and <TT>glibc-linuxthreads-2.1.3.tar.gz</TT> tarballs there.
<P>
Now we can create the build directory, configure, make and install glibc.
These are the commands I used, but read the documentation yourself and
make sure you do what is best for your circumstances.
Before you do though, you might want to do a <TT>df</TT> command to see
how much free space you have. You can do another after you've built and
installed glibc, to see what a space-hog it is.
<P><VERB>
cd ..
mkdir glibc-build
../glibc-2.1.3/configure --enable-add-ons --prefix=/usr
make
make install_root=/mnt/target install
</VERB>
<P>
Notice that we have yet another way of telling a package where to install.
<SECT1>SysVinit
<P>
Making and installing the SysVinit binaries is pretty straight forward.
I'll just be lazy and give you the commands, assuming that you have
unpacked and entered the SysVinit source code directory:
<P><VERB>
cd src
make
ROOT=/mnt/target make install
</VERB>
<P>
There are also a lot of scripts associated with <TT>init</TT>.
There are example scripts with the SysVinit package, which work fine.
But you have to install them manually. They are set up in a heirarchy
under <TT>debian/etc</TT> in the SysVinit source code tree. You can
just copy them straight across into the target <TT>etc</TT> directory,
with something like <TT>cd ../debian/etc; cp -r * /mnt/target/etc</TT>.
Obviously you will want to have a look before you copy them across!
<P>
Everything is in place now for the target kernel to load up <TT>init</TT>
when we reboot. The problem this time should be that the scripts won't
run, becasue <TT>bash</TT> isn't there to interpret them. Also, <TT>init</TT>
will try to run <TT>getty</TT>'s, but there is no <TT>getty</TT> for it to run.
Reboot now and make sure there is nothing else wrong.
<SECT1>Ncurses
<P>
The next thing we need is Bash, but bash needs ncurses, so we'll install
it first. Ncurses replaces termcap as the way of handling text screens,
but it can also provide backwards compatibility by supporting the termcap
calls. In the interests of having a clean simple modern system,
I think its best to
disable the old termcap method. You might strike trouble later on if
you are compiling an older application that uses termcap.
But at least you will know what is using what. If you need to you can recompile
ncurses with termcap support.
<P>
The commands I used are
<P><VERB>
./configure --prefix=/usr --with-install-prefix=/mnt/target --with-shared --disable-termcap
make
make install
</VERB>
<SECT1>Bash
<P>
It me took quite a lot of reading and thinking and trial and error
to get Bash to install itself where I thought it should go. The
configuration options I used are
<P><VERB>
./configure --prefix=/mnt/target/usr/local --exec-prefix=/mnt/target --with-curses
</VERB>
<P>
Once you have made and installed Bash, you need to make a symlink like this
<TT>cd /mnt/target/bin; ln -s bash sh</TT>. This is because scripts usually
have a first line like this
<P><VERB>
#!/bin/sh
</VERB>
<P>
If you don't have the symlink, your scripts won't be able to run, because
they will be looking for <TT>/bin/sh</TT> not <TT>/bin/bash</TT>.
<P>
You could reboot again at this point if you like. You should notice that
the scripts actually run this time, though you still can't login, because
there are no <TT>getty</TT> or <TT>login</TT> programs.
<SECT1>Util-linux (getty and login)
<P>
The util-linux package contains <TT>agetty</TT> and <TT>login</TT>. We need
both of these to be able to log in and get a bash prompt. After it is
instlalled, make a symlink from <TT>agetty</TT> to <TT>getty</TT> in the
target <TT>/sbin</TT> directory. <TT>getty</TT> is one of the programs
that is supposed to be there on all Unix-like systems, so the link
is a better idea than hacking <TT>inittab</TT> to run <TT>agetty</TT>.
<P>
I have one remaining problem with the compilation of util-linux. The
package also contains the program <TT>more</TT>, and I have not been
able to persuade the <TT>make</TT> process to have <TT>more</TT>
link against the ncurses 5 library on the target system rather than
the ncurses 4 on the source system. I'll be having a closer look at
that.
<P>
You will also need a <TT>/etc/passwd</TT> file on the target system.
This is where the <TT>login</TT> program will check to find out if
you are allowed in. Since this is only a toy system at this stage,
we can do outrageous things like setting up only the root user,
and not requiring any password!! Just put this in the target
<TT>/etc/passwd</TT>
<P><VERB>
root::0:0:root:/root:/bin/bash
</VERB>
<P>
The fields are separated by colons, and from left to right they are
user id, password (encrypted), user number, group number, user's name,
home directory and default shell.
<SECT1>Sh-utils
<P>
The last package we need is GNU sh-utils. The only program we need from
here at this stage is <TT>stty</TT>, which is used in <TT>/etc/init.d/rc</TT>
which is used to change runlevels, and to enter the initial runlevel.
I actually have, and used a package that contains only <TT>stty</TT>,
but I can't remember where it came from. Its a better idea to use the
GNU package, because there is other stuff in there that you will need
if you add to the system to make it useable.
<P>
Well that's it. You should now have a system that will boot up and prompt
you for a login. Type in ``root'', and you should get a shell. You won't
be able to do much with it. There isn't even an <TT>ls</TT> command here
for you to see your handiwork. Press tab twice so you can see the
available commands. This was about the most satisfying thing I found to do
with it.
<SECT1>Towards Useability
<P>
It might look like we have made a pretty useless system here. But really,
there isn't that far to go before it can do some work. One of the first
things you would have to do is have the root filesystem mount read-write.
There is a script from the SysVinit package, in <TT>/etc/init.d/mountall.sh</TT>
which does this, and
issues a <TT>mount -a</TT> so that everything gets mounted the way you
specify in <TT>/etc/fstab</TT>. Put a symlink called something like
<TT>S05mountall</TT> to it in the target's <TT>etc/rc2.d</TT>.
<P>
You may find that this script will use commands that you haven't
installed yet. If so, find the package that contains the commands
and install it. See section <REF ID="finding" NAME="Random Tips"> for
clues on how to find packages.
<P>
Look at the other scripts in <TT>/etc/init.d</TT>. Most of them will
need to be included in any serious system. Add them in one at a time,
make sure everthing is running smoothly before adding more.
<P>
Check the File Heirarchy Standard (see section <REF ID="FHS" NAME="Filesystem">).
It has lists of the commands that should be in <TT>/bin</TT> and
<TT>/sbin</TT>. Make sure that you have all these commands installed.
Even better, find the Posix documentation that specifies this stuff.
<P>
>From there, it's really just a matter of throwing in more and more packages
until everything you want it there. The sooner you can put the build tools
such as <TT>gcc</TT> and <TT>make</TT> in the better. Once that is done,
you can use the target system to build itself, which is much less complicated.
<SECT1>Random Tips
<LABEL ID="finding">
<P>
If you have a command called <TT>thingy</TT> on a Linux system with RPM, and
want a clue about where to get the source from, you can use the command:
<VERB>
rpm -qif `which thingy`
</VERB>
And if you have a Red Hat source CD, you can install the source code using
<VERB>
rpm -i /mnt/cdrom/SRPMS/what.it.just.said-1.2.srpm
</VERB>
<P>
This will put the tarball, and any Red Hat patches into
<TT>/usr/src/redhat/SOURCES</TT>.
<SECT1>More Information
<P>
<ITEMIZE>
<ITEM> There is a mini-howto on building software from source, the
<URL URL="http://www.linuxdoc.org/HOWTO/Software-Building.html"
NAME="Software Building mini-HOWTO">.
<ITEM> There is also a HOWTO on building a Linux system from scratch.
It focuses much more on getting the system built so it can be used,
rather than just doing it as a learning exercise.
<URL URL="http://www.linuxfromscratch.org"
NAME="The Linux From Scratch HOWTO">
</ITEMIZE>
<SECT>Conclusion
<P>
One of the best things about Linux, in my humble opinion, is that you can get
inside it and really find out how it all works. I hope that you enjoy this as
@ -1458,8 +914,15 @@ Please acknowledge me if you use all or part of this in another document.
<SECT1>Homepage
<P>
The lastest version of this document lives at
<URL URL="http://learning.taslug.org.au/power2bash"
<URL URL="http://www.netspace.net.au/~gok/power2bash"
NAME="From Powerup To Bash Prompt">
as does its companion ``Building a Minimal Linux System from Source Code''.
<P>
There is a French translation at
<URL URL="http://www.freenix.fr/unix/linux/HOWTO/From-PowerUp-To-Bash-Prompt-HOWTO.html"
NAME="From Powerup To Bash Prompt"> thanks to Dominique van den Broeck.
@ -1481,15 +944,6 @@ There are some people I want to say thanks to, for helping to make this happen.
<P>
<DESCRIP>
<TAG>Everyone on the learning@TasLUG mailing list</TAG>
Thanks for reading all my mails and asking interesting questions.
You can join this list by sending a message to
<URL URL="mailto:majordomo@taslug.org.au" NAME="majordomo"> with
<VERB>
subscribe learning
</VERB>
in the message body.
<TAG>Michael Emery</TAG>
For reminding me about Unios.
@ -1508,10 +962,25 @@ For correcting my hexidecimal arithmetic.
For pointing out some typos.
<TAG>David Leadbeater</TAG>
For contributing some ``ramblings'' about the kernel deamons.
<TAG> Dominique van den Broeck </TAG>
For translating this doc into French.
</DESCRIP>
<SECT1>Change History
<SECT2>0.7 -> 0.8
<P>
<ITEMIZE>
<ITEM> Removed instructions on how to build a system, placing them in a
separate document. Adjusted a few links accordingly.
<ITEM> Changed homepage from <URL URL="http://learning.taslug.org.au/power2bash"
NAME="learning@TasLUG">
to <URL URL="http://www.netspace.net.au/~gok/power2bash"
NAME="my own webspace">.
<ITEM> Completely failed to incorporate a lot of good material
contributed by various people. Maybe next time :(
</ITEMIZE>
<SECT2>0.6 -> 0.7
<P>
<ITEMIZE>
@ -1544,6 +1013,7 @@ For contributing some ``ramblings'' about the kernel deamons.
<ITEM>add more exercises, perhaps a whole section on larger exercises,
like creating a minimal system file by file from a distro
install.
<ITEM>add makefile hack to bash build instructions - see easter notes.
</ITEMIZE>
</ARTICLE>