How?
@@ -111,7 +114,10 @@ aware.
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 nobody> for this purpose.
+never use an existing generic user like nobody> for this purpose.
+However, some distributions, such as SuSE and Linux Mandrake have started
+providing a specific user (generally called named>); you can simply adapt
+this user for our purposes, if you like.
This requires adding a line something like the following to /etc/passwd>:
@@ -191,7 +197,7 @@ will be sufficient to put the necessary libraries in place:
As an alternative, you could simply build statically-linked versions of the BIND
binaries to put in your chroot jail. You should also copy ldconfig> into
-the jail, and run it to create an etc/ld.so.conf> for the jail environment.
+the jail, and run it to create an etc/ld.so.cache> for the jail environment.
The following commands could take care of this:
# cp /sbin/ldconfig /chroot/named/bin/
@@ -226,7 +232,7 @@ in the real /etc/group> above.
Unlike a conventional jailbird, BIND can't just scribble its log entries on the
-walls :-). Normally, BIND logs through syslogd>, the system logging daemon.
However, this type of logging is performed by sending the log entries to the
special socket /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.
The ideal solution to this dilemma requires a reasonably recent version of
-syslogd> which supports the -a> switch introduced by OpenBSD. Check the
+manpage for your syslogd(8)> to see if you have such a version.
If you do, all you have to do is add the switch ``-a
-/chroot/named/dev/log>'' to the command line when you launch '' to the command line when you launch syslogd>. On
systems which use a full SysV-init (which includes most Linux distributions),
this is typically done in the file /etc/rc.d/init.d/syslog>. For example,
on my Red Hat Linux system, I changed the line
@@ -250,23 +256,34 @@ to
daemon syslogd -m 0 -a /chroot/named/dev/log
-The simply restart syslogd>, either by killing it and launching it again,
+or by using the SysV-init script to do it for you:
# /etc/rc.d/init.d/syslog stop
# /etc/rc.d/init.d/syslog start
+I'm told that on SuSE systems, the best place to add this switch is in the
+/etc/rc.config> file. Changing the line
+
+SYSLOGD_PARAMS=""
+
+to read
+
+SYSLOGD_PARAMS="-a /chroot/named/dev/log"
+
+should do the trick.
+
Once it's been restarted, you should see a ``file'' in /chroot/named/dev>
-called log>, that looks something like this:
srw-rw-rw- 1 root root 0 Mar 13 20:58 log
The Other Solutions
-If you have an older syslogd>, then you'll have to find another way to do
+your logging. There are a couple programs out there, such as 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 /dev/log>
socket.
@@ -454,16 +471,16 @@ exit 0
Configuration Changes
-You will also have to add or change a few options in your 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 options>
section:
directory "/etc/namedb";
pid-file "/var/run/named.pid";
named-xfer "/bin/named-xfer";
-Since this file is being read by the named> daemon, all the paths are of
course relative to the chroot jail.
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 [ 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 ]named>. If not, you have a problem.
That's It!
You can go take a nap now ;-).
+Appendix - Thanks
+
+
+I'd like to thank Lonny Selinger <lonny at abyss.za.org>> for
+"testing" this HOWTO and making sure that I didn't miss any steps. I'd also
+like to thank Chirik <chirik at CastleFur.COM>>, Dwayne Litzenberger
+<dlitz at cheerful.com>>, Phil Bambridge <phil.b at
+cableinet.co.uk>>, and others for pointing out errors, omissions, and other
+useful advice to make this HOWTO even better.
+
Appendix - Document Distribution Policy
@@ -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 without any warranty>; without even the impled warranty of
merchantability or fitness for a particular purpose. See the LDP licence for
more details.
diff --git a/LDP/howto/linuxdoc/From-PowerUp-To-Bash-Prompt-HOWTO.sgml b/LDP/howto/linuxdoc/From-PowerUp-To-Bash-Prompt-HOWTO.sgml
index 517955e4..a0f6a8d5 100644
--- a/LDP/howto/linuxdoc/From-PowerUp-To-Bash-Prompt-HOWTO.sgml
+++ b/LDP/howto/linuxdoc/From-PowerUp-To-Bash-Prompt-HOWTO.sgml
@@ -6,13 +6,12 @@
From Power Up To Bash Prompt
Greg O'Keefe, gcokeefe@postoffice.utas.edu.au
-v0.7, April 2000
+v0.8, September 2000
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.
@@ -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.
-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'
(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 [)
-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
+].
+They explain how to
+``toy'' system, purely as a learning exercise.
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.
Check out, download compile and make a boot disk for
-.
+.
(They used to have a home page at ,
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.
-
-
+
by Eric S. Raymond,
especially section 3, What happens when you switch on a computer?
@@ -216,7 +219,8 @@ to make a five point loop. Fun!
- The lilo man page.
-
- The Lilo package (see
[)
+]- The Lilo package
+ (
),
contains the ``LILO User's Guide''
lilo-u-21.ps.gz (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.
make menuconfig or make xconfig
-
-- Kernel source download see
[
+]- source code, see
+
+ for urls
@@ -400,7 +407,10 @@ a program that uses this library.
More Information
-- source code, see section
[
+]- source code, see
+
+ for urls
@@ -507,12 +517,15 @@ This is a good exercise in learning Bash shell scripting too, some of the script
More Information
-- see
[ for source code download url's
]- There are man pages for the
inittab and fstab files.
Type (eg) man inittab into a shell to see it.
- The Linux System Administrators Guide has a good
on init.
+- source code, see
+
+ for urls
@@ -594,7 +607,9 @@ Check out the ext2 filesystem code in the Kernel.
- The
mount command is part of the util-linux package, there is a link
- to it in [.
+ to it in
+ ]
- man pages for
mount , fstab , fsck and mke2fs
- EXT2 File System Utilities
More Information
-- source code download see
[
]- There is a ``Bash Reference Manual'' with this, which is comprehensive, but heavy going.
- There is an O'Rielly book on Bash, not sure if it's good.
- I don't know of any good free up to date bash tutorials. If you do, please
email me a url.
+
- source code, see
+
+ for urls
@@ -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.
-Building A Minimal Linux System From Source
-
-
-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
-.
-
-
-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.
-
-
-What You Will Need
-
-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 source code which we will also be using.)
-
-
-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.
-
-
-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 /boot for any partitions that are over that
-512M mark.
-
-
-Last time I did this, I used Red Hat 6.1 as a source system. I installed
-the base system plus
-
-
-- cpp
-
- egcs
-
- egcs-c++
-
- patch
-
- make
-
- dev86
-
- ncurses-devel
-
- glibc-devel
-
- kernel-headers
-
-
-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?)
-
-
-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 make clean
-after each package is built. Still, this mind boggling bloat is a bit of a worry.
-
-
-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.
-
-
-
-
-- MAKEDEV
-
- Another
-
- site
-- Lilo
-
,
- .
-- Linux Kernel
- Use one of the mirrors listed at
-
- rather than
-
- because they are always overloaded.
-
-- GNU libc
- itself, and the linuxthreads addon are at
-
-
-- 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
-
- The linuxthreads addon is in the same places as libc itself
-- GNU ncurses
-
-
-- SysVinit
-
-
-- GNU Bash
-
-
-- GNU sh-utils
-
-
-- util-linux
-
- This package contains agetty and
- login .
-
-
-
-
-To sum up then, you will need:
-
-- A machine with two spare partitions of about 400M and 700M respectively
- though you could probably get away with less
-
- A Linux distribution (eg. a Red Hat cd) and a way of installing it
- (eg. a cdrom drive)
-
- The source code tarballs listed above
-
-
-
-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.
-
-
-The first milestone in this little project is getting the kernel to boot up
-and panic because it can't find an init . 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 /dev 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.
-
-
-The Filesystem
-
-
-Our new system is going to live in a file system. So first, we have to make
-that file system using mke2fs . Then mount it somewhere. I'd suggest
-/mnt/target . 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 /etc/fstab so that it mounts there automatically when the
-source system comes up.
-
-
-When we boot up the target system, the stuff that's now in /mnt/target
-will be in / .
-
-
-We need a directory structure on target. Have a look at the
-File Heirarchy Standard (see section [)
-to work out what this should be, or just ]cd
-to where the target is mounted and blindly do
-
-
- 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
-
-
-Since the FHS and most packages disagree about where man pages should go,
-we need a symlink
-
-
- cd ..; ln -s share/man man
-
-
-MAKEDEV
-
-We will put the source code in the target /usr/src directory.
-So for example, if your target file system is mounted on /mnt/target
-and your tarballs are in /root , you would do
-
-
- cd /mnt/target/usr/src
- tar -xzvf /root/MAKEDEV-2.5.tar.gz
-
-
-
-Don't be completely lame and copy the tarball to the place where you are going
-to extract it ;->
-
-
-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 /mnt/target is the root filesystem. Different packages
-have different ways of letting you do this. For MAKEDEV you do
-
-
- ROOT=/mnt/target make install
-
-
-
-You need to look out for these options in the README and INSTALL files
-or by doing a ./configure --help .
-
-
-Have a look in MAKEDEV's Makefile to see what it does with the
-ROOT varible that we set in that command. Then have a look
-in the man page by doing man ./MAKEDEV.man to see how it
-works. You'll find that the way to make our device files is to
-cd /mnt/target/dev and do ./MAKEDEV generic .
-Do an ls to see all the wonderful device files it has made
-for you.
-
-Kernel
-
-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 usr/src
-directory, and unpack the linux kernel source there. Enter the linux
-source tree (cd linux ) and configure the kernel
-using your favourite method, for example make menuconfig .
-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 Makefile , find INSTALL_MOD_PATH
-and set it to /mnt/target .
-
-
-Now you can make dep , make bzImage , and if you configured
-modules: make modules , make modules_install . Copy
-the kernel arch/i386/boot/bzImage and the system map System.map
-to the target boot directory /mnt/target/boot , and we are ready
-to install lilo.
-
-Lilo
-
-Lilo comes with a neat script called QuickInst . Unpack the lilo
-source into the target source directory, run this script with the command
-ROOT=/mnt/target ./QuickInst . It will ask you questions about
-how you want lilo installed.
-
-
-Remember, since we have set ROOT ,
-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
-/boot/bzImage not /mnt/target/boot/bzImage .
-I found a little bug in the script, so it said
-
-
-
- ./QuickInst: /boot/bzImage: no such file
-
-
-But if you just ignore it, it's ok.
-
-
-Where should we get QuickInst 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 lilo.conf file on such a system
-probably looks something like this:
-
-
-
-prompt
-timeout = 50
-default = linux
-
-image = /boot/bzImage
- label = linux
- root = /dev/hda1
- read-only
-
-other = /dev/hda2
- label = dos
-
-
-
-
-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 dos at the prompt, lilo loads the boot sector from
-hda2, and it loads DOS.
-
-
-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 QuickInst
-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.
-
-
-To cut a long story short, when QuickInst asks you where to put the
-boot sector, tell it the device where your target filesystem is,
-eg. /dev/hda2 .
-
-
-Now modify the lilo.conf on your source system, so it has
-a line like
-
-
-other = /dev/hda2
- label = target
-
-
-run lilo, and we should be able to do our first boot into the target system.
-
-Glibc
-
-Next we want to install init , but like almost every program that
-runs under Linux, init uses library functions provided by the
-GNU C library, glibc. So we will install that first.
-
-
-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.
-
-
-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!
-
-
-Unpack the glibc-2.1.3.tar.gz (or whatever version) tarball into
-/mnt/target/usr/src
-as usual. Now, we need to unpack the ``add-ons'' into glibc's directory. So
-cd glibc-2.1.3 , and then unpack the glibc-crypt-2.1.3.tar.gz
-and glibc-linuxthreads-2.1.3.tar.gz tarballs there.
-
-
-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 df 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.
-
-
- cd ..
- mkdir glibc-build
- ../glibc-2.1.3/configure --enable-add-ons --prefix=/usr
- make
- make install_root=/mnt/target install
-
-
-
-Notice that we have yet another way of telling a package where to install.
-
-SysVinit
-
-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:
-
-
- cd src
- make
- ROOT=/mnt/target make install
-
-
-
-There are also a lot of scripts associated with init .
-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 debian/etc in the SysVinit source code tree. You can
-just copy them straight across into the target etc directory,
-with something like cd ../debian/etc; cp -r * /mnt/target/etc .
-Obviously you will want to have a look before you copy them across!
-
-
-Everything is in place now for the target kernel to load up init
-when we reboot. The problem this time should be that the scripts won't
-run, becasue bash isn't there to interpret them. Also, init
-will try to run getty 's, but there is no getty for it to run.
-Reboot now and make sure there is nothing else wrong.
-
-Ncurses
-
-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.
-
-
-The commands I used are
-
-
- ./configure --prefix=/usr --with-install-prefix=/mnt/target --with-shared --disable-termcap
- make
- make install
-
-
-Bash
-
-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
-
-
- ./configure --prefix=/mnt/target/usr/local --exec-prefix=/mnt/target --with-curses
-
-
-
-Once you have made and installed Bash, you need to make a symlink like this
- cd /mnt/target/bin; ln -s bash sh . This is because scripts usually
-have a first line like this
-
-
-#!/bin/sh
-
-
-
-If you don't have the symlink, your scripts won't be able to run, because
-they will be looking for /bin/sh not /bin/bash .
-
-
-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 getty or login programs.
-
-Util-linux (getty and login)
-
-The util-linux package contains agetty and login . We need
-both of these to be able to log in and get a bash prompt. After it is
-instlalled, make a symlink from agetty to getty in the
-target /sbin directory. getty 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 inittab to run agetty .
-
-
-I have one remaining problem with the compilation of util-linux. The
-package also contains the program more , and I have not been
-able to persuade the make process to have more
-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.
-
-
-You will also need a /etc/passwd file on the target system.
-This is where the login 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
- /etc/passwd
-
-
-
-root::0:0:root:/root:/bin/bash
-
-
-
-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.
-
-Sh-utils
-
-The last package we need is GNU sh-utils. The only program we need from
-here at this stage is stty , which is used in /etc/init.d/rc
-which is used to change runlevels, and to enter the initial runlevel.
-I actually have, and used a package that contains only stty ,
-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.
-
-
-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 ls 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.
-
-Towards Useability
-
-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 /etc/init.d/mountall.sh
-which does this, and
-issues a mount -a so that everything gets mounted the way you
-specify in /etc/fstab . Put a symlink called something like
-S05mountall to it in the target's etc/rc2.d .
-
-
-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 [ for
-clues on how to find packages.
-
-]
-Look at the other scripts in /etc/init.d . 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.
-
-
-Check the File Heirarchy Standard (see section [).
-It has lists of the commands that should be in ]/bin and
-/sbin . Make sure that you have all these commands installed.
-Even better, find the Posix documentation that specifies this stuff.
-
-
->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 gcc and make in the better. Once that is done,
-you can use the target system to build itself, which is much less complicated.
-
-Random Tips
-
-
-If you have a command called thingy on a Linux system with RPM, and
-want a clue about where to get the source from, you can use the command:
-
-
- rpm -qif `which thingy`
-
-
-And if you have a Red Hat source CD, you can install the source code using
-
-
- rpm -i /mnt/cdrom/SRPMS/what.it.just.said-1.2.srpm
-
-
-
-This will put the tarball, and any Red Hat patches into
-/usr/src/redhat/SOURCES .
-
-More Information
-
-
-- There is a mini-howto on building software from source, the
-
.
-- 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.
-
-
-
-Conclusion
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.
Homepage
The lastest version of this document lives at
-
+as does its companion ``Building a Minimal Linux System from Source Code''.
+
+
+There is a French translation at
+ 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.
-Everyone on the learning@TasLUG mailing list
-Thanks for reading all my mails and asking interesting questions.
-You can join this list by sending a message to
- with
-
- subscribe learning
-
-in the message body.
-
Michael Emery
For reminding me about Unios.
@@ -1508,10 +962,25 @@ For correcting my hexidecimal arithmetic.
For pointing out some typos.
David Leadbeater
For contributing some ``ramblings'' about the kernel deamons.
+ Dominique van den Broeck
+For translating this doc into French.
Change History
+0.7 -> 0.8
+
+
+- Removed instructions on how to build a system, placing them in a
+ separate document. Adjusted a few links accordingly.
+
- Changed homepage from
+ to .
+- Completely failed to incorporate a lot of good material
+ contributed by various people. Maybe next time :(
+
+
0.6 -> 0.7
@@ -1544,6 +1013,7 @@ For contributing some ``ramblings'' about the kernel deamons.
- add more exercises, perhaps a whole section on larger exercises,
like creating a minimal system file by file from a distro
install.
+
- add makefile hack to bash build instructions - see easter notes.