Head First into Linux with LFS

9 05 2013

Is it possible for a total Linux newbie to start the journey with LFS?

The answer, from our own experience is, yes!

But not recommended. You’ll feel frustrated, angry and downright stupid.

I had worked with Ubuntu for around an year, but had never delved into bash other than for the occasional make install. My friend, on the other hand, had never worked on Linux!

Yet we made it through! It took around a month, with more time spent on learning than implementing, and it would have been much more faster if not for two very ancient computers!

Still want to delve in? Here are some hints to make it significantly less painful!

1. Choose a well-supported host 

We used Debian without much ado, but Ubuntu and Slackware seem pretty good choices too. What really matters is that the chosen distribution has firm user and developer support, so when you run into a problem, it won’t be too hard finding a solution!

The critical question would be whether to use a virtual machine (vm) or dual boot? While dual booting does give a lot more learning opportunity, using a VM will take you quickly through the early part of the learning curve without getting frustrated right at the start!

2. Learn some basic Linux and how to use the terminal

Well, this one is quite obvious. Our recommended starting point is Linux.org but it is critical to follow up with IBM’s tutorials which are pretty more concise. You need not understand everything at first go.

Familiarize yourself with basic stuff like some simple compilations and installations via the terminal, move around a few files, create some small scripts… Just get used to come out of your Windows frame of mind!

3.  Read the first chapters before you get started

Read at least upto the end of Part 2. You may not understand, but what is important is to get a basic understanding. Down the way, you’ll learn a whole bunch of new concepts way out of the scope of the LFS book.

4. Ask, ask and ask

LinuxQuestions.org has a dedicated LFS forum, and there are also the LFS mailing lists and IRC channels. Just don’t be ready to ask some any question, however dumb it may sound!

5.  Do some automation

There IS an automated LFS version, but then there would be no point learning LFS, right? Well, perhaps you can make the process easier plus learn at the same time by doing some automation. A good start is the package installation in Chapter 5. Write some simple bash scripts and let them run while you do some other work! Just thinking how to implement it will make you a much better programmer!

6. Backup

Simple copies to clones of VMs, backups help make life easier!

7. Learning over Implementation

Use Linux From Scratch as a learning experience! Don’t worry if it takes more time than you expected. What matters is that you gained a lot of knowledge in the process!

Do you have any more handy hints? We’d love to hear from you!


Victory : Rebooting into LFS

7 05 2013


We were all done with our Linux From Scratch system!

It was time for reboot.

On a side note, if you are building on a VM, it wouldn’t be a bad idea to make a clone. It makes things easier, specially if you are an error-prone newbie! Trust us!

After precautionary following all those minute final steps, we typed the shutdown -r now command and crossed our fingers in anticipation.

And imagine our excitement when the screen popped up, quite colourful really!

And the anti-climax when we realized that try as we could, but we couldn’t remember the root password (and the benefits of the clone!)

But truly, LFS is a great experience! It thought us lots and lots of new stuff and a sense of pride to boot up to a system we ourselves compiled!


Of Udev, Bootscripts, Kernels and GRUB

29 04 2013

Chapter 7 and 8 give a very comprehensive overview of exactly how the internals of the Linux system works and how to deal with .  However, if you are a total newbie, like we were, it may be a bit of a heavy load and can benefit greatly from some additional reading.

Before getting started with boot scripts, we need to understand some fundamentals behind Linux device handling.

Lets start with the basics. One of the catchphrases that stuck to my head when learning Linux fundamentals was that everything is a file in Linux! The /dev folder contains files that keep track of all the devices of the system.

So where does udev come in? udev is the device manger for the kernel and basically manages all the device nodes in /dev.

sysfs and devtmpfs

The book is somewhat ambiguous of what exactly happens between sysfs and devtmpfs. It simply says

Drivers that have been compiled into the kernel directly register their objects with a sysfs (devtmpfs internally) as they are detected by the kernel.

What does this exactly mean? As total newbies to the world of drivers, we decided to look around for what actually happened. Accordingly, when a driver registers with sysfs, a device node is automatically created simultaneously in devtmpfs.

Note : Linux Device Drivers is a good comprehensive read for anyone interested in delving deeper into the what-why and how of Linux drivers.


The next step was to install the LFS bootscipts. The LFS system contains its own bootscripts, given in the Appendix. Though not essential, just going through the bootscripts is immensely beneficial. After all, LFS is not about building a Linux system, its all about learning how it works.

The rest of Chapter 7 is very straightforward in terms of implementation, but critical to take a thorough look to fully understand the system. Once done with all the sundry details, we were finally read to move on to Chapter 9.

Compiling the Kernel

It was time for the last compilation in the book! LFS 7.3 is based upon the Linux 3.8.1 kernel. There are basically three steps : configuration, compilation and installation. Configuration is driven by a menu-based interface. The rule of thumb here is, when in any doubt, just go with the default options!

Compilation and installation took quite some time but finally it was done!

GRUB and the Boot Process

In accord with our partition division, we installed GRUB in the LFS partition. Not the best approach, but certainly not a bad newbie approach. The most important thing to note is that GRUB has its own naming conventions and its important to heed them when setting the root in the grub configuration file.

GRUB Naming Conventions  

GRUB names each partition using a pair of values (hdn, m). The n here is the hard disk number while m is the partition number.  (0<=n)

So how does this work?

Consider a partition on hda with the partition number 1. Then, the naming would be as (hd0,1)

Now consider a partition numbered 3 on sdb. This would be naed as (hd1, 3)

That problem cleared,  it was time for THE END!

Pre-Bootscript : Configuring the Network Interface

24 04 2013

Finally, after some torturous days compiling packages, it was finally time to move on!

Chapter 7 deals with bootscripts. However there are a few configurations to do before getting started with that interesting task.

First came setting up the configuring the network interface.

Configuring the network cards : ifconfig

This is a pretty straightforward process, but we learnt an important fact that we’d hereto ignored cloning changes the HW addresses resulting in a very messy process. Having cloned our VMs several times so we could work from home, we found ourselves in a pretty stick situation, specially because one clone had been done after creating the 70-persistent-net.rules file. This resulted in the Debian output and .rules file showing two different network cards.  Though this was remedied by editing the .rules file, we highly recommend not to clone your VM if you are a LFS newbie!

After the .rules file issue was resolved, the next step was to configure the ifconfig file. Here, the following command is pretty handy in finding the variables needed for the ifconfig file.
route -n | egrep "Gateway|UG"

DNS Resolution

Having trouble figuring out your domain name and nameserver? You can check the file on the host system and set the nameservers accordingly.
cat /etc/resolv.conf

The final step was to configure the /etc/hosts file. Here also, just refer to the host system if in doubt.
Then over to bootscrips!

Tortured by torture

22 04 2013

After completing the build of the temporary system we had to now move on to installing basic system software. For this we needed to chroot into the temporary mini Linux system, make a few final preparations, and then begin installing the packages.

This installation is pretty much straightforward however there are a few important things to keep in mind. The order of installing the packages should be strictly followed and it is not recommended to compile separate packages in parallel.

To begin with we had to prepare virtual kernel file systems. For this we had to first create initial device nodes, then mount and populate the dev directory and finally mount the virtual kernel file systems. 

Next up was starting to build and install the final LFS system. For this a few commands had to be run as the root. From this point on, there is no need to use the LFS variable anymore, because all work will be restricted to the LFS file system. This is because the Bash shell is told that $LFS is now the root (/) directory.

In order to create some structure in the LFS system it was necessary to create a standard directory tree and some essential files and symlinks. After that it was basically installing some API headers, man-pages and then the package containing the main C library. Once this was done we had to adjust the toolchain so that it will link any newly compiled program against these new libraries.

Then came the hard part where we required a ton of patience sitting and waiting till each of the 51 packages were installed successfully. Some happened really fast as their approximate build time was rather low but special note must be made on the GCC 4.7.2. package which took eons to install and as the name itself explained we were really tortured by the torture test especially having to work on a single core machine.

Because of this time-killing process we thought of cloning the VM and running it on our personal laptops at home over the weekend so that we can keep it running on the night and also because it was dual core and hoped it would be faster. But to our dismay even after doing that we had issues in cloning the completed one and running it back on the office machine. This was a pretty frustrating and we were really down as we had no other option but to stay until it installed at snail pace. 

Luckily for us with the help of our training engineer we managed to get a dual core machine and after that installation was a piece of cake.

Thank God for that savior machine we have completed chapter 6 and we are now ready to set up the system boot scripts.

Linking the Toolchain

15 04 2013

The bare bones of the system, a tool chain is composed of the assembler, linker, compiler and libraries required to build the O/S and other programs.

Chapter 5 describes this process and is pretty straightforward. Its just a combination of configure, make and make install. And patience.

Remember # 1 : Always build the packages in the following order

1. Start in the $LFS/sources directory

2. Extract the .tar file

Don’t forget the extensions

tar -xvf file.tar
tar -xzvf file.tar.gz
tar -xJf file.xz
tar -xjvf file.tar.bz2

3. Change to the directory to which the package was extracted.

4. Follow the book’s instructions for building the package.

This is usually a combination of configure, make and make install

5. Change back to the sources directory

6. Delete the extracted source directory and any <package>-build directories that were created
in the build process.

Remember # 2 : Experiment with Parallel Makes

Parallel Makes : To do or not to do?

Quite an enlightening discussion sprang up over on LinuxQuestions. Now, we were using ancient Pentium HT 4 CPUs with single cores, but we just wanted to experiment a bit. The results were quite interesting.

Finishing up, all left was to strip the installed packages of their documentations and change the ownership to root.

Preparing for the Build

10 04 2013

The LFS system required a substantial amount of groundwork as outlined in Chapter 4 in the book. .

Partitioning the Disk

When installing the host system, we had already created a free disk space, which made the whole process much less complicated. Alternatively, you could use a program like GParted to resize and create free disk space.

Being first time LFS users, we decided to stick to the very basics and used fdisk to create the root partition taking up the entire free disk space of 11.83 GB.

The host system already had a swap partition and as recommended by the book, we decided to use it and not create a separate swap for the LFS system.

Here’s how the partition table looked before partitioning:

After partitioning:

As you can see, the LFS partition is sda3 and the common swap partition is sda5. 

(An easy way to check the size of a block is to echo “BLOCKS/(2^30)”)

Creating file systems and mounting

Unlike Windows. which just has two basic file systems, Linux has an array of choices. Today, you can see the ext2, ext3 and ext4. as well as vfat (fat32 in Windows) and XFS. We decided to stick to ext3, which while also being used in the boot, provides all features of ext2 as well as journaling capability.

Journaling is a very useful feature that enables faster recovery after system crash. ext3 also had the added advantage of being supported by a greater array of recovery tools than its successor, ext4.

After creating the ext3 file system with mke2fs -jv /dev/sda3 , it was time to mount the partition to the host system. We went with the book’s recommended mount point of /mnt/lfs .

Next up was creating the environment variable $LFS. This variable is used to refer to the mount point instead of using the longer, error-prone /lfs/mnt.

export LFS=/mnt/lfs

mkdir -pv $LFS

mount -v -t ext3 /dev/sda3 $LFS

An important point we missed here, that gave us a big headache later on, is the fact that setting the environment variable and mounting it to the host system should be done upon every restart of the terminal. If not, it won’t show the directories within the LFS partition.


Creating the /sources and /tools directories

The LFS system requires a basic set of required packages that are essential for any  basic Linux system. The book also specifies a number of patches to be used to correct any mistakes in the original packages as well as making them easier to work with.

First on was creating a directory on the LFS partition to store these required packages as well as provide a working environment to unpack the tarballs that contain the packages and build them. The $LFS/sources directory was created for this purpose.

The book’s website provides a wget-list that makes it much easier to download all the required patches and packages on one go using wget -i <location of wget-list file> -P $LFS/sources.

md5sums, also available on the book’s website can be used to check whether all the required packages and their specific versions are present.

The other directory created was $LFS/tools. This is used to store all programs compiled when building the temporary tools upon which the final LFS system is built.


Setting up the Environment

There were some final tweaks to be done before getting our hands dirty with the LFS system.

Due to the attached power and risk of the root user, a separate unprivileged lfs user is created to minimize the risk of a mistake crashing the whole system.

The final step was to modify the login and non-login user profiles. The reasoning behind this modification is to ensures that the new LFS system contains no hazardous environment variables from the host system and to make the shell pick up the newly installed tools instead of versions of the same tool available in the host system..

The login shell is run as part of the user’s login to the system and is generally used to do any user configurations to establish the work-environment. It reads the host’s /etc/profile and .bash_profile files.

A non-login shell refers to:any other shell either run by the user after logging on or which is run by an automated process. This shell reads the .bashrc file.


Now it is time to start building the system.