"Containers" became popular a few years ago with the emergence of Docker, but they are actually the result of a long line of evolution starting with chroot, a concept which dates all the way back to 1979. The idea of a container, or a chroot, is to run a process or set of processes in a (more or less) isolated environment that's separate from your main operating system.

The first iteration, chroot, only isolated the filesystem: chroot would "change" the "root" directory (hence the name) to a subdirectory of the main filesystem, then run a program that would see only files in that subdirectory. Among other things, this was used as a way to prevent rogue programs from accidentally damaging other files on the system. But it wasn't particularly safe, especially because any program running with administrator privileges could play tricks and eventually switch its root back to the "real" root directory. Separately from security, though, it's sometimes interesting to install a different operating system variant in a subdirectory, then chroot into it and run programs that require that operating system version. For example, if you're running the latest version of Debian Linux, but you want to build an application that only builds correctly on the Debian version from 5 years ago, you can install the 5-years-ago Debian files in a directory, chroot into that, and build your application. The main limitation is that your "host" system and your chroot environment share the same kernel version, and rogue programs usually can find a way to escape the chroot, so it's not useful if your inner system is running dangerous code.

Partly in response to the limitations of chroot, "virtualization" started to gain popularity around 2001, made famous by VMware. (IBM mainframes had been doing something similar for a few decades, but not many people knew how IBM mainframes worked.) Anyway, virtualization simulates a computer's actual hardware and lets you run a different kernel on the virtual hardware, and a filesystem inside that hardware. This has several advantages, including much stricter security separation and the ability to run a different kernel or even a different "guest" operating system than the one on the host. Virtualization used to be pretty slow, but it's gotten faster and faster over the years, especially with the introduction of "paravirtualization," where we emulate special virtual-only "hardware" that needs special drivers in the guest, in exchange for better performance. On Linux, the easiest type of paravirtualization nowadays is kvm (kernel virtual machine), a variant of QEMU.

Virtual machines provide excellent security isolation, but at the expense of performance, since every VM instance needs to have its own kernel, drivers, init system, terminal emulators, memory management, swap space, and so on. In response to this, various designers decided to go back to the old chroot system and start fixing the isolation limits, one by one. The history from here gets a bit complicated, since there are many, overlapping, new APIs that vary between operating systems and versions. Eventually, this collection of features congealed into what today we call "containers," in products like OpenVZ, LXC, and (most famously) Docker.

Why are we talking about all this? Because in this tutorial, we'll use redo to build and run three kinds of containers (chroot, kvm, and docker), sharing the same app build process between all three. redo's dependency and parallelism management makes it easy to build multiple container types in parallel, share code between different builds, and use different container types (each with different tradeoffs) for different sorts of testing.

You can follow along by checking out the redo source and looking in the docs/cookbook/container/ directory.

A Hello World container

Most Docker tutorials start at the highest level of abstraction: download someone else's container, copy your program into it, and run your program in a container. In the spirit of redo's low-level design, we're going to do the opposite, starting at the very lowest level and building our way up. The lowest level is, of course, Hello World, which we compiled (with redo of course) in an earlier tutorial:

In fact, our earlier version of Hello World is a great example of redo's safe recursion. Instead of producing an app as part of this tutorial, we'll just redo-ifchange ../hello/hello from in our new project, confident that redo will figure out any locking, dependency, consistency, and parallelism issues. (This sort of thing usually doesn't work very well in make, because you might get two parallel sub-instances of make recursing into the ../hello directory simultaneously, stomping on each other.)

For our first "container," we're just going to build a usable chroot environment containing our program (/bin/hello) and the bare minimum requirements of an "operating system": a shell (/bin/sh), an init script (/init, which will just be a symlink to /bin/hello), and, for debugging purposes, the all-purpose busybox program.

Here's a .do script that will build our simple container filesystem:

There's a little surprise here. Did you see it above? In current versions of redo, the semantics of a .do script producing a directory as its output are undefined. That's because the redo authors haven't yet figured out quite what ought to happen when a .do file creates a directory. Or rather, what should happen after you create a directory?

Can people redo-ifchange on a file inside that newly created directory? If so, what if the new directory contains .do files? What if you redo-ifchange one of the sub-files before you redo-ifchange the directory that contains it, so that the sub-file's .do doesn't exist yet? And so on. We don't know. So for now, to stop you from depending on this behaviour, we intentionally made it not work.

Instead of that, you can have a .do script that produces a different directory as a side effect. So above, produces a directory called simple when you run redo simple.fs. simple.fs is the (incidentally empty) target file, which is remembered by redo as a node in the dependency tree, so that other scripts can depend upon it using redo-ifchange simple.fs. The simple directory happens to materialize too, and redo doesn't know anything about it, which means it doesn't try to do anything about it, and you don't have to care what redo's semantics for it might someday be. In other words, maybe someday we'll find a more elegant way to handle .do files that create directories, but we won't break your old code when we do.


All right, one more catch. Operating systems are complicated, and there's one more missing piece. Our Hello World program is dynamically linked, which means it depends on shared libraries elsewhere in the system. You can see exactly which ones by using the ldd command:

$ ldd ../hello/hello (0x00007ffd1ffca000) => /lib/x86_64-linux-gnu/ (0x00007f9ddf8fd000)
    /lib64/ (0x00007f9ddfe9e000)

If we chroot into our simplistic "container" and try to run hello, it won't work, because those libraries aren't available to programs inside the chroot. That's the whole point of chroot, after all!

How do we fix it? We get a list of the libraries with ldd, and then we copy the libraries into place.

Actually, for reasons we'll address below, let's make a copy of the new filesystem and copy the new libraries into that:

So now there's a directory called simple, which contains our program and some helper programs, and one called libs, which contains all that stuff, plus the supporting libraries. That latter one is suitable for use with chroot.

Running a container with unshare and chroot

So let's run it! We can teach redo how to start a program inside any chroot by using a script. In this case, we'll use With that file in place, when we run redo whatever.runlocal (for any value of whatever), redo will first construct the whatever directory (using redo-ifchange whatever.fs), and then chroot into it and run /init inside. We'll collect stdout into the redo output (ie. the file outside the chroot named whatever.runlocal). Also, the stderr will go to redo's build log, readable with redo-log or on the console at build time, and if the /init script returns a nonzero exit code, so will our script. As a result, the whole container execution will act like a single node in our build process. It can depend on other things, and other things can depend on it.

Just one more thing: once upon a time, chroot was only available to sysadmins, not normal users. And it's never a good idea to run your build scripts as root. Luckily, Linux recently got a feature called "user namespaces" (userns), which, among many other things, lets non-administrator users use chroot. This is a really great addition.

(Unfortunately, some people worry that user namespaces might create security holes. From an abundance of caution, many OSes disable user namespaces for non-administrators by default. So most of this script is just detecting those situations so it can give you a useful warning. The useful part of the script is basically just: unshare -r chroot "$2" /init >$3. Alas, the subsequent error handling makes our script look long and complicated.)

Speaking of error handling, the script above calls a script called ./, which is just a helper that prints a helpful error message and aborts right away if the listed programs are not available to run, rather than failing in a more complicated way. We'll use that script more extensively below.

And that's it! A super simple container!

$ redo libs.runlocal
redo  libs.runlocal
redo    libs.fs
redo      simple.fs

$ time redo libs.runlocal
redo  libs.runlocal

real    0m0.112s
user    0m0.060s
sys 0m0.024s

$ du libs
792 libs/bin
156 libs/lib64
1656    libs/lib/x86_64-linux-gnu
1660    libs/lib
3752    libs

$ cat libs.runlocal
Hello, world!

By the way, if this were a docker tutorial, it would still print "Hello, world!" but your container would be >100 megabytes instead of 3.7 megabytes, and it would have taken at least a couple of seconds to start instead of 0.11 seconds. But we'll get to that later. First, now that we have a container, let's do more stuff with it!

Running a container with kvm and initrd

Now you've seen chroot in action, but we can run almost the same container in kvm (kernel virtual machine) instead, with even greater isolation. kvm only runs on Linux, so for this step you'll need a Linux machine. And for our example, we'll just have it run exactly the same kernel you're already using, although kvm has the ability to use whatever kernel you want. (You could even build a kernel as part of your redo project, redo-ifchange it, and then run it with kvm. But we're not going to do that.)

Besides a kernel, kvm needs an "initial ramdisk", which is where it'll get its filesystem. (kvm can't exactly access your normal filesystem, because it's emulating hardware, and there's no such thing as "filesystem hardware." There are tools like the 9p filesystem that make this easier, but it's not available in all kernel builds, so we'll avoid it for now.)

"Initial ramdisk" (initrd) sounds fancy, but it's actually just a tarball (technically, a cpio archive) that the kernel extracts into a ramdisk at boot time. Since we already have the files, making the tarball is easy:

(Ignore that thing for now. We'll get to it a bit further down. In our simple.fs example, it's a no-op anyway.)

The main thing you need to know is that, unlike tar, cpio takes a list of files on stdin instead of on the command line, and it doesn't recurse automatically (so if you give it a directory name, it'll store an entry for that directory, but not its contents, unless you also provide a list of its contents). This gives us a lot of power, which we'll use later. For now we're just doing basically find | cpio -o, which takes all the files and directories and puts them in a cpio archive file.

$ redo libs.initrd
redo  libs.initrd
5163 blocks
1 block

$ cpio -t <libs.initrd
7444 blocks also appends another file, rdinit (the "ram disk init" script), which is the first thing the kvm Linux kernel will execute after booting. We use this script to set up a useful environment for our container's /init script to run in - notably, it has to write its stdout to some virtual hardware device, so redo can capture it, and it has to save its exit code somewhere, so redo knows whether it suceeded or not. Here's a simple rdinit script that should work with any container we want to run using this technique:

Configuring a virtual machine can get a little complicated, and there are a million things we might want to do. One of the most important is setting the size of the ramdisk needed for the initrd. Current Linux versions limit the initrd to half the available RAM in the (virtual) machine, so to be safe, we'll make sure to configure kvm to provide at least 3x as much RAM as the size of the initrd. Here's a simple script to calculate that:

With all those pieces in place, actually executing the kvm is pretty painless. Notice in particular the three serial ports we create: one for the console (stderr), one for the output (stdout), and one for the exit code:

And it works!

$ redo libs.runkvm
redo  libs.runkvm
redo    libs.initrd
5163 blocks
1 block
libs: kvm memory required: 70M
[    0.306682] reboot: Power down

$ time redo libs.runkvm
redo  libs.runkvm
libs: kvm memory required: 70M
[    0.295139] reboot: Power down

real    0m0.887s
user    0m0.748s
sys 0m0.112s

$ cat libs.runkvm
Hello, world!

Virtual machines have come a long way since 1999: we managed to build an initrd, boot kvm, run our program, and shut down in only 0.9 seconds. It could probably go even faster if we used a custom-built kernel with no unnecessary drivers.

A real Docker container

Okay, that was fun, but nobody in real life cares about all these fast, small, efficient isolation systems that are possible for mortals to understand, right? We were promised a Container System, and a container system has daemons, and authorization, and quotas, and random delays, and some kind of Hub where I can download (and partially deduplicate) someone else's multi-gigabyte Hello World images that are built in a highly sophisticated enterprise-ready collaborative construction process. Come on, tell me, can redo do that?

Of course! But we're going to get there the long way.

First, let's use the big heavy Container System with daemons and delays to run our existing tiny understandable container. After that, we'll show how to build a huge incomprehensible container that does the same thing, so your co-workers will think you're normal.

Docker and layers

Normal people build their Docker containers using a Dockerfile. A Dockerfile is sort of like a non-recursive redo, or maybe a Makefile, except that it runs linearly, without the concept of dependencies or parallelization. In that sense, I guess it's more like an IBM mainframe job control script from 1970. It even has KEYWORDS in ALL CAPS, just like 1970.

Dockerfiles do provide one really cool innovation over IBM job control scripts, which is that they cache intermediate results so you don't have to regenerate it every time. Basically, every step in a Dockerfile copies a container, modifies it slightly, and saves the result for use in the next step. If you modify step 17 and re-run the Dockerfile, it can just start with the container produced by step 16, rather than going all the way back to step 1. This works pretty well, although it's a bit expensive to start and stop a container at each build step, and it's unclear when and how interim containers are expunged from the cache later. And some of your build steps are "install the operating system" and "install the compiler", so each step produces a larger and larger container. A very common mistake among Docker users is to leave a bunch of intermediate files (source code, compilers, packages, etc) installed in the output container, bloating it up far beyond what's actually needed to run the final application.

Spoiler: we're not going to do it that way.

Instead, let's use redo to try to get the same Dockerfile advantages (multi-stage cache; cheap incremental rebuilds) without the disadvantages (launching and unlaunching containers; mixing our build environment with our final output).

To understand how we'll do this, we need to talk about Layers. Unlike our kvm initrd from earlier, a Docker image is not just a single tarball; it's a sequence of tarballs, each containing the set of files changed at each step of the build process. This layering system is how Docker's caching and incremental update system works: if I incrementally build an image starting from step 17, based on the pre-existing output from step 16, then the final image can just re-use layers 1..16 and provide new layers 17..n. Usually, the first few layers (install the operating system, install the compilers, etc) are the biggest ones, so this means a new version of an image takes very little space to store or transfer to a system that already has the old one.

The inside of a docker image looks like this:

 $ tar -tf test.image

We could use redo to build a Docker image by simply making a single layer.tar of the filesystem (like we did with initrd), adding a VERSION and json file, and putting those three things into an outer tarball. But if we want a system that works as well as a Dockerfile, we'll have to make use of multiple layers.

Our simple container is already pretty tiny by container standards - 2.6MB - but it's still a bit wasteful. Most of that space turns out to be from the dynamic libraries we imported from the host OS. These libraries don't change when we change Hello World! They belong in their own layer.

Up above, in preparation for this moment, we created to build a separate filesystem, rather than adding the libraries inside, which would have been easier. Now we can make each of those filesystems its own layer.

There's one more complication: we did things a bit backwards. In a Dockerfile, you install the libraries first, and then you install your application. When you replace your application, you replace only the topmost layer. We did it the other way around: we installed our application and some debugging tools, then detected which libraries they need and added a layer on top. The most recent versions of Docker, 1.10 and above, are more efficient about handling layers changing in the middle of the stack, but not everyone is using newer Docker versions yet, so let's try to make things efficient for older Docker versions too.

Luckily, since we're starting from first principles, in redo we can do anything we want. We have to generate a tarball for each layer anyway, so we can decide what goes into each layer and then we can put those layers in whatever sequence we want.

Let's start simple. A layer is just a tarball made of a set of files (again, ignore the try_fakeroot stuff for now):

The magic, of course, is in deciding which files go into which layers. In the script above, that's provided in the .list file corresponding to each layer. The .list file is produced by

This requires a bit of explanation. First of all, you probably haven't seen the very old, but little-known comm program before. It's often described as "compare two sorted files" or "show common lines between two files." But it actually does more than just showing common lines: it can show the lines that are only in file #1, or only in file #2, or in both files. comm -1 -3 suppresses the output of lines that are only in #1 or that are in both, so that it will print the lines that are only in the second file.

If we want to make a libs.layer that contains only the files that are not in simple, then we can use comm -1 -3 to compare simple with libs.

Now, this script is supposed to be able to construct the file list for any layer. To do that, it has to know what parent to compare each layer against. We call that the "diffbase", and for layers that are based on other layers, we put the name of the parent layer in its diffbase file:

(If there's no diffbase, then we use /dev/null as the diffbase. Because if file #1 is empty, then all the lines are only in file #2, which is exactly what we want.)

There's just one more wrinkle: if we just compare lists of files, then we'll detect newly-added files, but we won't detect modified files. To fix this, we augment the file list with file checksums before the comparison (using, then strip the checksums back out in before sending the resulting list to cpio.

The augmented file list looks like this:

$ cat simple.list
. 0040755-0-0-0
./bin 0040755-0-0-0
./bin/busybox 0100755-0-0-ba34fb34865ba36fb9655e724266364f36155c93326b6b73f4e3d516f51f6fb2
./bin/hello 0100755-0-0-22e4d2865e654f830f6bfc146e170846dde15185be675db4e9cd987cb02afa78
./bin/sh 0100755-0-0-e803088e7938b328b0511957dcd0dd7b5600ec1940010c64dbd3814e3d75495f
./init 0120777-0-0-14bdc0fb069623c05620fc62589fe1f52ee6fb67a34deb447bf6f1f7e881f32a

(Side note: the augmentation needs to be added at the end of the line, not the beginning so that the file list is still sorted afterwards. comm only works correctly if both input files are sorted.)

The script for augmenting the file list is fairly simple. It just reads a list of filenames on stdin, checksums those files, and writes the augmented list on stdout:

Just one more thing! Docker (before 1.10) deduplicates images by detecting that they contain identical layers. When using a Dockerfile, the layers are named automatically using random 256-bit numbers (UUIDs). Since Dockerfiles usually don't regenerate earlier layers, the UUIDs of those earlier layers won't change, so future images will contain layers with known UUIDs, so Docker doesn't need to deduplicate them.

We don't want to rely on never rebuilding layers. Instead, we'll adopt a technique from newer Docker versions (post 1.10): we'll name layers after a checksum of their contents. Now, we don't want to actually checksum the whatever.layer file, because it turns out that tarballs contain a bunch of irrelevant details, like inode numbers and mtimes, so they'll have a different checksum every time they're built. Instead, we'll make a digest of the whatever.list file, which conveniently already has a checksum of each file's contents, plus the interesting subset of the file's attributes.

Docker expects 256-bit layer names, so we might normally generate a sha256 digest using the sha256sum program, but that's not available on all platforms. Let's write a python script to do the job instead. To make it interesting, let's write it as a .do file, so we can generate the sha256 of anything by asking for redo-ifchange anything.sha256. This is a good example of how in redo, .do files can be written in any scripting language, not just sh.

Let's test it out:

$ redo simple.list.sha256
redo  simple.list.sha256
redo    simple.list

$ cat simple.list.sha256

$ rm -rf simple

$ redo simple.list.sha256
redo  simple.list.sha256
redo    simple.list
redo      simple.fs

$ cat simple.list.sha256

Consistent layer id across rebuilds! Perfect.

Combining layers: building a Docker image

We're almost there. Now that we can produce a tarball for each layer, we have to produce the final tarball that contains all the layers in the right order. For backward compatibility with older Docker versions, we also need to produce a json "manifest" for each layer. In those old versions, each layer was also its own container, so it needed to have all the same attributes as a container, including a default program to run, list of open ports, and so on. We're never going to use those values except for the topmost layer, but they have to be there, so let's just auto-generate them. Here's the script for customizing each layer's json file from a template:

And here's the empty template:

Now we just need to generate all the layers in a subdirectory, and tar them together:

This requires a list of layers for each image we might want to create. Here's the list of two layers for our simple container:

Finally, some people like to compress their Docker images for transport or uploading to a repository. Here's a nice .do script that can produce the .gz compressed version of any file:

Notice the use of --rsyncable. Very few people seem to know about this gzip option, but it's immensely handy. Normally, if a few bytes change early in a file, it completely changes gzip's output for all future bytes, which means that incremental copying of new versions of a file (eg. using rsync) is very inefficient. With --rsyncable, gzip does a bit of extra work to make sure that small changes in one part of a file don't affect the gzipped bytes later in the file, so an updated container will be able to transfer a minimal number of bytes, even if you compress it.

Let's try it out!

$ redo simple.image.gz
redo  simple.image.gz
redo    simple.image
redo      libs.list.sha256
redo        libs.list
redo          simple.list
redo      libs.layer
3607 blocks
redo      simple.list.sha256
redo      simple.layer
1569 blocks
layer: b65ae6e742f8946fdc3fbdccb326378162641f540e606d56e1e638c7988a5b95 libs
layer: 4d1fda9f598191a4bc281e5f6ac9c27493dbc8dd318e93a28b8a392a7105c145 simple

flow:~/src/redo/docs/cookbook/container $ tar -tf simple.image.gz

In the above, notice how we build libs.layer first and simple.layer second, because that's the order of the layers in simple.image.layers. But to produce libs.list we need to compare the file list against simple.list, so it declares a dependency on simple.list.

The final simple.image tarball then includes the layers in reverse order (topmost to bottommost), because that's how Docker does it. The id of the resulting docker image is the id of the topmost layer, in this case 4d1fda9f.

Loading and running a Docker image

Phew! Okay, we finally have a completed Docker image in the format Docker expects, and we didn't have to execute even one Dockerfile. Incidentally, that means all of the above steps could run without having Docker installed, and without having any permissions to talk to the local Docker daemon. That's a pretty big improvement (in security and manageability) over running a Dockerfile.

The next step is to load the image into Docker, which is easy:

And finally, we can ask Docker to run our image, and capture its output like we did, so long ago, in and

The result is almost disappointing in its apparent simplicity:

$ time redo simple.rundocker
redo  simple.rundocker
redo    simple.load

real    0m2.688s
user    0m0.068s
sys 0m0.036s

$ cat simple.rundocker
Hello, world!

Notice that, for some reason, Docker takes 2.7s to load, launch and run our tiny container. That's about 3x as long as it takes to boot and run a kvm virtual machine up above with exactly the same files. This is kind of weird, since containers are supposed to be much more lightweight than virtual machines. I'm sure there's a very interesting explanation for this phenomenon somewhere. For now, notice that you might save a lot of time by initially testing your containers using default.runlocal (0.11 seconds) instead of Docker (2.7 seconds), even if you intend to eventally deploy them in Docker.

A Debian-based container

We're not done yet! We've built and run a Docker container the hard way, but we haven't built and run an unnecessarily wastefully huge Docker container the hard way. Let's do that next, by installing Debian in a chroot, then packaging it up into a container.

As we do that, we'll recycle almost all the redo infrastructure we built earlier while creating our simple container.

Interlude: Fakeroot

It's finally time to talk about that mysterious script that showed up a few times earlier. It looks like this:

fakeroot is a tool, originally developed for the Debian project, that convinces your programs that they are running as root, without actually running them as root. This is mainly so that they can pretend to chown() files, without actually introducing security holes on the host operating system. Debian uses this when building packages: they compile the source, start fakeroot, install to a fakeroot directory, make a tarball of that directory, then exit fakeroot. The tarball then contains the permissions they want.

Normally, fakeroot forgets all its simulated file ownership and permissions whenever it exits. However, it has -s (save) and -i (input) options for saving the permissions to a file and reloading the permissions from that file, respectively.

As we build our container layers, we need redo to continually enter fakeroot, do some stuff, and exit it again. The script is a helper to make that easier.


The next Debian tool we should look at is debootstrap. This handy program downloads and extracts the (supposedly) minimal packages necessary to build an operational Debian system in a chroot-ready subdirectory. Nice!

In order for debootstrap to work without being an administrator - and you should not run your build system as root - we'll use fakeroot to let it install all those packages.

Unfortunately, debootstrap is rather slow, for two reasons:

  1. It has to download a bunch of things.
  2. It has to install all those things.

And after debootstrap has run, all we have is a Debian system, which by itself isn't a very interesting container. (You usually want your container to have an app so it does something specific.)

Does this sound familiar? It sounds like a perfect candidate for Docker layers. Let's make three layers:

  1. Download the packages.
  2. Install the packages.
  3. Install an app.

Here's step one:

On top of that layer, we run the install process:

Since both steps run debootstrap and we might want to customize the set of packages to download+install, we'll put the debootstrap options in their own shared file:

And finally, we'll produce our "application" layer, which in this case is just a shell script that counts then number of installed Debian packages:

Building the Debian container

Now that we have the three filesystems, let's actually generate the Docker layers. But with a catch: we won't actually include the layer for step 1, since all those package files will never be needed again. (Similarly, if we were installing a compiler - and perhaps redo! - in the container so we could build our application in a controlled environment, we might want to omit the "install compiler" layers from the final product.)

So we list just two layers:

And the 'debian' layer's diffbase is debootstrap, so we don't include the same files twice:

Running the Debian container

This part is easy. All the parts are already in place. We'll just run the existing

$ time redo debian.rundocker
redo  debian.rundocker
redo    debian.load
redo      debian.image
redo        debian.list.sha256
redo          debian.list
redo        debian.layer
12 blocks
layer: a542b5976e1329b7664d79041d982ec3d9f7949daddd73357fde17465891d51d debootstrap
layer: d5ded4835f8636fcf01f6ccad32125aaa1fe9e1827f48f64215b14066a50b9a7 debian

real    0m7.313s
user    0m0.632s
sys 0m0.300s

$ cat debian.rundocker

It works! Apparently there are 82 Debian packages installed. It took 7.3 seconds to load and run the docker image though, probably because it had to transfer the full contents of those 82 packages over a socket to the docker server, probably for security reasons, rather than just reading the files straight from disk. Luckily, our chroot and kvm scripts also still work:

$ time redo debian.runlocal
redo  debian.runlocal

real    0m0.084s
user    0m0.052s
sys 0m0.004s

$ cat debian.runlocal

$ time redo debian.runkvm
redo  debian.runkvm
redo    debian.initrd
193690 blocks
1 block
debian: kvm memory required: 346M
[    0.375365] reboot: Power down

real    0m3.445s
user    0m1.008s
sys 0m0.644s

$ cat debian.runkvm

Testing and housekeeping

Let's finish up by providing the usual boilerplate. First, an that builds, runs, and tests all the images on all the container platforms. This isn't a production build system, it's a subdirectory of the redo package, so we'll skip softly, with a warning, if any of the components are missing or nonfunctional. If you were doing this in a "real" system, you could just let it abort when something is missing.

And here's a redo clean script that gets rid of (most of) the files produced by the build. We say "most of" the files, because actually we intentionally don't delete the debdownload and debootstrap directories. Those take a really long time to build, and redo knows to rebuild them if their dependencies (or .do files) change anyway. So instead of throwing away their content on 'redo clean', we'll keep it around.

Still, we want a script that properly cleans up everything, so let's have redo xclean (short for "extra clean") wipe out the last remaining files: