Just like I broke up building the LFS toolchain into several parts, I will break up building the LFS system.
Right now I have my temporary toolchain, but to start building the LFS system, I need to make a few changes to get it ready. If I break something major, I will have to start from here with the known-good backup of my temporary toolchain (which I just made). As it is, I’m ecstatic that I’ve made it this far with no troubles.
The LFS book recommends that first-time LFS builders (like me!) should build without optimizations, since those speed gains can come with problems in compilation and bugs in the “optimized” software. Will I go back and try optimization later? Possibly, but not very likely unless I’m testing on a faster system (it took me 30 hours to get this far, so I’m feeling conservative).
The book also emphasizes that I should build all the packages in order, so “no program accidentally acquires a path referring to
/tools hard-wired into it.”
Virtual Kernel File Systems
The kernel uses several virtual (RAM-hosted) filesystems, but they are mounted as though they are actually on disk; therefore, I need to create their host directories.
The kernel also requires a few virtual device nodes (those things I mostly don’t understand that crowd
/dev) in order to boot at all, so I need to create a few manually.
/dev, though, isn’t populated for the LFS system that I will chroot into. Since
/dev is normally filled during boot, and the LFS chroot has never booted, I have no valid system information yet, and if I tried to build anything, the software would be baffled by the complete lack of hardware. I got around this by using a bind mount (a mount that mirrors an existing mount point or directory) of my build environment’s (the LFS live CD)
/dev. This even allows me to add/remove hardware on the fly, since the changes in
/dev will be mirrored to the chrooted LFS build environment.
Finally, I mount a few more virtual kernel file systems that are empty, but that the kernel will need later, including
Package Management Speak
LFS doesn’t include any package management scheme, as the goal of LFS is to teach about Linux’s inner workings. The LFS book does discuss various solutions for package management, along with their strengths and weaknesses, but leaves their implementation up to the user.
Almost as a side note, the LFS book mentions that LFS can be handy for use on multiple computers with similar hardware, and can be deployed with only a little modification. I don’t really know why anyone would do this in the real world; I’d rather use a Linux system with package management of some sort.
Entering the Chroot Environment
So with the temporary toolchain ready and the virtual kernel file systems mounted and mirrored, I am ready to chroot into the
$LFS directory and start building the final LFS system!
The actual chroot command is pretty long, but is fairly self-explanatory. The new chroot environment is quite similar to the live CD environment, except that it is tuned to make building with the temporary toolchain more painless (so the system uses the newly built software right away automatically).
At this point,
$LFS is pretty sparse, consisting only of the
/tools directories (if memory serves). I needed a full directory tree, so I created one with the dozen-odd commands in the LFS book.
Ah, that’s better.
Creating Essential Files and Symlinks
A few final tweaks configure the LFS chroot environment to be ready to build! After adding a few symlinks, directories, and files, I started a new shell (thus fixing the
I have no name! in the prompt) and created some log files.
Time to build LFS!