Tag Archives: Kernel

LFS 6.8 (Part 12): Preparing to Build the LFS System

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.

Preliminary Speak

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.

Most of /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 /dev/pts, /dev/shm, /proc, and /sys.

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).

Creating Directories

At this point, $LFS is pretty sparse, consisting only of the /dev, /source, and /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!

LFS 6.8 (Part 7): Temporary Toolchain First Pass and Adjustments

The LFS temporary toolchain is going to take a while to cover completely, so I’m breaking it up into several parts for readability.

Binutils (Pass 1)

Binutils contains some of the closest “to the metal” utilities that Linux needs, providing low-level translation of programmer intent into machine-readable binary code. Binutils gets built first as GCC and Glibc will need these lower-level utilities in order to function properly themselves.

This first pass of Binutils is a cross-compile, making it refer specifically to the hardware it is being built on, rather than to the hardware the current build environment (I’m using the LFS live CD) was built for. Binutils is installed to the /tools directory (in the temporary toolchain, /mnt/lfs/tools) because right now / (root) refers to the live CD environment.

I put the configure and make commands for Binutils into a time{} container to measure an SBU (Standard Build Unit) so I could then reliably guess build times for other packages. It turns out an SBU on Pressie is 49 minutes and 8 seconds.

GCC (Pass 1)

GCC is the GNU Compiler Collection, and it is the main utility on a Linux box for compiling programs written in C and C++ (and a host of others that are irrelevant to LFS for now).

The first pass of GCC is also a cross-compile. It requires GMP, MPFR, and MPC, so I extracted their sources into GCC’s source directory so they could be used during the build process. GCC is installed to /tools (/mnt/lfs/tools in the temporary toolchain). Only the C compiler is required for now, so that’s all I built.

I expected GCC to build in 4 hours and 5 minutes, but in reality it took 4 hours and 44 minutes.

As a final touch, I fake out the soon-to-be-built Glibc by symlinking libgcc.a to libgcc_eh.a, since apparently libgcc.a has all the things Glibc wants from libgcc_eh.a. Ours not to reason why….

Linux API Headers

Now this part took me a short while to figure out: to compile the Linux API headers I had to extract the entire Linux kernel source, but only compile the headers with some special commands.

The Linux API headers expose the Linux API to Glibc when I build Glibc; that way, Glibc knows what the kernel can and can’t do, and it compiles accordingly. The headers are installed to /tools/include (/mnt/lfs/tools/include for in the temporary toolchain)

It actually took longer to extract the sources than to build this one: Pressie shattered through the predicted build time of 5 minutes and build in only 3 minutes.

Glibc (not EGlibc)

Glibc is the main C library. Basically, it is a standardized collection of basic functionality for the C language (like memory allocation, file reading, etc.).

I needed to apply a patch to Glibc that fixes a bug preventing it from compiling with the version of GCC I built earlier. I made Glibc a dedicated build directory, as recommended, and then ran a command to compile it as compatible for i486 (i386 is no longer supported by Glibc). I’m not sure why Glibc’s authors didn’t make it i486 by default, but I’m sure it made sense at the time.

Glibc is also cross-compiled, using the first pass builds of Binutils and GCC to configure itself according to the capabilities of Pressie’s hardware. After adjusting the toolchain settings, I will compile Binutils and GCC against the new and Pressie-specific Glibc, so they will be free of any polluting influences of the live CD environment. Glibc is installed to /tools (/mnt/lfs/tools in the temporary toolchain) as well.

A predicted 5 hours and 38 minutes was really 6 hours and 7 minutes.

Adjusting the Toolchain

With the temporary C libraries in place, it is time to adjust things to point toward these new libraries instead of the libraries provided by the live CD environment. I ran a sed script that removed all references in GCC’s specs file to /lib (libraries on the live CD) and pointed them instead to /tools (temporary toolchain libraries on the hard drive).

Finally, I ran a sanity check like the book recommended, and everything worked perfectly! Next I will compile the second passes of Binutils and GCC, together with twenty-odd smaller packages that I’ll need for the rest of the temporary toolchain.

Installing Crunchbang 10 Statler r20110105 on Piggybacker

Crunchbang Statler on Piggybacker

Crunchbang Statler on Piggybacker

Well, as much as I’ve been loving Crunchbang 9.04.01 on Piggybacker, I’ve been hankering to work with a Debian-based distro for a while. (I plan to migrate Limited Edition over to Aptosid, or maybe vanilla Debian + KDE4 with Sid repositories, and I want to have at least some practice with Debian before then.) So, upon hearing of a new release of Crunchbang Statler that was at a pretty usable point, I downloaded the ISO and got to installing it.

Statler’s install screens are pretty self-explanatory, and the install process took about half an hour, which is pretty good time considering that everything is written to a crotchety and uber-slow CF card. The only real bump in the install process was when I forgot to explicitly tell Crunchbang to use my swap partition, so it of course didn’t use it (apparently I’m already too used to automation!). I took the easy way out and just reinstalled rather than fiddling with /etc/fstab.

After booting into my new Statler install (with a working swap partition this time 😛 ), a startup script popped up to help with the inevitable post-install customizations. Among other things, it allows you to enhance your default install with OpenOffice.org, Java runtime libraries, the Liquorix/Zen kernel (a more bleeding-edge and potentially better kernel, but I’ve not noticed a difference), XFCE side-by-side with Openbox, printer support, and development tools. It is a really nice touch that I would absolutely love to see in other distributions (especially the option to install OpenOffice.org).

I immediately took to Statler’s default theme, mostly because it is much easier to read in bright conditions (like near a window) than the 9.04.01 theme. The scrollbars are way harder to see, but that’s why we have keyboard shorcuts, right? Also, I’m not really a fan of Chrome, so I installed Iceweasel (a.k.a. Firefox).

I only had minor annoyances with the install, like having to manually alter some shortcuts and having some applications (including Firefox) not showing up in the main menu, but the Alt-F2 shortcut is keeping me happy in the meantime. Overall, Statler seems much more polished and visually appealing than 9.04.01, and it has proven very stable and workable as my mobile workstation.

Alternative To The “200 Lines Kernel Patch That Does Wonders” Which You Can Use Right Away: It Worked For Me!

This article is absolutely priceless! Ever since I first heard about the 200-ish line kernel patch that improves Linux desktop interactivity by, oh, an order of magnitude or better, I’ve been champing at the bit for K/Ubuntu to update their  kernels with the patch… but apparently the patch was predated by some bash-y proof-of-concept magic. Apparently, a few tweaks in your configuration files can do the same thing as this amazing patch for those people who don’t immediately custom-roll a kernel when cool patches go out (read, “most people”). I was even more excited to see that there was even a Ubuntu-tailored version that is a little more involved thanks to Ubuntu-y quirks, but my desktop experience has gone from a “meh, it’s okay” to a “whoa!”

The smoothness (no more lag!) and snappiness of my desktop is absolutely stunning — things that before I just took for granted as slow (like HD video when I do anything else in the background, file operations, that pause before menu and notifications are actually drawn) are now practically realtime. Applications themselves take just as long to load, but now everything doesn’t… take… forever… to… finally stop lagging so I can get to work. I would definitely recommend at least trying this out (of course, after a thorough backup — just in case)

Kernel developers +1!