What is debos

debos is quite a new tool allowing easier Debian images generation. It seems to be following current trends – it is written in Go, using YAML as an input format. The idea of taking away debootstrap shell scripts and replacing it with a single, simple YAML file looks tempting enough to give it a try. Full feature description can be found in this introductory post on Collabora’s blog.

First approach – Ubuntu host

In order to get started, I followed with the installation steps as given in the installation section from the GitHub repo README. The installation commands are for Debian but I thought it will work just fine (as usual) on my fresh Ubuntu 18.04 laptop. Well, not quite. So the installation looks like:

I have decided to skip the GOPATH export and stick to the default GOPATH=~/go

I thought that the first sanity test would be to build the example recipe:

The first problem appears in the beginning:

I have virtio_console driver compiled in the kernel, so the error message seems really confusing:

It seems to be known issue, which is described in one of the fakemachine’s github issues. fakemachine is another module written in Go, which is a dependency of debos. It seems to be a wrapper for qemu-system in order to allow for running image building phases as an unprivileged user. It may not be obvious at first, as this thing does not even have a single README.

So, it seems that it just won’t work on the Ubuntu? Running on any other distro is also questionable. It seems that there are more unsolved issues when running on distros other than Debian. And those issues were open back in Nov 2017, so it is definitely not a priority to make it work properly on distros other than Debian.

Second approach – Debian VirtualBox

I decided to give it another chance and try running inside VirtualBox. I went with a fresh Debian 9.3 Strech box from osboxes.

git was another dependency for installation:

Output from the first run:

Still no luck after second try:

The first message (fakemachine not supported) from log above appears when there is no /dev/kvm device present. Although, I’m not sure if this is a strict requirement in order to run qemu.

It seems debootstrap is at /usr/sbin/debootstrap – so not in user’s default PATH:

Another try:

Of course. I don’t mind running as root to see how far can we go this time (we are in VirtualBox after all):

The privileged run failed at:

It seems to me that no correct qemu-static is called in order to run arm64 binary.

When building for the host archtiecture:

After a while, almost success:

Another package missing, namely systemd-container:

And finally, we have our image:

Third approach – docker container

With above problems in mind, it seems like mandatory to package all those things in a portable, easy-to-use container. In fact, this is one of the items from the project’s TODO list. Thanks to the VirtualBox triage I am already armed with a list of dependencies and potential issues to come.

I’ve noticed that fakemachine already has a Dockerfile, so I had something to take a look at. However, it seems to be used to build fakemachine at container runtime, which is not exactly our target if we want to push the functional debos image to the Docker Hub.

I went with multi-stage-build in order to reduce the image size (do not include build dependencies into the image, only the runtime ones).

I ended up with the following Dockerfile.

And the build for host architecture:

Finished just fine:

In a conclusion, when building for a non-host architecture we have the same error as it was in the case of VirtualBox. I’m not sure what might be the issue: either the proper qemu-static is not used, or some virtualization problems? Debugging of what’s going on beneath is not easy, especially if there is no way to have more debug output from the debos or fakemachine tools (at least I have not found any).


debos seems like a really cool tool for Debian images building without tinkering with debootrap and chroot script that much. Unfortunately, I was unable to build an image for arm or arm64 so far (which is my main interest). Maybe on the native installed Debian it would just work perfectly I did not have the opportunity to try it this way. I think that having a docker container with debos tool fits perfectly into this case and would allow many more people to benefit from using it. I will try to push my work upstream and start a discussion, so the cross-building issues will be hopefully resolved.