Preparation

Source Preparation

First, create a workspace:

$ TOP=$HOME/teeny-linux
$ mkdir -pv $TOP

Our entire system will be composed of exactly two packages: the Linux kernel and Busybox. Download and extract them now:

$ cd $TOP
$ curl https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-5.11.7.tar.xz | tar xJf -
$ curl https://busybox.net/downloads/busybox-1.32.1.tar.bz2 | tar xjf -

Build Environment

Now we’ll create our docker image.

$ mkdir -pv docker
$ cd docker

Then create a Dockerfile at $TOP/docker/Dockerfile with the following content:

FROM debian:10.8-slim

RUN apt-get update
RUN apt-get install -y \
        bc \
        bison \
        build-essential \
        cpio \
        flex \
        libelf-dev \
        libncurses-dev \
        libssl-dev \
        vim-tiny

If you’re building on a Mac M1 you’ll also need to add gcc-x86-64-linux-gnu (which is a cross-compiler) to the package list. (Thanks to commenter Franziska Napelt for pointing this out!)

And build the docker image (add sudo if necessary on your system):

$ docker build . -t teeny-linux-builder

For simplicity we’ll be running as root in the docker container. If you really want to build as a regular user within your container you can always do something like this.

Busybox Userland

The first thing we’ll do is create a minimal userland based on the ever-useful busybox tool. After building busybox, we’ll throw it in a minimal filesystem hierarchy and package it up in an initramfs using cpio.

Let’s go configure busybox now.

First we enter our build container:

$ docker run -ti -v $TOP:/teeny teeny-linux-builder

and prepare the initial busybox configuration:

# cd /teeny/busybox-1.32.1
# mkdir -pv ../obj/busybox-x86
# make O=../obj/busybox-x86 defconfig

If you’re using a cross-compiler (if you’re on a Mac M1, for example), you’ll also need to add ARCH=x86_64 CROSS_COMPILE=/usr/bin/x86_64-linux-gnu- to this and all subsequent make commands below. E.g.:

# make ARCH=x86_64 CROSS_COMPILE=/usr/bin/x86_64-linux-gnu- O=../obj/busybox-x86 defconfig

(Note: in the busybox build system, O= means “place build output here”. This allows you to host multiple different configurations out of the same source tree. The Linux kernel follows a similar convention.)

This gives us a basic starting point. We’re going to take the easy way out here and just statically link busybox in order to avoid fiddling with shared libraries. We’ll need to use busybox’s menuconfig interface to enable static linking:

# make O=../obj/busybox-x86 menuconfig

type /, search for “static”. You’ll see that the option is located at:

-> Settings
[ ] Build static binary (no shared libs)

Go to that location, select it by pressing space, and exit (saving changes).

Now build busybox:

# cd ../obj/busybox-x86
# make -j$(nproc)
# make install

(The -j$(nproc) causes make to execute a concurrent build using the same number of build process as you have processor cores.)

So far so good. With a statically-linked busybox in hand we can build the directory structure for our initramfs:

# mkdir -pv /teeny/initramfs/x86-busybox
# cd /teeny/initramfs/x86-busybox
# mkdir -pv {bin,sbin,etc,proc,sys,usr/{bin,sbin}}
# cp -av /teeny/obj/busybox-x86/_install/* .

Of course, there’s a lot missing from this skeleton hierarachy that will cause a lot of applications to break (no /etc/passwd, for example), but it’s enough to boot to a shell, so we’ll live with it for the sake of brevity. If you want to flesh it out more you can refer to these sections of Linux From Scratch.

One absolutely critical piece of our userland that’s still missing is an init program. We’ll just write a tiny shell script and use it as our init:

# vi /teeny/initramfs/x86-busybox/init

And enter the following:

#!/bin/sh

mount -t proc none /proc
mount -t sysfs none /sys

echo -e "\nBoot took $(cut -d' ' -f1 /proc/uptime) seconds\n"

exec /bin/sh

and make it executable:

# chmod +x /teeny/initramfs/x86-busybox/init

The Gentoo wiki’s Custom Initramfs page is a great reference for building a minimalistic initramfs if you’d like to learn more.

We’re now ready to cpio everything up:

# cd /teeny/initramfs/x86-busybox
# find . -print0 \
    | cpio --null -ov --format=newc \
    | gzip -9 > /teeny/obj/initramfs-busybox-x86.cpio.gz

We now have a minimal userland in $TOP/obj/initramfs-busybox-x86.cpio.gz that we can pass to qemu as an initrd (using the -initrd option). But before we can do that we need a kernel…

Linux Kernel

Basic Kernel Config

For our not-yet-trimmed-down baseline, let’s build a kernel using the default x86_64 configuration that ships with the kernel tree. Apply the configuration like so:

# cd /teeny/linux-5.11.7
# make O=../obj/linux-x86-basic x86_64_defconfig

We can also merge in a few config options that improve performance/functionality of kvm guests with:

# make O=../obj/linux-x86-basic kvm_guest.config

The kernel is now configured and ready to build. Go ahead and build it:

# make O=../obj/linux-x86-basic -j$(nproc)

Your freshly built kernel image is located at $TOP/obj/linux-x86-basic/arch/x86_64/boot/bzImage

Now that we have a kernel and a userland, we’re ready to boot!

Exit your build container:

# exit

Now you can use qemu-system-x86_64 to try out your new system:

$ cd $TOP
$ qemu-system-x86_64 \
    -kernel obj/linux-x86-basic/arch/x86_64/boot/bzImage \
    -initrd obj/initramfs-busybox-x86.cpio.gz \
    -nographic -append "console=ttyS0"

Exit the VM by hitting Ctl-a c then typing “quit” at the qemu monitor shell.

If your host processor and kernel have virtualization extensions you can add the -enable-kvm flag to really speed things up:

$ qemu-system-x86_64 \
    -kernel obj/linux-x86-basic/arch/x86_64/boot/bzImage \
    -initrd obj/initramfs-busybox-x86.cpio.gz \
    -nographic -append "console=ttyS0" -enable-kvm

Smaller Kernel Config

That’s great and all, but if we really just want a tiny system with nothing but busybox on it we can remove a bunch of stuff from our kernel. By trimming down our kernel config we can reduce the size of our kernel image and reduce boot time.

Let’s try using the kernel’s Kbuild defaults as our baseline. The Kbuild defaults are generally quite conservative since Linus Torvalds has declared that in the kernel unless the feature cures cancer, it’s not on by default, as opposed to the x86_64_defconfig which is meant to provide a lot of generally useful features and work on a wide variety of x86 targets.

To get started, re-enter our build container:

$ docker run -ti -v $TOP:/teeny teeny-linux-builder

You can apply this more conservative configuration based on the Kbuild defaults by using the alldefconfig target:

# cd /teeny/linux-5.11.7
# make O=../obj/linux-x86-alldefconfig alldefconfig

We need to enable a few more options in order to actually be able to use this configuration.

First, we need to enable a serial driver so that we can get a serial console. Run your preferred kernel configurator (I like nconfig, but you can use menuconfig, xconfig, etc.):

# make O=../obj/linux-x86-alldefconfig nconfig

Navigate to:

-> Device Drivers
  -> Character devices
    -> Serial drivers

and enable the following options:

[*] 8250/16550 and compatible serial support
[*] Console on 8250/16550 and compatible serial port

We also need to enable initramfs support, so that we can actually boot our userland. Go to:

-> General setup

and select:

[*] Initial RAM filesystem and RAM disk (initramfs/initrd) support

You can also deselect all of the initrd/initramfs decompressors except gzip, since that’s the only one we’re using.

You can now exit, saving changes.

Finally, enable some features for kvm guests (not actually necessary to get the system booting, but hey):

# make O=../obj/linux-x86-alldefconfig kvm_guest.config

Build:

# make O=../obj/linux-x86-alldefconfig -j$(nproc)

And exit the build container:

# exit

We now have a much smaller kernel image:

$ (cd $TOP; du -hs obj/linux-x86-*/vmlinux)
19M     obj/linux-x86-alldefconfig/vmlinux
54M     obj/linux-x86-basic/vmlinux

Now boot the new kernel (with our same userspace):

$ qemu-system-x86_64 \
    -kernel obj/linux-x86-alldefconfig/arch/x86_64/boot/bzImage \
    -initrd obj/initramfs-busybox-x86.cpio.gz \
    -nographic -append "console=ttyS0" -enable-kvm

Not only is it smaller than the last one, but it boots faster too! Here are the results on my system:

Configuration	Boot time (seconds)
`x86_64_defconfig + kvmconfig`	`0.74`
`alldefconfig + custom stuff + kvmconfig`	`0.32`

Smallest Kernel Config

We saw a nearly 3x decrease in kernel image size and cut boot time in half by using a smaller set of default options. But how much smaller and “faster” can we go?

Let’s prune the image down even further by starting with absolutely nothing. The kernel build system has a make target for this: allnoconfig. Let’s create a new configuration based on that.

Enter the build container again:

$ docker run -ti -v $TOP:/teeny teeny-linux-builder

And start an allnoconfig build configuration:

# cd /teeny/linux-5.11.7
# make O=/teeny/obj/linux-x86-allnoconfig allnoconfig

Now everything that can be turned off is turned off. This is as low as it goes without hacking up the kernel source. As one might expect, we have a little more work to do in order to get something that actually boots in qemu. Incredibly, though, there isn’t a ton to do.

Fire up your kernel configurator:

# make O=../obj/linux-x86-allnoconfig nconfig

Here are the options you need to turn on:

[*] 64-bit kernel

-> General setup
  -> Configure standard kernel features
[*] Enable support for printk

-> General setup
[*] Initial RAM filesystem and RAM disk (initramfs/initrd) support

-> Executable file formats
[*] Kernel support for ELF binaries
[*] Kernel support for scripts starting with #!

-> Device Drivers
  -> Character devices
[*] Enable TTY

-> Device Drivers
  -> Character devices
    -> Serial drivers
[*] 8250/16550 and compatible serial support
[*]   Console on 8250/16550 and compatible serial port

-> File systems
  -> Pseudo filesystems
[*] /proc file system support
[*] sysfs file system support

And exit, saving changes.

In order to keep things truly tiny, we’ll skip make kvmconfig. Build it:

# make O=../obj/linux-x86-allnoconfig -j$(nproc)

and exit the build container:

# exit

The resulting image is quite a bit smaller than our last one, and nearly 10x smaller than the one based on x86_64_defconfig:

$ (cd $TOP; du -hs obj/linux-x86-*/vmlinux)
19M     obj/linux-x86-alldefconfig/vmlinux
6.1M    obj/linux-x86-allnoconfig/vmlinux
54M     obj/linux-x86-basic/vmlinux

Adding make kvm_guest.config increases the image size to 9M.

And boot it:

$ qemu-system-x86_64 \
    -kernel obj/linux-x86-allnoconfig/arch/x86_64/boot/bzImage \
    -initrd obj/initramfs-busybox-x86.cpio.gz \
    -nographic -append "console=ttyS0" -enable-kvm

Our new tiniest kernel boots about twice as fast as the alldefconfig one and about 5x as fast as the one based on x86_64_defconfig. Adding kvmconfig didn’t really affect boot time.

Configuration	Boot time (seconds)
`x86_64_defconfig + kvmconfig`	`0.74`
`alldefconfig + custom stuff + kvmconfig`	`0.32`
`allnoconfig + custom stuff`	`0.28`

Conclusion

The most obvious application for this type of work is in the embedded space. However, I could see how it might also be beneficial in elastic cloud computing to reduce boot times and memory footprint. Please leave a comment if you’re aware of anyone doing this in “the cloud”!

If nothing else it’s an interesting exercise! :)

https://mgalgs.io/2021/03/23/how-to-build-a-custom-linux-kernel-for-qemu-using-docker.html