Chapter 5 Constructing a Temporary System

Rebooting the VM

Whenever you reboot a LiveCD it forgets about any changes you made to the running system, such is the nature of LiveCD's. Chapters two and four have you perform several changes to the host operating system. Since these changes do not persist between reboots, you will have to repeat them each time the system boots. Below is "script" you can copy and paste to return you to a working state. It essentially repeats the necessary steps laid out in chapters two and four.

You only need to run this script if you rebooted or shut down your VM. If you used "Save the machine state," you do not need to run this script.

export LFS=/mnt/lfs
mkdir -v /mnt/lfs
mount -v -t ext4 /dev/sda1 $LFS
mount -v -t ext4 /dev/sda2 $LFS/home
mount -v -t ext4 /dev/sdb1 $LFS/sources
if ! grep -q sda3 /proc/swaps; then /sbin/swapon -v /dev/sda3; fi
groupadd lfs
useradd -s /bin/bash -g lfs -m -b $LFS/home -k /dev/null lfs
ln -sv $LFS/tools /tools
su - lfs

Uncompressing The Packages

Before starting chapter five you need to uncompress all of the packages you downloaded in the chapter three notes. Before starting be sure your terminal is using the lfs user. If you do this as root you will quickly run into significant problems.

cd $LFS/sources
for i in *.gz *.bz2 *.xz ; do echo "Unarchiving: $i"; tar xf $i ; done

Building Advice

An unwritten direction is that each build should be executed inside that item's source directory. Start every section inside that package's directory! For example, the directions for section 5.17 Bzip2 should be done inside of the $LFS/sources/bzip2-1.0.6 directory. Some directions will have you create a special build directory. None the less, you should still start the section inside the package's source directory. The book will then have you use paths relative to that source directory. Towards the end of the chapter when the build times get short, it is easy to mess this up and build the same package over again, but think you built the next one. Be careful!

In this chapter be sure to skip the tests & checks. They are not necessary to for this chapter and can be quite time consuming.

Combining Directions

Many of the programs, starting in section 5.14, contain a variation on the ./configure → make → make install system. Doing each stage separately can be a problematic. It is easy to think you issued make install when in fact you are on the make stage. To help solve this you can combine directions into a single command by separating the parts of the command with the && operator. This operator acts as a short-circuiting logical and. Therefore, each command in the chain is only executed if all the preceding commands executed successfully. For example, you could build Sed (and many other packages) like this:

./configure --prefix=/tools && make && make install

Before doing GCC and BinUtils Second Pass

You need to delete the build directories that you used previously. You also need to delete the directory that was created when we uncompressed the tar-ball. You then need to uncompress the two files again. Failure to do this will result in Chapter Six failing mysteriously, and you will have to repeat a lot of work. Not doing this creates a subtle error that cannot be detected until you are well into Chapter Six. To fix this problem you will have to repeat all of chapter five. Consider yourself warned!!!

Section 5.7

Before starting this section, you need to get rid of the gcc directories to free up enough space for the glibc package to compile.

rm -rf $LFS/sources/gcc*/

Section 5.9

Before starting the this section run these two commands. This will give you a brand-new source directory.

cd $LFS/sources
rm -rf binutils*/
tar xjf binutils*.tar.bz2

Section 5.10

Before starting the this section run these two commands. This will give you a brand-new source directory.

cd $LFS/sources
rm -rf {gcc,binutils,glibc}*/
tar xjf gcc*.tar.bz2

After completing this section run this command. It will scavenge 2GB disk space. Remember the virtual hard disk only has 4GB of space, so the savings are enormous.

cd $LFS/sources && rm -rf {gcc,binutils,glibc}*/

Timing

Keeping track of how long things are taking is highly advised. It is very important that you time the first build very precisely. All the other timings are given as a relative measurement to this build's time. This measurement is called a SBU. Below is a group of commands that you need to copy and paste that will notify you of the total time taken for section 5.4 of the book. This script should be done instead of following the directions inside of section 5.4.

cd $LFS/sources/binutils*/
time {
mkdir -v ../binutils-build &&
sed -i -e 's/@colophon/@@colophon/' \
       -e 's/doc@cygnus.com/doc@@cygnus.com/' bfd/doc/bfd.texinfo &&
cd ../binutils-build &&
../binutils*/configure \
    --prefix=/tools \
    --with-sysroot=$LFS \
    --with-lib-path=/tools/lib \
    --target=$LFS_TGT  \
    --disable-nls --disable-werror &&
make &&
make install
}

The time command outputs three times, but you only really care about the first. This is the actual amount of time taken to perform all the commands within the braces. The commands above gave me the following output. We only care about the real timing, the others do not matter.

time { ... }
real    2m2.590s
user    1m14.593s
sys     0m10.973s

The real timing is your SBU! Given this SBU we can calculate how much time you will need to finish chapter five. I went through the chapter and totaled the listed SBU's and came up with 27.40 SBU's. So on my computer it will take approximately 55 minutes, i.e. (2 * 27.40).

Taking Snapshots

One of the major benefits of using a virtual machine to compile LFS is that you can take snapshots. Snapshots allow you to take a picture of the virtual machine. This picture includes the current state of the hard drive and if the machine is running it also records what is in RAM. You can then later revert the virtual machine to this state.

I highly recommend that you take frequent snapshots of your virtual machine. The directions in the book are extremely detailed and easy to mess up. Everyone makes mistakes during this process (I have had to start over five times so far). Snapshots allow you to revert the machine to a good state before the mistake happened.

If you do not take snapshots you may have to start all over at some point. Snapshot will help you minimize any wasted effort.

I recommend that you take a snapshot before starting each chapter. Also, take one after the first and second pass of GCC because it takes the longest to compile.