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:
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:
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
exportGOPATH=~/go
go get -u github.com/go-debos/debos/cmd/debos
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
exportPATH=$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):
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:
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).
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.
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.
.png){kind=small}
