Custom Distributions

Build a Custom Minimal Linux Distribution from Source, Part II

Petros Koutoupis — Thu, 28 Mar 2019 11:30:00 +0000

Follow along with this step-by-step guide to creating your own distribution.

In an article in the June 2018 issue of LJ, I introduced a basic recipe for building your own minimal Linux-based distribution from source code packages. The guide started with the compilation of a cross-compiler toolchain that ran on your host system. Using that cross-compiler, I explained how to build a generic x86-64 target image, and the Linux Journal Operating System (LJOS) was born.

This guide builds on what you learned from Part I, so if you haven't already, be sure to go through those original steps up to the point where you are about to package the target image for distribution.

Glossary

Here's a quick review the terminology from the first part of this series:

Host: the host signifies the very machine on which you'll be doing the vast majority of work, including cross-compiling and installing the target image.
Target: the target is the final cross-compiled operating system that you'll be building from source packages. You'll build it using the cross-compiler on the host machine.
Cross-Compiler: you'll be building and using a cross-compiler to create the target image on the host machine. A cross-compiler is built to run on a host machine, but it's used to compile for an architecture or microprocessor that isn't compatible with the target machine.

Gathering the Packages

To follow along, you'll need the following:

busybox-1.28.3.tar.bz2 (the same package used in Part I).
clfs-embedded-bootscripts-1.0-pre5.tar.bz2 (the same package used in Part I).
Dropbear-2018.76.tar.bz2.
Iana-etc-2.30.tar.bz2.
netplug-1.2.9.2.tar.bz2.
sysstat-12.1.1.tar.gz.

Note: I ended up rebuilding this distribution with the 4.19.1 Linux kernel. If you want to do the same, be sure to install the development package of the OpenSSL libraries on your host machine or else the build will fail. On distributions like Debian or Ubuntu, this package is named libssl-dev.

Fixing Some Boot-Time Errors

After following along with Part I, you will have noticed that during boot time, a couple errors are generated (Figure 1).

Figure 1. Errors generated during the init process of a system boot.

Go to Full Article

January 2019, #294: The Distributions Issue

Bryan Lunduke — Wed, 02 Jan 2019 15:30:00 +0000

by Bryan Lunduke

Do you remember your first distro?

The first version of Linux I truly used, for any length of time, was back at the end of the 1990s—in Ye Olden Times, when 56k modems, 3.5" floppies and VGA CRT monitors reigned supreme.

Linux itself had been a thing for a number of years by this point—with both SUSE (then known as the gloriously mixed-case and punctuation-filled S.u.S.E.) and Red Hat doing good business supporting it—when I decided to really give this "Free" operating system a try.

Because I'm a nerd. And that's what we do.

I remember the day well. It was cold. It was rainy. And I was taking an extended lunch break from my job at Microsoft (seriously). My days—and, all too often, nights—spent testing Windows NT 5 (before it was renamed Windows 2000) had taken a toll. I had reached peak "burn out".

After a mildly rejuvenating, two-hour long, burger-eating (and venting about our job) session with a co-worker, we made our way to the big-box computer store close to Microsoft's main campus. Once inside, we bee-lined it for the Operating System section (this was back when computer stores had rows upon rows of actual boxes that contained actual physical media, which, in turn, contained actual software).

Several versions of Windows were on display, and, lo and behold, right there next to them, was S.u.S.E. Linux—in a box. I grabbed it immediately. It was heavy. There were several CDs inside along with a manual (which would turn out to be necessary simply to get the system to boot).

Fifteen minutes later, we were back in my office installing Linux on one of my little Dell towers.

That's right. My first full-time Linux machine? A Microsoft, company-issued work computer. This was my way of "sticking it to the man"—and boy did it feel good.

Were there problems with my first foray into Linux? You bet. The sound card didn't work. Getting an X Server running (with any sort of GUI) was a mildly mystifying process. And, heck, just getting the darn thing to boot took the better part of an afternoon. But, even with those challenges, I was in love.

Thus, my 20-year long hobby of "installing every Linux distribution I can get my grubby little hands on" was born—right there on Microsoft's main campus, using funds I earned from my job at Microsoft, on Microsoft-owned hardware, using Microsoft-supplied electricity and company time.

Shh. Don't tell Ballmer.

From that point onward, one of the things about Linux that always has made me smile is the wide variety of distributions out there in the world. There seems to be one custom-made for every man, woman and child on planet Earth.

Go to Full Article

Custom Embedded Linux Distributions

Michael J. Hammel — Thu, 01 Feb 2018 15:55:42 +0000

by Michael J. Hammel

The proliferation of inexpensive IoT boards means the time has come to gain control not only of applications but also the entire software platform. So, how do you build a custom distribution with cross-compiled applications targeted for a specific purpose? As Michael J. Hammel explains here, it's not as hard as you might think.

Why Go Custom?

In the past, many embedded projects used off-the-shelf distributions and stripped them down to bare essentials for a number of reasons. First, removing unused packages reduced storage requirements. Embedded systems are typically shy of large amounts of storage at boot time, and the storage available, in non-volatile memory, can require copying large amounts of the OS to memory to run. Second, removing unused packages reduced possible attack vectors. There is no sense hanging on to potentially vulnerable packages if you don't need them. Finally, removing unused packages reduced distribution management overhead. Having dependencies between packages means keeping them in sync if any one package requires an update from the upstream distribution. That can be a validation nightmare.

Yet, starting with an existing distribution and removing packages isn't as easy as it sounds. Removing one package might break dependencies held by a variety of other packages, and dependencies can change in the upstream distribution management. Additionally, some packages simply cannot be removed without great pain due to their integrated nature within the boot or runtime process. All of this takes control of the platform outside the project and can lead to unexpected delays in development.

A popular alternative is to build a custom distribution using build tools available from an upstream distribution provider. Both Gentoo and Debian provide options for this type of bottom-up build. The most popular of these is probably the Debian debootstrap utility. It retrieves prebuilt core components and allows users to cherry-pick the packages of interest in building their platforms. But, debootstrap originally was only for x86 platforms. Although there are ARM (and possibly other) options now, debootstrap and Gentoo's catalyst still take dependency management away from the local project.

Some people will argue that letting someone else manage the platform software (like Android) is much easier than doing it yourself. But, those distributions are general-purpose, and when you're sitting on a lightweight, resource-limited IoT device, you may think twice about any any advantage that is taken out of your hands.

Go to Full Article