LFS Write up -- Part 1 -- RFC

Doumbeck1 at aol.com Doumbeck1 at aol.com
Wed Nov 21 14:29:07 PST 2001


Hey guys,
    I wrote this article for my LUG and apparently one of our members is a 
osdn rep...so anyway, he was really interested in publishing this 
article....I wanted your peer review and approval from up above...

Thanx,
    Scot Mc Pherson


-----------------------------
Linux From Scratch
    Compelling Reasons to Compile
    or
    Not For The Faint of Heart

By Scot Mc Pherson



Caveat


    I use a few phrases interchangeably. "Base system" is a phrase I use both 
for the original installed distribution Linux system, and it is also my 
description of what a completed LFS system is, it's a base system. Sorry for 
the confusion, but "base system" works very well for both situations. Reading 
it in context should make it clear what I mean. I try to make it clear in the 
sentence or paragraph which base system I mean.

COPYRIGHT NOTICE: All Rights are Reserved. This white paper may be reproduced 
and distributed at will so long as the following conventions are adhered to. 
This document must be duplicated exactly as is. If you want to publish it, go 
ahead but as a courtesy please inform me first and give me the opportunity to 
polish it. It must be published in its entirety.





Introduction


    I am not going to go through the typical introduction to Linux (pron. 
LIH-nux) that many authors have provided seemingly with every article written 
about Linux. I am going to start by saying that Linux is an addition to the 
Unix family of operating systems. It was written by a Finnish Grad 
Student/hacker named Linus Torvalds (pron. LEE-nus) and was initially 
released in the fall of 1991. It and its acceptance has grown ever since. 
That is all on that.

    Do you think you know a lot about Linux? Well unless you are some sort of 
uber-hacker or Linus or Alan Cox, LFS (Linux From Scratch) has something to 
teach you. Until you actually have to hunt down tar.gz source files on the 
net and figure out how to compile and install them successfully and to your 
liking, you haven't experienced Linux. You are probably reading this either 
because you want to be convinced to use LFS or you want to find something to 
debunk. Either way, read on. At the end I am going to go through some 
point-by-point PROS and CONS of LFS. The funniest part about writing this 
article is something I realized about the most common arguments. They are 
almost identical to the arguments between the Linux camp and MS Windows camp. 
So if you think you have something to say on the MS vs. Linux front, then I 
bet you can apply the same arguments here, just graduated by one step or 
degree.

    Today we have many choices in how we implement Linux systems. We have 
offered to us easily over 100 different flavors of Linux operating systems 
ranging from the immensely popular and well-recognized distributions such as 
RedHat, Debian, Mandrake, Slackware, SuSE, and YellowDog all the way down to 
more obscure implementations like, BeeHiveLinux, Wolverine, easyLinux and 
other distributions skilled hackers have put together. Lets not forget the 
utility distributions, such as tomsrtbt, which are used to diagnose and 
repair your system when all else fails. So much to choose from, and yet they 
are the result of other people's efforts and therefore other peoples visions 
of how a system should operate.

    Have you ever had that moment when you become dissatisfied with your 
current favorite distro and renew the hunt for the perfect distro? I know I 
was in that situation when RedHat-7.0 was released. I was the perfect RedHat 
customer and user. I supported RedHat each time I purchased a copy of every 
CD RedHat produced from 3.somethingerrather all the way up to 6.2. RedHat was 
a dream to work with. It was stable, it did what I configured it to do, and 
it didn't argue, too much. I never even considered looking elsewhere. Then 
RedHat-7.0 hit the shelves. Oh man, what a bummer that was. The distribution 
grew to outrageous size and was thoroughly broken to-boot (an expression, not 
system boot.) I went through installing it 50 times and running up2date and 
all the other fancy schmancy fix it schemes provided on www.redhat.com, but 
yet it always seemed to fail to meet my expectations of stability and 
usability. I couldn't compile software, and to make matter even worse they 
pulled the carpet from beneath me when they completely reorganized how the 
filesystem was arranged. /etc had 100's of files even if I wasn't using most 
of them and /dev was full of devices I never even heard of. Now let's be 
clear. I am not bashing RedHat; I think it's a fine company, which produces a 
fine product. My issue was and is with Linux distributions as a whole. If I 
were to suggest a distribution to a newcomer of Linux, I would suggest they 
begin with RedHat, Mandrake, Slackware, or SuSE. But for me, I needed 
something more (or less really.) Enough was enough.





The Search Begins


    I began my search. I won't list all the distributions I researched and 
tried, there are too many. But I will give you a summary of what I came 
across. I found SuSE with too much stuff and too big if you were downloading 
and wanted the neat stuff, Debian was way too old (XFree86 v 3?) unless you 
want to play with the CVS versions, and what the heck is tasksel, dselect, 
and dpkg? It was very confusing sorting through all the online deb files. At 
least RedHat provided a pretty complete description of what each obscure RPM 
provided. Slackware was probably the cleanest system I found, but you had to 
choose to install large packages to get one or two things out of the package. 
Slackware presently is my favorite distribution since I don't consider "Linux 
>From Scratch" (LFS as I will be calling it from here on out) a distribution. 
LFS is a system you compile completely from source code and not an installed 
distributed Linux, if I did lump it in with distros Slackware would be my 2nd 
favorite. Mandrake is the easiest to install, otherwise pretty much RedHat 
compiled for i586s, which is a good feature if you are performance conscious. 
Later I will explain why. Ok none of these was doing it for me. Some were 
worse some were better but since I was searching for "my" new system it had 
to be perfect.

    After a bunch of other systems I came across a website in November of 
2000 which at the time was rather obscure http://www.linuxfromscratch.org. I 
browsed the website and I talked to the people on the mailing lists and the 
irc chat room (irc.linuxfromscratch.org). It was fairly easy to convince me 
that I wasn't going to find what I wanted in other distros, I had already 
proved that to myself.





The First Attempt

    I being a person of wanting ensured stability began with LFS-2.4.2. Let 
me explain something here. "Linux From Scratch" is the name of a book. Its 
not a distributed set of binaries, and isn't even a distributed set of source 
code. http://www.linuxfromscratch.org does provide the necessary and some 
optional source code and patch files as a convenience to its user, developer 
and tester base. Rest assured they are unadulterated copies of the original 
sources. To say it again, they are merely gathered together in a single place 
for our convenience. If you wish to hunt for and gather all of the sources 
yourself, be my guest. When you have done so, do a checksum on them and the 
files you can download from www.LFS.org (remember I am shortcutting the 
name). You'll find you wasted a lot of time, but sometimes experiencing 
hardship for yourself is the best way to learn. Anyway back to the issue at 
hand.

    It took me some 3 weeks to compile my first system, although I have an 
excuse or rather a few excuses. I have my own family, my wife (Ginger) and my 
2 boys (Davis 3, and Morgan 10 months). So between my family and my 
meticulous and methodic combing of the LFS book contributed to the length of 
time it took me that first time. When I had completed it, I erased the old 
distribution I used as a development system to build this one (yes you need a 
Linux system to build a linux system, but I will get to that later too.) And 
now what? Oops. Oh man, I messed up, I can't do anything. Sure I have a Linux 
system and its brand spanking new in a few senses of the word, but it doesn't 
do anything. Boy did I have a lot to learn, I hadn't really thought this 
through. Ok, so I re-installed the old Linux system back onto the spare 
partition so I could get out on the Internet and download a few client 
packages like lynx, and lukeftp. I boot back into my LFS. Ok NOW I have the 
tools I need to get more tools. Oh well, I guess I didn't think it through 
first.





Continuing My Education


    The second time I compiled LFS, it took maybe 3 days and now that I have 
done it over 200 times I can get it done in about 4 hours on a fast computer 
around 500MHz (including installing the base system - a modified RedHat). It 
shouldn't take you 3 weeks your first time. I was one of those people that 
had to read and check and recheck each command I hand typed. And like I said 
earlier I had my family competing for my time. You can copy and paste with 
GPM if you like. I typed it out the first few times, because I was concerned 
about the indenting and such things. Now I realize I didn't need to worry 
about it and I am now the GPM copy and paste king. I still think hand typing 
it is a good way to really learn "how" to do it though.

    Slowly I added to my fileserver various bits and pieces of 
necessary/optional code and built myself many systems. From LFS-2.4.2 I moved 
on to 2.4.4, which was much nicer. After 2.4.4 the version 3 prereleases were 
coming out. I have always been afraid of beta software. But with some 
prodding of the LFS staff and user base I tried LFS-3pre2. I skipped 3pre1 
altogether. Man what I difference. It was much easier to build, and seemed 
more solid. I kept on building systems (oh hey, did I mention this becomes a 
very addictive hobby?? Well it is VERY addictive) and became slightly 
dissatisfied with 3pre2, and I started developing my own "fork" of LFS. 3pre3 
was released and I hated it (well hate is a strong word, but I didn't like it 
anyway). I skipped 3pre4, and finally a few months ago (Aug2001) LFS-3.0 was 
released. Immediately a problem was discovered regarding stripping of 
libraries, which rendered a system useless. Ugh...ok now my next step into 
the development world. The CVS version of LFS was considered to be plenty 
stable, and again with prodding, I was convinced to try it. Remember this is 
a book, not software. CVS versions of LFS are not exactly cutting edge 
either. CVS could easily be considered the "current state of the stable LFS". 
Testing of LFS systems is mostly dealt with in the bugzilla system and 
changes aren't implemented into CVS until and unless the changes have been 
tested by the author and project leader of LFS (Gerard Beekman) and bunch of 
users which make sure a system is regression tested before the system is 
committed to CVS. Regression testing is a pretty thorough test of almost 
every part of the LFS base system. Regression testing includes compiling and 
using GCC, XFree86, QT, KDE and GNOME. This might not seem like much, but 
until you have tried it, don't scoff. Testing by compiling, installing and 
using those 5 items is a very thorough testing of almost each and every piece 
of software included in the LFS book. If a system can successfully compile 
and run those environments and desktops, then it's pretty darn stable.





These Days

    Now a days I get to use my systems. I am pretty much finished with 
tweaking and tuning and recompiling everything. My systems do what I want 
them to do, and unless something serious happens (like I get a new project at 
work or a new computer, or one of my system crashes so bad that even back-ups 
don't work) I won't be rebuilding LFS too soon. I like things the way they 
are and it's nice. At home, I have a network of 6 systems. I have a p150 
w/32MB RAM which is my firewall, and front-end apache and ftp server...a Dell 
Optiplex Piii866w/256 MB RAM which runs as my fileserver and back-end to my 
web and ftp services and also houses my network's /home directories (all 
using /dev/ndb). My GNOME-1.4 workstation is an original Slot-A AMD700 w/512 
MB RAM and an AMD k2-333, which is my wife's WIN98SE box (hey what can I tell 
you?). I have an AMD486 w/16 MB RAM that I am going to build into my new 
firewall/router ONLY box, and return the p150 to service as the front end to 
my net services without running any firewall/router service. I have a p200mmx 
w/160MB of bad RAM which when I get the RAM replaced I will use that as my 
SETI box and also use for my C/C++ coding. Once again all /home directories 
are housed on my fileserver using net block devices (except for the 
firewall.) I am learning how to program better than just being able 
troubleshoot some existing code (which I learned because of LFS). I run samba 
on all my boxes for print services into the fileserver. If you have an i386 
Mobo you want to get rid of, give me a holler.





Suggestions When Building LFS


    A lot of this probably won't make sense until you have read the LFS book. 
I suggest reading the book either before reading this, or coming back to this 
section again after you have read the book. (example: $LFS is an environment 
variable we set while building LFS, it is the non-chrooted directory of our 
chroot)

    Take the time to plan your partitions intelligently. Smart partitioning 
alleviates fragmenting of system files and this improves performance. If I 
have two hard drives I do things similarly, but I make sure my system files 
are always on primary partitions ALWAYS...if the extended partition gets 
messed up, then I don't loose EVERYTHING, and can often recover from the 
failure. If I have multiple drives, I put a swap partition on all of them. I 
always put swap in an extended partition so I have my primary partitions for 
system partitions. This is the partitioning scheme I use:
    /dev/hda1   /       130 MB
    /dev/hda2   /boot       4-12 MB (I assign 1 cylinder, size depends on 
your hard-drive)
    /dev/hda3   /usr        300-1200 MB (depending on space and what I plan 
on doing, this is system software)
    /dev/hda5   <SWAP>      48-256 MB (I usually just assign a default 128MB, 
but if I am short on space, or have more space than I know what to do with I 
adjust)
    /dev/hda6   /usr/local  300-1200 MB (Depending on space and what I plan 
on doing, this is for your user software)
    /dev/hda7   /tmp        100 MB (you want this partitioned for a few 
reasons, so that temp files don't overrun your system
    /dev/hda8   /var        20-500MB (depending on space and how much logging 
and state information you want to store, you definitely want to partition 
this too, to keep runaway logs from taking over your system...it CAN happen, 
I have seen it)
    /dev/hda9   /opt        300-1200 MB (depending on space and what you plan 
on doing, this is for GNOME, KDE, etc and your GUI Software, entirely 
optional as its name implies)
    /dev/hda10  /home       Whatever is left...


    Use CVS... It's perfectly stable, and it's just a book, but CVS does seem 
to be the most stable. Funny that. Really use the nightly CVS snapshot.



    Do it twice. I mean it. Some people think it's a religious thing, but its 
not. If you LFS, and then immediately LFS again, you divorce your system 
further from the distribution you started with, by an extra 2 steps. People 
argue that it's ineffective, arguing that by creating the chrooted 
environment that one has created an environment protected from the initial 
base system. I don't quite buy that, because the software you compile into 
chroot is created using the glibc and other libs resident on that initial 
base system. The second LFS process ensures that your LFS is built by LFS, 
and honestly this is the best way I know how to control a system. By ensuring 
consistency, I know what I am going to have as a result. LFS is the best 
system to build LFS with. I have tested the results and I suggest it. Install 
Distro Linux to /dev/hda9 above, build LFS(1) into /dev/hda10 or any 
non-system partition that is larger than 1000MB. The 2nd time you build LFS, 
you are going to build it into the final system using all your partitions. 
Also, if you partition thusly, use another partition for $LFS/usr/src. This 
will help you reduce the necessary space for $LFS/usr if you need to keep it 
to a minimum. You will still need/want at least 300 MB for $LFS/usr if you 
plan on building a "complete" Linux system. Reduced /usr partitions are 
mostly for specialized Linux systems that won't use many of the common tools 
normally found there.

    Start with RedHat, although its a mess its the easiest to install for our 
purposes. All you need to do when installing RedHat is select Custom System. 
Partition Smartly, and install RedHat into the /dev/hda9 above. Select 
Development when you are selecting packages (don't worry about anything else, 
all you need is already selected (except maybe IRC if you want to chat or get 
help while you are doing this). When you are done installing RedHat, 
immediately recompile gcc and replace it with gcc-2.95.2.1 which is a patched 
gcc-2.95.2 that was made specifically for building against RedHat's faulty 
2.96 compiler, do this even if you have updated RedHat's GCC or have 
installed 7.1 or 7.2. You are now ready to LFS.

    Use the Linux-2.2.19 kernel instead of the 2.4 kernel specified in the 
LFS books. Unless you have a very good reason to use 2.4 (such as netfilter 
which IS a good reason), please don't bother. Hunting for a good 2.4 kernel 
that works with your hardware and just plain works at all is a royal pain in 
the tookas. I consider Linux-2.4 to still be in development regardless of 
what Linus happens to say. Linux-2.2.19 always works, always. It's the most 
stable kernel in existence right now and it IS a very modern kernel. In some 
cases I still use the 2.0.39 kernel. The 2.4 kernel's stability and 
usefulness depends a LOT on your hardware and what you plan on doing, don't 
use it if you don't have to. That means in both places, chapter 6 and chapter 
7.

    Most software you can upgrade, replace or remove with abandon. There are 
three you can't (or really don't want to.) They are your kernel, glibc and 
ncurses, all for much the same reason. These packages include headers and 
libraries that get compiled into almost every piece of software on your 
system. Sometimes these headers get changed enough in a new revision to make 
a drastic difference on how your system is compiled, and you can break 
something. When you replace your kernel, make sure you keep your old kernel 
and lilo entry for an extended period of time, in case you discover something 
wrong with your system running the new kernel. FYI I don't delete old kernels 
at all. Glibc _can_ be replaced, but be very warned, if it doesn't build 
right or if it breaks you are _royally screwed_. Ncurses is another set of 
libraries and headers that much of your software depends on, if it changes 
enough you will break a lot of software that isn't system critical, but will 
prevent you from doing many of your daily chores...again don't do it...You 
have been warned.

    Stay clear away from gcc-3.* its broken, I don't care what anyone else 
has told you or whether you have seen it compile a kernel or not. If you do, 
you'll be sorry you did when you finish your system and find out the system 
is broken here and there and you are trying to figure out why. Use 
gcc-2.95.3-2, it works its nice and its stable.

    Use glibc-2.2.4, although it was meant to fix problems with gcc-3.* it's 
a major improvement over glibc-2.2.3 regardless of gcc selection.

    Download both lukeftp and lynx BEFORE you begin and place them in the 
tarball directory that houses your LFS sources. You'll save time and 
frustration by not having to reboot back into the old system to get this 
stuff.

-- 
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe alfs-discuss' in the subject header of the message



More information about the alfs-discuss mailing list