Briefly, what I am going to cover this evening is the "Linux From Scratch" project. Founded by Gerard Beekmans,First of all LinuxFromScratch is a book. However, since its aim is a moving target it lives on-line and is constantly updated so as to remain current.
A large and very active community has grown up around the LFS project. The book has gone through many revisions and this community of users and developers have debugged it to a very fine degree.
The LFS 'book' is essentially a learning guide for building a basic Linux operating system from original source packages. LFS strives to use the latest stable version of the packages needed. For more cutting edge development check out the CVS version.
Just a note here. While LFS may be described as a 'learning guide' it is still a serious undertaking. I used an LFS built system for the file server on my LAN. It now has 469 days of uptime. Its run has about come to an end as I have run out of room, so it is time to take it apart to upgrade the hardware.
Having used a number of different Linux distributions, I was never fully satisfied with any of them. I didn't like the way the bootscripts were arranged, I didn't like the way certain programs were configured by default, and more of those things. I came to realize that if I wanted to be fully satisfied with a Linux system, I would have to build my own system from scratch, ideally using only the source code. Not using pre-compiled packages of any kind. No help from some sort of CD-ROM or bootdisk that would install some basic utilities. I would use my current Linux system and use that one to build my own.This, at one time, wild idea seemed very difficult and at times almost impossible. After sorting out all kinds of dependency problems, compile problems, etcetera, a custom-built Linux system was created and fully operational. I called this system an LFS system, which stands for Linux From Scratch.
I hope all of you will have a great time working on LFS!
--
Gerard Beekmans
gerard@linuxfromscratch.org
Table of Contents
Preface
Foreword
Who would want to read this book
Who would not want to read this book
Organization
Part I - Introduction
Part II - Installation of the LFS system
Part III - Appendixes
I. Part I - Introduction
1. Introduction
Acknowledgments
How things are going to be done
Conventions used in this book
Book version
Mirror sites
Changelog
Mailing lists and archives
News server
FAQ
Contact information
2. Important information
About $LFS
How to download the software
How to install the software
Which Platform?
How to ask for help
II. Part II - Installing the LFS system
3. Packages that need to be downloaded
Introduction
Packages that need to be downloaded
4. Preparing a new partition
Introduction
Creating a new partition
Creating a file system on the new partition
Mounting the new partition
5. Preparing the LFS system
Introduction
Why do we use static linking?
Install all software as an unprivileged user
Creating directories
Installing Bash-2.05a
Installing Binutils-2.12
Installing Bzip2-1.0.2
Installing Diffutils-2.8
Installing Fileutils-4.1
Installing Gawk-3.1.0
Installing GCC-2.95.3
Installing Grep-2.5
Installing Gzip-1.2.4a
Installing Linux Kernel-2.4.18
Installing Make-3.79.1
Installing Patch-2.5.4
Installing Sed-3.02
Installing Sh-utils-2.0
Installing Tar-1.13
Installing Texinfo-4.1
Installing Textutils-2.0
Creating passwd and group files
Copying old NSS library files
Mounting $LFS/proc file system
6. Installing basic system software
Introduction
About debugging symbols
Creating $LFS/root/.bash_profile
Entering the chroot'ed environment
Changing ownership of the LFS partition
Creating the /etc/mtab symlink
Installing Glibc-2.2.5
Creating devices (Makedev-1.4)
Installing Man-pages-1.48
Installing Findutils-4.1
Installing Gawk-3.1.0
Installing Ncurses-5.2
Installing Vim-6.1
Installing GCC-2.95.3
Installing Bison-1.34
Installing Less-374
Installing Groff-1.17.2
Installing Man-1.5j
Installing Perl-5.6.1
Installing M4-1.4
Installing Texinfo-4.1
Installing Autoconf-2.53
Installing Automake-1.6
Installing Bash-2.05a
Installing Flex-2.5.4a
Installing File-3.37
Installing Libtool-1.4.2
Installing Bin86-0.16.2
Installing Binutils-2.12
Installing Bzip2-1.0.2
Installing Ed-0.2
Installing Gettext-0.11.1
Installing Kbd-1.06
Installing Diffutils-2.8
Installing E2fsprogs-1.27
Installing Fileutils-4.1
Installing Grep-2.5
Installing Gzip-1.2.4a
Installing Lilo-22.2
Installing Make-3.79.1
Installing Modutils-2.4.15
Installing Netkit-base-0.17
Installing Patch-2.5.4
Installing Procinfo-18
Installing Procps-2.0.7
Installing Psmisc-20.2
Installing Reiserfsprogs-3.x.1b
Installing Sed-3.02
Installing Sh-utils-2.0
Installing Net-tools-1.60
Installing Shadow-4.0.3
Installing Sysklogd-1.4.1
Installing Sysvinit-2.84
Installing Tar-1.13
Installing Textutils-2.0
Installing Util-linux-2.11o
Installing LFS-Bootscripts-1.9
Removing old NSS library files
Configuring essential software
7. Setting up system boot scripts
Introduction
How does the booting process with these scripts work?
Configuring the setclock script
Do I need the loadkeys script?
Configuring the sysklogd script
Configuring the localnet script
Creating the /etc/hosts file
Configuring the network script
8. Making the LFS system bootable
Introduction
Creating the /etc/fstab file
Installing linux-2.4.18
Making the LFS system bootable
9. The End
The End
Get Counted
Rebooting the system
III. Part III - Appendixes
A. Package descriptions and dependencies
B. Resources
Introduction
Books
HOWTOs and Guides
Other
When writing a program, rather than having to rewrite all the functions for dealing with the kernel, hardware, files, etc. every time you write a new program, all these basic functions are instead kept in libraries...
The programmer then simply writes library calls to have these standardized routines incorporated into the program. This also greatly diminishes errors.
These libraries can be quite large. So instead of having multiple copies built into every program that needs them, they live in a separate file. Then when the program needs code from a particular library it is loaded into memory.
Additionally, if two programs need the same library at the same time only one copy is loaded into memory and is then shared between them.
Why then are we building statically linked packages? Because the libraries will not be available in the chroot environment until we have a chance to build them.
SysVinit
It's based on a concept of runlevels. It can be widely different from one system.the book uses lilo but there is a grub hint
compile and install the kernel
/sbin/lilo
reboot
Yea! Yea! Yea!