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 sudo apt install golang sudo apt install libglib2.0-dev libostree-dev go get -u github.com/go-debos/debos/cmd/debos I thought that the first sanity test would be to build the example recipe:

virtio_console driver compiled in the kernel, so the error message seems really confusing: cat /boot/config-4.15.0-24-generic | grep VIRTIO_CONSOLE CONFIG_VIRTIO_CONSOLE=y 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. sudo apt install golang sudo apt install libglib2.0-dev libostree-dev mkdir ~/go export GOPATH=~/go go get -u github.com/go-debos/debos/cmd/debos

git was another dependency for installation: sudo apt install git

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: export PATH=$PATH:/usr/sbin Another try:

root to see how far can we go this time (we are in VirtualBox after all): sudo ~/go/bin/debos ~/go/src/github.com/go-debos/debos/doc/examples/example.yaml The privileged run failed at:

qemu-static is called in order to run arm64 binary. When building for the host archtiecture: sudo ~/go/bin/debos -t architecture:”amd64″ ~/go/src/github.com/go-debos/debos/doc/examples/example.yaml After a while,

almost success: 2018/07/26 14:00:39 Debootstrap | I: Base system installed successfully. 2018/07/26 14:00:39 Action debootstrap failed at stage Run, error: exec: “systemd-nspawn”: executable file not found in $PATH Another package missing, namely

systemd-container: sudo apt install 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. ./docker/run.sh doc/examples/example.yaml

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

Conclusion

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.