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 b9a531d6..517955e4 100644 --- a/LDP/howto/linuxdoc/From-PowerUp-To-Bash-Prompt-HOWTO.sgml +++ b/LDP/howto/linuxdoc/From-PowerUp-To-Bash-Prompt-HOWTO.sgml @@ -1,11 +1,12 @@ +
From Power Up To Bash Prompt <AUTHOR>Greg O'Keefe, <tt>gcokeefe@postoffice.utas.edu.au</tt> -<DATE>v0.6, February 2000 +<DATE>v0.7, April 2000 <ABSTRACT> This is a brief description of what happens in a Linux system, from the time @@ -33,7 +34,7 @@ I assume that you have a working Linux box, and understand some basic things about Unix and PC hardware. If not, an excellent place to start learning is Eric S. Raymond's <URL -URL="http://mirror.aarnet.edu.au/linux/LDP/HOWTO/Unix-Internet-Fundamentals-HOWTO.html" +URL="http://www.linuxdoc.org/HOWTO/Unix-and-Internet-Fundamentals-HOWTO.html" NAME ="The Unix and Internet Fundamentals HOWTO" > It is short, very readable and covers all the basics. @@ -42,12 +43,25 @@ The main thread in this document is how Linux starts itself up. But it also tries to be a more comprehensive learning resource. 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, or ``rolling your own''. +know of, which is building a system from source code. Giambattista Vico, an Italian philosopher (1668-1744) said -``verum ipsum factum'', understanding arises through making. -Thanks to Alex (see <REF ID="acknowledge">) for this quote. +``verum ipsum factum'', which means ``understanding arises through making''. +Thanks to Alex (see <REF ID="acknowledge" NAME="Acknowledgements">) +for this quote. + +<P> +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. <P> Packages are presented in the order in which they appear in the system @@ -56,18 +70,6 @@ you can reboot after each installation, and see the system get a little closer to giving you a bash prompt each time. There is a reassuring sense of progress in this. -<P> -There are choices to make when putting together a Linux system. These are the -same choices that the likes of Red Hat and Debian must make when creating a -distribution. There are often several free packages available to do the same -job. What I describe here are the components that are part of the major Linux -distributions. I choose GNU software if it is available because it is better -documented, and causes less headaches. It would be possible to get a bash -prompt without installing everything I mention here. However I want to -describe a base system that can be built on easily, without nasty kludges. -For example, one of the init scripts uses awk. (Don't worry if you don't -know what awk is) Rather than hack this out of the script, I just install awk. - <P> I recommend that you first read the main text of each section, skipping the exercises and references. Then decide how deep an understanding you want to @@ -84,7 +86,8 @@ in working order. This is called the ``Power on self test''. Then a program called the bootstrap loader, located in the ROM BIOS, looks for a boot sector. A boot sector is the first sector of a disk and has a small program that can load an operating system. Boot sectors are marked with a magic -number 0xAA55 = 43603 at byte 0x1FE = 500. This is how the hardware can tell +number 0xAA55 = 43603 at byte 0x1FE = 510. That's the last two bytes of the +sector. This is how the hardware can tell whether the sector is a boot sector or not. <P> @@ -119,24 +122,34 @@ 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://www.unios.org" NAME=Unios>. -This is just a bootable "Hello World!" program, consisting of just over 100 +<URL URL="http://learning.taslug.org.au/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 lines of assembler code. It would be good to see it converted to a format that the GNU assembler <TT>as</TT> can understand. +<P> +Open the boot disk image for unios with a hex editor. This image is 512 bytes +long, exactly one sector. Find the magic number 0xAA55. Do the same for +the boot sector from a bootable floppy disk or your own computer. You can +use the <TT>dd</TT> command to copy it to a file: <TT>dd if=/dev/fd0 of=boot.sector</TT>. +Be <EM>very</EM> careful to get <TT>if</TT> (input file) and <TT>of</TT> +(output file) the right way round! <P> Check out the source code for LILO's boot loader. <SECT1>More Information <P> <ITEMIZE> -<ITEM><EM>The Unix and Internet Fundamentals HOWTO</EM>, by Eric S. Raymond, -<URL URL="http://mirror.aarnet.edu.au/linux/LDP/HOWTO/Unix-Internet-Fundamentals-HOWTO.html"> +<ITEM> +<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> <ITEM>The first chapter of <EM>The LILO User's Guide</EM> gives an excellent explanation of PC disk partitions and booting. -See <REF ID="lilo-links" NAME="LILO"> for a URL. +See section <REF ID="lilo-links" NAME="LILO"> for a URL. <ITEM><EM>The NEW Peter Norton Programmer's Guide to the IBM PC & PS/2</EM>, by Peter Norton and Richard Wilton, Microsoft Press 1988 @@ -164,7 +177,7 @@ There are lots of different ways to set your system up to boot. What I have just <P> The configuration file for lilo is <TT>/etc/lilo.conf</TT>. There is a manual page for it: type <TT>man lilo.conf</TT> into a shell to see it. The main thing -in lilo.conf is one entry for each thing that lilo is set up to boot. For a +in <TT>lilo.conf</TT> is one entry for each thing that lilo is set up to boot. For a Linux entry, this includes where the kernel is, and what disk partition to mount as the root filesystem. For other operating systems, the main piece of information is which partition to boot from. @@ -203,11 +216,8 @@ to make a five point loop. Fun! <LABEL ID="lilo-links"> <ITEMIZE> <ITEM>The lilo man page. -<ITEM>Lilo <URL URL="ftp://lrcftp.epfl.ch/pub/linux/local/lilo/" - NAME="download">, - Australian <URL URL="ftp://mirror.aarnet.edu.au/pub/linux/metalab/system/boot/lilo/" - NAME="mirror">. - These directories also contain the ``LILO User's Guide'' +<ITEM>The Lilo package (see <REF ID="downloads" NAME="downloads">) + contains the ``LILO User's Guide'' <TT>lilo-u-21.ps.gz</TT> (or a later version). You may already have this document though. Check <TT>/usr/doc/lilo</TT> or there abouts. @@ -215,7 +225,7 @@ to make a five point loop. Fun! since it contains diagrams and tables. <ITEM><URL URL="http://www.toms.net/rb" NAME="tomsrtbt"> the coolest single floppy linux. Makes a great rescue disk. -<ITEM><URL URL="http://mirror.aarnet.edu.au/linux/LDP/HOWTO/Bootdisk-HOWTO.html" +<ITEM><URL URL="http://www.linuxdoc.org/HOWTO/Bootdisk-HOWTO/" NAME="The Bootdisk HOWTO"> </ITEMIZE> @@ -286,8 +296,8 @@ information. When you copy the kernel to the target system, copy <P>Think about this: <TT>/dev/hda3</TT> is a special type of file that describes a hard disk partition. But it lives on a file system just like all other files. The kernel wants to know which partition to mount as the root -filesystem - it doesn't have a file system yet. So how can it read /dev/hda3 to -find out which partition to mount? +filesystem - it doesn't have a file system yet. So how can it read +<TT>/dev/hda3</TT> to find out which partition to mount? <P> If you haven't already: build your own kernel. Read all the help information @@ -316,14 +326,7 @@ 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 - Australian - <URL URL="http://kernel.mirror.aarnet.edu.au/pub/linux/kernel/" - NAME="mirror"> -<ITEM>The Linux Kernel - <URL URL="http://www.kernel.org" NAME="home page"> - <URL URL="ftp://ftp.kernel.org/pub/linux/kernel" NAME="download"> - Use one of the mirrors listed at <TT>kernel.org</TT>, because they - are always overloaded. +<ITEM> Kernel source download see <REF ID="downloads" NAME="downloads"> </ITEMIZE> @@ -397,18 +400,7 @@ a program that uses this library. <SECT1>More Information <P> <ITEMIZE> -<ITEM>Australian GNU libc - <URL URL="http://mirror.aarnet.edu.au/pub/gnu/glibc" - NAME="mirror">. You will also need the linuxthreads and libcrypt addons. - If libcrypt is not there it is because of some US export laws. There - will be a README or some such saying where you can get it from. -<ITEM>Australian GNU ncurses - <URL URL="http://mirror.aarnet.edu.au/pub/gnu/ncurses" - NAME="mirror">. Ncurses is a library that provides a lot of text screen - capabilities. It includes the terminfo database, which replaces the - termcap file. You can (and probably should) compile ncurses as a glibc - addon. - +<ITEM>source code, see section <REF ID="downloads" NAME="downloads"> </ITEMIZE> @@ -416,11 +408,12 @@ a program that uses this library. <SECT>Init <P> I will only talk about the ``System V'' style of init that Linux systems mostly -use. There are alternatives. Infact, you can put any program you like in +use. There are alternatives. In fact, you can put any program you like in <TT>/sbin/init</TT>, and the kernel will run it when it has finished loading. <P> -It is inits job to get everthing running the way it should be. It checks that +It is <TT>init</TT>'s job to get everthing running the way it should be. +It checks that the file systems are ok and mounts them. It starts up ``daemons'' to log system messages, do networking, serve web pages, listen to your mouse and so on. It also starts the getty processes that put the login prompts on your virtual @@ -452,7 +445,7 @@ These scripts are really just links to scripts in another directory usually called <TT>init.d</TT>. <P> -So our run-level script was called by init, and it is looking in a directory for scripts starting with `S'. It might find <TT>S10syslog</TT> first. The numbers tell the run-level script which order to run them in. So in this case <TT>S10syslog</TT> gets run first, since there were no scripts starting with S00 ... S09. But <TT>S10syslog</TT> is really a link to <TT>/etc/init.d/syslog</TT> which is a script to start and stop the system logger. Because the link starts with an `S', the run-level script knows to execute the <TT>syslog</TT> script with a ``start'' parameter. There are corresponding links starting with `K', which specify what to shut down and in what order when leaving the run-level. +So our run-level script was called by <TT>init</TT>, and it is looking in a directory for scripts starting with `S'. It might find <TT>S10syslog</TT> first. The numbers tell the run-level script which order to run them in. So in this case <TT>S10syslog</TT> gets run first, since there were no scripts starting with S00 ... S09. But <TT>S10syslog</TT> is really a link to <TT>/etc/init.d/syslog</TT> which is a script to start and stop the system logger. Because the link starts with an `S', the run-level script knows to execute the <TT>syslog</TT> script with a ``start'' parameter. There are corresponding links starting with `K' (for kill), which specify what to shut down and in what order when leaving the run-level. <P> To change what subsystems start up by default, you must set up these links in @@ -463,8 +456,10 @@ the <TT>rcN.d</TT> directory, where N is the default runlevel set in your The last important thing that init does is to start some <TT>getty</TT>'s. These are ``respawned'' which means that if they stop, <TT>init</TT> just starts them again. Most distributions come with six virtual terminals. You may -want less than this to save memory, or more so you can leave things running and -quickly flick to them as you need them. You may also want to run a getty for a +want less than this to save memory, or more so you can leave lots of +things running and +quickly flick to them as you need them. You may also want to run a +<TT>getty</TT> for a text terminal or a dial in modem. In this case you will need to edit the <TT>inittab</TT> file. @@ -512,12 +507,7 @@ This is a good exercise in learning Bash shell scripting too, some of the script <SECT1>More Information <P> <ITEMIZE> -<ITEM>Australian Sys V init - <URL URL="http://mirror.aarnet.edu.au/pub/linux/metalab/system/daemons/init" - NAME="mirror"> -<ITEM>Sys V init - <URL URL="http://sunsite.unc.edu/pub/Linux/system/daemons/init" - NAME="download"> +<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 @@ -549,7 +539,8 @@ inodes of the files that are in the directory. If the system wants to read <TT>/home/greg/bigboobs.jpeg</TT>, it first finds the inode for the root directory <TT>/</TT> in the ``superblock'', then finds the inode for the directory <TT>home</TT> in the contents of <TT>/</TT>, then finds the inode for -the directory <TT>greg</TT>, then the inode for <TT>bigboobs.jpeg</TT> which +the directory <TT>greg</TT> in the contents of <TT>/home</TT>, +then the inode for <TT>bigboobs.jpeg</TT> which will tell it which disk blocks to read. @@ -570,8 +561,8 @@ system read-only. The mount command is used to remount it read-write after Linux supports other kinds of filesystem too: msdos, vfat, minix and so on. The details of the specific kind of filesystem are abstracted away by the virtual file system (VFS). I won't go into any detail on this though. There is a -discussion of it in ``The Linux Kernel'' (see <REF ID="Kernel" NAME="The Linux -Kernel"> for a url) +discussion of it in ``The Linux Kernel'' +(see section <REF ID="Kernel" NAME="The Linux Kernel"> for a url) <SECT1>Configuration <P> @@ -603,7 +594,7 @@ 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="util-linux" NAME="Login and Getty">. + to it in <REF ID="downloads" NAME="downloads">. <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" @@ -612,12 +603,12 @@ Check out the ext2 filesystem code in the Kernel. NAME="ext2fsprogs"> Australian mirror. There is also a Ext2fs-overview document here, although it is out of date, and not as readable as chapter 9 of ``The Linux Kernel'' -<ITEM> <URL URL="ftp://mirror.aarnet.edu.au/pub/linux/metalab/system/admin/" - NAME="MAKEDEV"> This is a script to make all the device files in - <TT>/dev</TT> -<ITEM> <LABEL ID="FHS"> +<ITEM> <LABEL ID="FHS"> <URL URL="ftp://tsx-11.mit.edu/pub/linux/docs/linux-standards/fsstnd/" - NAME="Unix File System Standard"> This describes what should go where + NAME="Unix File System Standard"> + Another <URL URL="http://www.pathname.com/fhs/" + NAME="link"> to the Unix File System Standard. + This describes what should go where in a Unix file system, and why. It also has minimum requirements for the contents of <TT>/bin</TT>, <TT>/sbin</TT> and so on. This is a good reference if your goal is to make a minimal yet complete system. @@ -677,6 +668,39 @@ when init arrives on the scene? <P> I put a script to mount <TT>/proc</TT> and do a <TT>ps aux</TT> in <TT>/sbin/init</TT>. Process 1 was the script itself, and processess 2, 3, 4 and 5 were the kernel daemons just as under the real init. The kernel must put these processes there, because my script certainly didn't! +<P> +The following ramblings were contributed by David Leadbeater: + +<P> +These processes seem to take care of disk reads and writes, they seem to be +started by the kernel but after it runs the init process, it seems that being +run as kernel processes rather than seperate processess they are protected from +being killed (kill -9 dosen't stop them), I am not sure why they are run as +seperate threads (it seems to be something with disk access) + +<p><em>kflushd and kupdate</em> +These two processes are started to flush dirty (changed) buffers back to disk. +kflushd is run when the buffers are full and kupdate runs periodically (5 +seconds?) to sync the disk and the buffers in memory. + +<p><em>kpiod and kswapd</em> +These deal with paging out pages (sections) of memory into the swap file so +main memory never gets exhausted, these are similar to kflushd and kupdate in +that one is run when needed kpiod and the other kswapd is run peridically (1 +second intervals) + +<p><em>Other Kernel Daemons</em> +On a default install of RH6 kupdate is missing but update is running as a user +space daemon so it seems it needs to be run! Also another daemon mdrecoveryd is there, this seems to be dealing with software RAID, looking at the kernel source it seems that some SCSI drivers also start seperate processes. + +<p> +I am still unsure of the meaning of the brackets but it seems that they appear +when the RSS of a process is 0 meaning it isn't using any memory? + +<p> +(end of ramble, thanks David) + +<P> <SECT1>Configuration <P> I don't know of any configuration for these kernel daemons. @@ -687,8 +711,9 @@ Find out what these processes are for, how they work, and write a new ``Kernel D <SECT1>More Information <P> -The Linux Documentation Project's ``The Linux Kernel'' (see <REF ID="Kernel" NAME="The Linux Kernel"> for url), and the kernel source code are all I can think of. - +The Linux Documentation Project's ``The Linux Kernel'' +(see section <REF ID="Kernel" NAME="The Linux Kernel"> for a url), +and the kernel source code are all I can think of. <SECT>System Logger @@ -705,7 +730,9 @@ wrong with your system. Often there will be a valuable clue in there. The file <TT>/etc/syslog.conf</TT> tells the loggers what messages to put where. Messages are identified by which service they come from, and what priority level they are. This configuration file consists of lines that say messages from service x with priority y go to z, where z is a file, tty, printer, remote host or whatever. <P> -NOTE: Syslog requires the <TT>/etc/services</TT> file to be present. The services file allocates ports. I am not sure whether syslog needs a port allocated so that it can do remote logging, or whether even local logging is done through a port. +NOTE: Syslog requires the <TT>/etc/services</TT> file to be present. The services file allocates ports. I am not sure whether syslog needs a port allocated so that it can do remote logging, or whether even local logging is done through a port, +or whether it just uses <TT>/etc/services</TT> to convert the service names +you type <TT>/etc/syslog.conf</TT> into port numbers. <SECT1>Exercises <P> @@ -727,14 +754,16 @@ Getty is the program that enables you to log in through a serial device such as <P> -There are many getty's available, but the util-linux package, which includes -<TT>login</TT> has one called <TT>agetty</TT>, which works fine. This package also -contains <TT>clock</TT>, <TT>fdformat</TT>, <TT>mkswap</TT>, <TT>fdisk</TT>, +There are many getty's available. Some distributions, including Red Hat use +a very small one called <TT>mingetty</TT> that only works with virtual terminals. + +<P> +The <TT>login</TT> program is part of the util-linux package, which also +contains a getty called <TT>agetty</TT>, which works fine. This package also +contains <TT>mkswap</TT>, <TT>fdisk</TT>, <TT>passwd</TT>, <TT>kill</TT>, <TT>setterm</TT>, <TT>mount</TT>, -<TT>swapon</TT>, <TT>rdev</TT>, <TT>renice</TT>, <TT>hexdump</TT>, +<TT>swapon</TT>, <TT>rdev</TT>, <TT>renice</TT>, <TT>more</TT> (the program) and more (ie more programs). -To keep things simple by minimising the number of packages you have to install, -I recommend using <TT>agetty</TT>. <SECT1>Configuration <P> @@ -752,18 +781,6 @@ than the man page for the program. -<SECT1>More Information -<LABEL ID="util-linux"> -<P>The <URL URL="ftp://mirror.aarnet.edu.au/pub/linux/metalab/system/misc" - NAME="util-linux"> - package contains login and agetty, and lots of other stuff that you will need. -<P>There are lots of other getty's at - <URL URL="ftp://mirror.aarnet.edu.au/pub/linux/metalab/system/serial/getty" - NAME="Many getty's!">. getty_ps is the most general one, mingetty is for - virtual terminals only. However, the util-linux package which you need - for <TT>logon</TT> also contains <TT>agetty</TT>, which works fine. - - <SECT>Bash <P> If you give <TT>login</TT> a valid username and password combination, it will @@ -795,7 +812,7 @@ for f in /home/greg/sh-utils-1.16*.patch; do patch -p0 < $f; done; <P> This looks at all the files in my home directory whose names start with <TT>sh-utils-1.16</TT> and end with <TT>.patch</TT>. It then takes each of -these in turn, and sets the variable <TT>f</TT> to itand executes the commands +these in turn, and sets the variable <TT>f</TT> to it and executes the commands between <TT>do</TT> and <TT>done</TT>. In this case there were 11 patch files, but there could just as easily have been 3000. @@ -832,7 +849,7 @@ editor. <SECT1>Exercises <P> The basics of bash are easy to learn. But don't stop there: there is an -incredible depth to it. get into the habit of looking for better ways to do +incredible depth to it. Get into the habit of looking for better ways to do things. <P> @@ -841,182 +858,557 @@ Read shell scripts, look up stuff you don't understand. <SECT1>More Information <P> <ITEMIZE> -<ITEM> Australian Bash <URL URL="http://mirror.aarnet.edu.au/pub/gnu/bash" - NAME="mirror"> +<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> Australian readline <URL URL="http://mirror.aarnet.edu.au/pub/gnu/readline" - NAME="mirror"> You need to download readline separately ((is it an addon type thingy?)) -<ITEM>((bash tutorials? - if there isn't one around, make one!)) <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. </ITEMIZE> -<SECT>Basic Commands +<SECT>Commands <P> -You do most things in bash by issuing commands. Most of these commands are -small programs. I won't say too much about these. I have just listed the -packages that I found I needed. I fear that I may have lost track slightly of -what was really necessary and what wasn't. I will fix this when I rebuild -my system to test this document. There isn't too much baggage in the list. -Most of it is needed for a fully functional Linux system anyway. +You do most things in bash by issuing commands like <TT>cp</TT>. Most of these commands are +small programs, though some, like <TT>cd</TT> are built into the shell. <P> -Ideally, this list should include all commands specified in -The Unix <REF ID="FHS" NAME="File Heirarchy Standard"> -and everthing needed to run the basic initscripts -that come with the sysvinit dist. - -<P> -<ITEMIZE> -<ITEM>GNU fileutils - <URL URL="http://mirror.aarnet.edu.au/pub/gnu/fileutils/" - NAME="fileutils"> commands such as cp, dd, ls, ln, mkdir and so on. -<ITEM>GNU findutils - <URL URL="http://mirror.aarnet.edu.au/pub/gnu/findutils/" - NAME="findutils"> find and locate commands. Find is needed in an - init script ((check your notes on this)). -<ITEM>textutils? was that needed?? it contains <TT>cat</TT>, which is nice to have - so you can look a files. its GNU -<ITEM>Gawk - <URL URL="http://mirror.aarnet.edu.au/pub/gnu/gawk/" - NAME="gawk"> GNU's implementation of the awk language. Awk - is good for processing records in text files like the system log. - It is needed in an init script ((check your notes on this)). -<ITEM>grep - <URL URL="http://mirror.aarnet.edu.au/pub/gnu/grep/" - NAME="grep"> - It is needed in an init script ((check your notes on this)). -<ITEM>sed?? was that needed?? it's a GNU package -<ITEM><TT>sh-utils</TT> contains <TT>hostname</TT>, <TT>stty</TT>, <TT>true</TT>, - <TT>false</TT>, <TT>yes</TT>, <TT>who</TT>, <TT>sleep</TT> -<ITEM>Net Tools: is probably not completely necessary, since <TT>hostname</TT> - is in <TT>sh-utils</TT> - <URL URL="ftp://mirror.aarnet.edu.au/pub/linux/metalab/?????????????????" - NAME="net-tools">. The only thing you *really* need from this package, - to get a really basic system up is hostname. But the other stuff in here - such as, ifconfig, netstat and route will be needed when you want to - connect your system to anything else. -<ITEM>Process Monitoring - <URL URL="ftp://mirror.aarnet.edu.au/pub/linux/metalab/system/status/ps/" - NAME="procps">. The main commands in here are ps and top. They enable - you to see what is running on your system. This is useful for a learning - exercise. -</ITEMIZE> +The commands come in packages, most of them from the Free Software Foundation (or GNU). +Rather than list the packages here, I'll direct you to the +<URL URL="http://www.linuxfromscratch.org" NAME="Linux From Scratch HOWTO">. +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 Software From Source +<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. - -<SECT1>How I Built My System -<P> -There is more than one way to go about building a system. But the -way I did it seems to have worked out ok, so this account may be helpful to you. +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> -I used a dedicated -machine - an old Wang 386sx of almost zero dollar value. I did a minimal -install of Red Hat 6.0 to be the ``source'' system, and allocated a ``target'' -partition where I built the system. In the old Wang, I have a 3G hard disk -partitioned as follows: +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. -<VERB> - hda1 480M where I built the system (``target'') - hda2 20M boot partition for the Red Hat system - hda3 50M swap - hda4 2500M extended partition containing hda5 - hda5 2500M Red Hat 6.0 root file system (``source'') -</VERB> + +<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> -There is no real point in having the logical partition hda5 inside an extended -partition, hda4. That's just what Red Hat's Disk Druid did when I installed. -You only need the base Red Hat system, plus development tools and libraries. -It used about 250M of disk space. You could do this exercise with a 1G disk, -or a pair of 500M disks. +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. But for Linux to get loaded by these old machines, -it has be reside somewhere below 512M. This is why I have both the whole -target partition, and the small boot partition for the source system -below the 512M mark. +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> -You may wish to actually use the target system, rather than simply build it for -a learning exercise. In this case, you would need to go a bit beyond what is -described in this document. You would need to install <TT>gcc</TT> and other -development tools so that the system could build itself. Once this was done, -you could wipe the ``source'' system and use its space on the target. Perhaps -you could move the <TT>/usr</TT> directory to it. +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 Wang only has 8M of RAM in it. I think this is -the main reason that the compile of <TT>glibc</TT> took 90 hours (and spanned -millenia). It ``only'' took 6 hours on my 486 with 32M. My guess is that if -I had 16M in the Wang, it would have taken 24 to 48 hours. Kernel compiles -take about 8 hours. +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> -I made an ext2 file system on the target partition using <TT>mke2fs</TT>, and -created directories by hand using <TT>mkdir</TT>. I didn't have it at the time, -but the <REF ID="FHS" NAME="Filesystem Heirarchy Standard"> would have been a -good thing to follow. +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> -In the <TT>fstab</TT> of the source system, I set up the target partition to -be mounted at <TT>/mnt/target</TT>. Most of the packages have a configuration -option for where they are to be installed. By default, the ``base'' directory -for a package installation is <TT>/</TT>, ie you want to install it on the -system where it is being built. I used these options to set the base install -directory to <TT>/mnt/target</TT>. For example, to install a GNU package to -<TT>/mnt/target</TT>, you configure as follows +<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>. -<VERB> - ./configure --prefix=/mnt/target +</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> -There is a problem with this approach if some of the packages of the target -system are more recent than their equivalents on the source system. For -example, I installed ncurses 5 on the target system, but the source had 4. -When compiling, by default the headers and libraries of the source system -are used. To fix this you need to set variables or configuration parameters -to tell it where the headers and libraries that you want it to use are. -Sometimes all you can do is hack the <TT>Makefile</TT>. If you look at the -output that is produced while a program is being compiled, the <TT>-I</TT> -flags tell it where to look for headers, and the <TT>-L</TT> flags tell it -where to look for libraries. Look for a variable called <TT>LDFLAGS</TT>. -This is probably where you can slip a couple extra of these flags in, and -make it look where you want. For example in the <TT>Makefile</TT> for the -<TT>procps</TT> package, I got it to use the right libraries by adding +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> - -L /mnt/target/lib + ROOT=/mnt/target make install </VERB> <P> -LILO is installed in the master boot record by Red Hat. I installed LILO for -the target system in the boot sector of the target partition. I then added -the following to <TT>/etc/lilo.conf</TT> in the source system +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> -other=/dev/hda1 - label=target + + ./QuickInst: /boot/bzImage: no such file </VERB> -and reran <TT>lilo</TT>. This has the effect that when you first boot, -one of the options LILO gives you is ``target''. If you choose this, you -get a second instance of LILO which boots the target system. This might -seem crazy, but it allows the separation of the system you are building -from the system you are using to build it with. +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: @@ -1031,31 +1423,20 @@ 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 </VERB> - <P> -Once you have a bash prompt, the next stage is to get your system able to -self replicate. I have not done this yet, but the following are some of -the things you will need to install to do this. - -<ITEMIZE> -<ITEM>GNU make -<ITEM>GNU egcs -<ITEM>gdb -<ITEM>binutils - assembler, linker, etc; bin86 - intel specific versions -<ITEM>tar, gzip, bzip2 -<ITEM>diff comes from diffutils, patch comes from patch, hehe -</ITEMIZE> +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://mirror.aarnet.edu.au/linux/LDP/HOWTO/mini/Software-Building.html" + <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://mirror.aarnet.edu.au/pub/linux/LDP/HOWTO/Linux-From-Scratch-HOWTO.html" + <URL URL="http://www.linuxfromscratch.org" NAME="The Linux From Scratch HOWTO"> </ITEMIZE> @@ -1072,7 +1453,7 @@ This document is copyright (c) 1999, 2000 Greg O'Keefe. You are welcome to use, copy, distribute or modify it, without charge, under the terms of the <URL URL="http://www.gnu.org/copyleft/gpl.html" NAME="GNU General Public Licence">. -Please acknowledge me if you use part of this in another document. +Please acknowledge me if you use all or part of this in another document. <SECT1>Homepage <P> @@ -1116,14 +1497,36 @@ For reminding me about Unios. For some good clues about <TT>/etc/passwd</TT> <TAG>sPaKr on #linux in efnet</TAG> Who sussed out that syslogd needs <TT>/etc/services</TT>, -and introduced me to the phrase "rolling your own" to +and introduced me to the phrase ``rolling your own'' to describe building a system from source code. <TAG>Alex Aitkin</TAG> For bringing Vico and his ``verum ipsum factum'' (understanding arises through making) to my attention. +<TAG>Dennis Scott</TAG> +For correcting my hexidecimal arithmetic. +<TAG>jdd</TAG> +For pointing out some typos. +<TAG>David Leadbeater</TAG> +For contributing some ``ramblings'' about the kernel deamons. </DESCRIP> <SECT1>Change History + +<SECT2>0.6 -> 0.7 +<P> +<ITEMIZE> +<ITEM>more emphasis on explanation, less on how to build a system, + building info gathered together in a separate section + and the system built is trimmed down, + direct readers to Gerard Beekmans' ``Linux From Scratch'' doc + for serious building +<ITEM>added some ramblings contributed by David Leadbeater +<ITEM>fixed a couple of url's, added link to unios download at + learning.taslug.org.au/resources +<ITEM>tested and fixed url's +<ITEM>generally rewrite, tidy up +</ITEMIZE> + <SECT2>0.5 -> 0.6 <P> <ITEMIZE> @@ -1134,10 +1537,13 @@ For bringing Vico and his ``verum ipsum factum'' <SECT1>TODO <P> <ITEMIZE> -<ITEM>add links to home sites, not just the aarnet mirror -<ITEM>add more exercises -<ITEM>wipe the target system on the Wang, and rebuild, closely following these notes as a test -<ITEM>check that all packages specified as kernel requirements (state version) are included +<ITEM>explain kernel modules, depmod, modprobe, insmod and all that + (I'll have to find out first!) +<ITEM>mention the /proc filesystem, potential for exercises here +<ITEM>convert to docbook sgml +<ITEM>add more exercises, perhaps a whole section on larger exercises, + like creating a minimal system file by file from a distro + install. </ITEMIZE> </ARTICLE>