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. 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 have hunt down 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.linuxfromscratch.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 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. Know what your system settings need to be before you begin, especially settings for routing and eth0 or ttyS0 or whatever. This will save frustration. If you need to refer to your Base System's settings, then go for it. Keep Notes. If you build LFS following the book to the letter, then the book is your notebook. If you diverge even a tinsy bit, write it down and keep it handy. Keep notes on how you install all software, you will need it if you need to remove something or need to remember where you installed it, because some other package doesn't seem to find it on its own. Don't loose your notes...This is important. You could end up installing a library in two locations by accident and that can cause all kinds of hell in the future. The first thing you should install after LFS is GPM, including before you start LFSing the second time...trust me...read the hint to get it compiled otherwise you won't get it compiled. Hints are found at http://hints.Linuxfromscratch.org go there, download them all and read them...read GPM first. Learn to like the console...it has much better, more stable software than X. I use X sometimes when I really want graphics support, but console really is better for functionality, it uses less resources and the software almost always much faster ... 9 out of 10 Linux gurus agree. Ok that's more generally Linux oriented and not LFS oriented, so I will stop there. Pros and Cons Here is the part you Linux advocacy die-hards should appreciate. You should notice the similarity between what is said here, and what is said in the MS vs. Linux war. PROS The very first and foremost pro for using LFS is Education. Flat out, this beats any other advantage that LFS has to offer. By the time you have learned how to compile your own Linux system using only the book for tips and hints, you have become a system developer and not just user...Don't get me wrong, you'll still have lots to learn about system administration and other stuff before you are a guru, but you are more guru now than ever before. You will learn how to modify and maintain source code. You will learn how your computer works, and right down to low level CPU functions if you go the hard core optimization route. Stability. This is the second most important reason for building LFS. When you take the time to regression test your system and fix any minor bugs that do occur occasionally, you'll have arguably the most stable system you could find. In essence this is by the way, what distribution developers do. In their own fashion they build their own specific LFS and test rebuild test patch rebuild and test and package. Performance. LFS is native. That means it was built on the system it is running on. If you allow gcc to discover the sort of system hardware and software you are using, you'll have a pretty good optimized system that by default will outperform any distribution on the market, guaranteed. There is a reason for this. Distributions need to build Linux systems for the widest set of platforms. Within an architecture family, this means compiling their distribution for the lowest common denominator (i.e. the Intel 80386 in the case of the Intel family and its compatibles). The exception being Mandrake, which targets the Pentium Classic as the lowest platform. Essentially this makes your Athlon1.2 GHz computer a 1.2 GHz 80386. None of the advantages are the newer architectures are used, because they can't be if the software must also run on an i386. So you gain a great deal of performance, up to 30% for just the default compile time options in some cases. Lean-ness. LFS will be very small compared to similar installations from Distributions. You can strip RedHat down to the very same files that you would find on a finished LFS system. RedHat would still be a much larger installation. This is due in part to the same reasons why you see a gain in performance with LFS. As well, instead of having to hunt down files that aren't going to be used, you instead are faced with the joy of only installing that which you absolutely want or need. I have a fully featured GNOME workstation loaded with software. The installation is big, but it's much smaller than a RedHat GNOME workstation, having only the components I use. It also is very stable and doesn't crash. I have only installed software as needed and so I know there is nothing superficial or superfluous about my software. Customizability. This could really be put anywhere in the ranking of pros. It might be your first priority or your last. This is also very easily the most used argument for why people might select Linux over MS Windows, and it also the most used argument for building LFS. You can do anything you want with LFS. You can put together a fat desktop and multimedia workstation with GNOME, KDE and GNUStep. Configure it to automatically boot into runlevel 5. Use xmms to play your favorite music and watch your favorite DVD movie with mplayer. If you don't like using /usr/local in the traditional manner and want to install all user software in /usr/local/PACKAGENAME go for it. Your PATH and ld.so.conf will be huge, but hey it can make software removal a breeze (rm -rf /usr/local/PACKAGENAME). Alternatively, you could fashion a DOS-like filesystem structure if you really want. Yes you could customize RedHat to that extent, but go ahead and try...Its a much bigger head-ache than customizing LFS. Here's the kicker and paradox argument for anti-LFSers, I'll be done long before you. LFS just lends itself to customization since its very basis is being compiled entirely from sources. Compartmentalization. This is really a combination of the last two above. With the lean-ness and customizability inherent in LFS, LFS is well suited for singular tasks that are best suited for older hardware freeing up newer hardware for hard-core tasks. Everyone knows about using an i[3,4,5]86 as a firewall, but how about using an i586 for a firewall and moving dhcp, WINS resolution and DNS and your other seldom used services to an i486. The i486 would perform very well, and perhaps better than your heavily hit i586 firewall running the additional services. You can leave the firewall alone to do its job as a router/NAT/firewall and so it performs better too. Ok, I am getting into that general Linux territory again. Stop. Experimenting. You can play all you want, and if you break something you probably now have the wherewithal to figure out what you broke. Understandability. When you are finished building your complete Linux system with all the junk you could want on it and tweaked it to the brim, I want you to compare your system with a RedHat or Debian or any other distribution system. Look at /etc ... geez what the heck is all that crap? Compare your ~/.bash_profile ~/.bashrc and ~/.bash_logout with RedHat's ... See any difference? A huge one I will wager. Support. LFS builders are some of the MOST knowledgeable Linux users in the world. If you hop onto irc.Linuxfromscratch.org friendly faces, people who are MORE than willing to help out a fellow LFSer will greet you. If they can't help you directly on irc, then you will likely be directed to the mailing lists or the news server (which is a mirror of the lists.) You can also search the mailing list archives to see if someone has already encountered and solved your problem. It's very likely. On a not so rare occasion a fellow LFSer might even try and duplicate the problem on their end to see if they can solve the problem. LFSers are by definition Linux problem solvers. CONS Education. You will be forced to learn how to do this, and it does take some time to become accustomed to this new method of system building. Gone are the days of just sticking in a CD and booting. You will have to make intelligent choices, scrap ideas and start anew when an idea doesn't pan out. Notice this is also listed in PROS. Time. It does take time to develop a system. As you become more familiar with compiling a system completely from scratch, compile time diminishes. Again my first time it took 3 weeks (with legit excuses), and now it takes me 3-4 hours. Before you think of this as too much of a disadvantage, how many times have you sat in front of a Linux installation screen and labored over what to install and how. And how many more times have you spent 4 hours installing Linux only to say to yourself...Oh man I wish I hadn't done that. It's the same deal; with familiarity it doesn't really take much more time to build Linux than it does to install it (of course I AM talking about on faster computers, an i386 can take days to compile LFS where a CD will take maybe 5 hours.) Frustration, Bruising and Headaches. Sometime when you are trying to install some software, you'll have one heck of a time. You'll bang your head on the desk (hence the bruises) and you kill anyone that comes within arms length. This isn't the norm, but it does happen sometimes. Usually it will be due to some earlier installed, and required software not being recognized properly or source code that isn't up to the current state of Unix/Linux. Before you beat yourself silly, just hop onto irc.linuxfromscratch.org. Someone is likely to have run into the same problem, or something like it and can give you a hand, within minutes usually. Proprietary. As much as customization is an advantage, it also becomes a disadvantage. You have no choice but to customize, or work very hard to adhere to a set of standards such as the File Hierarchy Standard, and others. You will never find RPMs for your system or deb files. Occasionally a tgz or tar.gz file will work as packaged. You pretty much are destined to compile everything. Experimenting. You will have to do it. Experimenting is how you get much software to work, but once you do get it to work, it really works. Package Management. Once again...No RPM, No Deb, the occasional tgz file works. There are people who have installed RPM or dpkg and apt-get, and they build their own packages for their own future use, but unless you follow the same standards as the people who made the packages, you can't use them. Most people make them for their own use so they can add and remove less often used software at will. Support. If it doesn't work, you don't have a vendor to blame and fix things for you. It's all on your shoulders. You can get on many irc channels that support developers, such as irc.openprojects.org. The developers of your software can often be found there. Configuration. You have to hand code almost every aspect of your Linux system. Although there are some provided rc scripts and /etc configuration files that can be downloaded from ftp.linuxfromscratch.org, you will probably want to change them to suit your needs...In addition any software you install above and beyond the LFS system will not have pre-made configuration files. You will have to learn how to do that yourself. Man Pages. This is really a PRO but I add it here for a reason. There are no manuals for LFS, no QUE no UNLEASHED or other overview manuals such as those you can get for distributed Linux. Man Pages will become your friends, and application specific manuals (such as O'Reilly's) will become the meat and potatoes of your IT library. In fact you might want to throw out your old Linux manuals, because they ARE vendor specific and won't be much help at all with LFS, they may even confuse you. Summary Linux From Scratch isn't for the faint of heart. It is meant as a launching platform from which you can build systems to do your bidding as you wish it. Go now, young Jedi. And remember, "Use the source" (Someone else gets credit for that quote, but I can't remember which LFSer said that to me) Copyright Nov. 2001 Acknowledgements Gerard Beekmans - Owner, Project Leader, Author and Principle Developer and Principle Tester of "Linux From Scratch Project" and Friend Beverly Beekmans - Mrs. Gerard, gracious supporter of the Linux From Scratch Project Jesse Tie-Ten-Quee (HIghOS) - IRC OP, Developer, Tester and Friend. We miss you Jesse. Jeremy Jones (mca) & roryo - Testers and Co-Authors of Gnome.txt, the GNOME hint (much better than my hint) and Friends, sometimes The list goes on and on, all the way down to minor contributors and just people we like(and some we don't).