Our first look at debos - new Debian images generator

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

1
2
3
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:

1
~/go/bin/debos ~/go/src/go-debos/debos/doc/examples/example.yaml

The first problem appears in the beginning:

1
2
3
4
2018/07/17 18:02:17 open failed:
  /lib/modules/4.15.0-24-generic/kernel/drivers/char/virtio_console.ko -
  open /lib/modules/4.15.0-24-generic/kernel/drivers/char/virtio_console.ko:
  no such file or directory

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

1
2
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 Stretch box from osboxes.

1
2
3
4
5
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:

1
sudo apt install git
1
~/go/bin/debos ~/go/src/github.com/go-debos/debos/doc/examples/example.yaml

Output from the first run:

1
2
3
4
5
6
7
2018/07/26 13:13:09 fakemachine not supported, running on the host!
2018/07/26 13:13:09 ==== debootstrap ====
2018/07/26 13:13:09 debootstrap.log | cat:
  /home/osboxes/.debos-873708939/root/debootstrap/debootstrap.log:
  No such file or directory
2018/07/26 13:13:09 Action `debootstrap` failed at stage Run, error: exec:
  "debootstrap": executable file not found in $PATH
1
sudo apt install debootstrap

Still no luck after second try:

1
2
3
4
5
6
7
2018/07/26 13:17:25 fakemachine not supported, running on the host!
2018/07/26 13:17:25 ==== debootstrap ====
2018/07/26 13:17:25 debootstrap.log | cat:
  /home/osboxes/.debos-909422932/root/debootstrap/debootstrap.log:
  No such file or directory
2018/07/26 13:17:25 Action `debootstrap` failed at stage Run, error:
  exec: "debootstrap": executable file not found in $PATH

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:

1
export PATH=$PATH:/usr/sbin

Another try:

1
2
3
4
5
6
7
8
2018/07/26 13:54:37 fakemachine not supported, running on the host!
2018/07/26 13:54:37 ==== debootstrap ====
2018/07/26 13:54:37 Debootstrap | E: debootstrap can only run as root
2018/07/26 13:54:37 debootstrap.log | cat:
  /home/osboxes/.debos-418422200/root/debootstrap/debootstrap.log:
  No such file or directory
2018/07/26 13:54:37 Action `debootstrap` failed at stage Run, error:
  exit status 1

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

1
sudo ~/go/bin/debos ~/go/src/github.com/go-debos/debos/doc/examples/example.yaml

The privileged run failed at:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
2018/07/26 13:36:38 Debootstrap (stage 2) | chroot: failed to run command
  ‘/debootstrap/debootstrap’: Exec format error
2018/07/26 13:36:38 debootstrap.log | gpgv: Signature made
  Thu Jul 26 10:21:51 2018 EDT
2018/07/26 13:36:38 debootstrap.log | gpgv:                using RSA key
  A1BD8E9D78F7FE5C3E65D8AF8B48AD6246925553
2018/07/26 13:36:38 debootstrap.log | gpgv: Good signature from "Debian Archive
  Automatic Signing Key (7.0/wheezy) <ftpmaster@debian.org>"
2018/07/26 13:36:38 debootstrap.log | gpgv: Signature made
  Thu Jul 26 10:21:51 2018 EDT
2018/07/26 13:36:38 debootstrap.log | gpgv:                using RSA key
  126C0D24BD8A2942CC7DF8AC7638D0442B90D010
2018/07/26 13:36:38 debootstrap.log | gpgv: Good signature from "Debian Archive
  Automatic Signing Key (8/jessie) <ftpmaster@debian.org>"
2018/07/26 13:36:38 debootstrap.log | gpgv: Signature made
  Thu Jul 26 10:21:51 2018 EDT
2018/07/26 13:36:38 debootstrap.log | gpgv:                using RSA key
  16E90B3FDF65EDE3AA7F323C04EE7237B7D453EC
2018/07/26 13:36:38 debootstrap.log | gpgv: Good signature from "Debian Archive
  Automatic Signing Key (9/stretch) <ftpmaster@debian.org>"
2018/07/26 13:36:38 Action `debootstrap` failed at stage Run,
  error: exit status 126

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

When building for the host architecture:

1
2
sudo ~/go/bin/debos  -t architecture:"amd64"
  ~/go/src/github.com/go-debos/debos/doc/examples/example.yaml

After a while, almost success:

1
2
3
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:

1
sudo apt install systemd-container

And finally, we have our image:

1
2
3
4
5
6
7
8
2018/07/26 14:11:45 ==== overlay ====
Overlaying
  /home/osboxes/go/src/github.com/go-debos/debos/doc/examples/overlays/sudo
  on /home/osboxes/.debos-414397177/root
2018/07/26 14:11:45 ==== run ====
2018/07/26 14:11:45 ==== pack ====
2018/07/26 14:11:45 Compression to /home/osboxes/debian-stretch-amd64.tgz
2018/07/26 14:11:56 ==== Recipe done
1
88M     debian-stretch-amd64.tgz

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.

1
./docker/run.sh -t architecture:"amd64" doc/examples/example.yaml
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
2018/07/26 18:36:39 Debootstrap (stage 2) | chroot: failed to run command
  '/debootstrap/debootstrap': Exec format error
2018/07/26 18:36:39 debootstrap.log | gpgv: Signature made
  Thu Jul 26 14:21:51 2018 UTC
2018/07/26 18:36:39 debootstrap.log | gpgv:                using RSA key
  A1BD8E9D78F7FE5C3E65D8AF8B48AD6246925553
2018/07/26 18:36:39 debootstrap.log | gpgv: Good signature from "Debian Archive
  Automatic Signing Key (7.0/wheezy) <ftpmaster@debian.org>"
2018/07/26 18:36:39 debootstrap.log | gpgv: Signature made
  Thu Jul 26 14:21:51 2018 UTC
2018/07/26 18:36:39 debootstrap.log | gpgv:                using RSA key
  126C0D24BD8A2942CC7DF8AC7638D0442B90D010
2018/07/26 18:36:39 debootstrap.log | gpgv: Good signature from "Debian
  Archive Automatic Signing Key (8/jessie) <ftpmaster@debian.org>"
2018/07/26 18:36:39 debootstrap.log | gpgv: Signature made
  Thu Jul 26 14:21:51 2018 UTC
2018/07/26 18:36:39 debootstrap.log | gpgv:                using RSA key
  16E90B3FDF65EDE3AA7F323C04EE7237B7D453EC
2018/07/26 18:36:39 debootstrap.log | gpgv: Good signature from "Debian Archive
  Automatic Signing Key (9/stretch) <ftpmaster@debian.org>"
2018/07/26 18:36:39 Action `debootstrap` failed at stage Run, error:
  exit status 126
Powering off.

And the build for host architecture:

1
./docker/run.sh -t architecture:"amd64" doc/examples/example.yaml

Finished just fine:

1
2
3
4
5
6
7
8
9
2018/07/26 19:20:30 ==== overlay ====
Overlaying /root/doc/examples/overlays/sudo on /scratch/root
2018/07/26 19:20:30 ==== run ====
2018/07/26 19:20:30 echo debian > /etc/hostname | host's /etc/localtime is not
  a symlink, not updating container timezone.
2018/07/26 19:20:30 ==== pack ====
2018/07/26 19:20:30 Compression to /root/debian-stretch-amd64.tgz
Powering off.
2018/07/26 19:20:44 ==== Recipe done ====

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

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.


Maciej Pijanowski
Engineering Manager at 3mdeb with years of experience in engineering and management. Open-source software enthusiast and contributor. Interested in embedded systems in general, build systems, security.