Elbe Docker container

[thir820]

This commit adds a Docker container for elbe which supports building images without an initvm. It supports Debian and Ubuntu based images and can built with a Debian or and Ubuntu base. Building images for foreign architecutres is supported, if the binfmt_misc kernel module is loaded in the host environment.

The command build_image is proided as helper for one-shot builds:

Usage: build_image
[ -c | --build-sdk ]
[ -r | --result-path ]
-i | --image path/to/image/xml

Known issues:

• The initvm command doesn't work
• Building ISOs doesn't work

[t-8ch]

Thanks for your contribution!
I have a few general remarks.

Currently I have a few issues with the design of the PR.

• There is a lot of hackery going on, installing parts of elbe that work for your specific usecase.

  One of my next goal is to make the initvm much more flexible. Using a libvirt, local qemu, a remote machine via SSH or a local machine should all be possible. This would remove the need for that part of the PR. I don't know when that will be done, though.

• The container seems to be meant to be used interactively. I would prefer a primarily non-interactive use like:
  docker run -v $PWD/:src $IMAGE submit foo.xml

• The Dockerfile and scripts are reinventing a rootfs-builder. Which elbe itself already is.
  elbe can create tar archives and these should be importable into docker with docker image import.
  Different base operating systems could be different variants.
  Or does this break your bootstrapping?

• What are source.xml, elbe.list for?

In general it should be fine for contrib/ but my hope is to be able to remove it again in the future.

[thir820]

Hi @t-8ch,

• There is a lot of hackery going on, installing parts of elbe that work for your specific usecase.
  One of my next goal is to make the initvm much more flexible. Using a libvirt, local qemu, a remote machine via SSH or a local machine should all be possible. This would remove the need for that part of the PR. I don't know when that will be done, though.

Yes, that's true and mainly results from the fact that elbe is at the moment expecting a not-documented environment. If elbe would be more flexible wrt this, it would help to make this more clean.
This hacky solution is necessary to avoid the need for nested virtualization, which is a problem in many cloud environments.

• The container seems to be meant to be used interactively. I would prefer a primarily non-interactive use like:
  docker run -v $PWD/:src $IMAGE submit foo.xml

I built the container as a base for a VS Code dev container workspace for image and application development (see https://github.com/thir820/elbe_dev_container/tree/ebcl_1.1.1_no_vm ). This is a interactive use case, since this container also needs to provide all other tools necessary for the use-cases, as a pre-defined development environment. A non-interactive "CI" usage is also possible, but it's a secondary goal.

• The Dockerfile and scripts are reinventing a rootfs-builder. Which elbe itself already is.
  elbe can create tar archives and these should be importable into docker with docker image import.
  Different base operating systems could be different variants.
  Or does this break your bootstrapping?

Yes, it breaks the bootstrapping. The container is not pre-built and delivered, but instead the container is built by the VS Code dev containers plugin by calling a build script (see https://github.com/thir820/elbe_dev_container/blob/ebcl_1.1.1_no_vm/.devcontainer/build_container.sh ). With this setup, I don't need to run a Docker registry and can built for the local environment (e.g. UID), to allow a seamless integration. The only requirement for the host is that Docker is available, and that the binfmt_misc kernel module is loaded if cross building is wanted.

• What are source.xml, elbe.list for?

soruce.xml is copied to /var/cache/elbe/, since the elbe service is expecting such a file and doesn't work properly without it.

elbe.list is indeed not used anymore and can be removed. It would be needed if elbe is installed from the apt repo instead of using the sources.

[t-8ch]

This hacky solution is necessary to avoid the need for nested virtualization, which is a problem in many cloud environments.

FYI with the changes in https://lists.linutronix.de/pipermail/elbe-devel/2024-May/006954.html elbe should work completely without any virtualization extensions.

With this setup, I don't need to run a Docker registry and can built for the local environment (e.g. UID), to allow a seamless integration. The only requirement for the host is that Docker is available, and that the binfmt_misc kernel module is loaded if cross building is wanted.

When building through elbe a registry would also not be necessary.
Not even a docker daemon for the build itself.

since the elbe service is expecting such a file and doesn't work properly without it.

Ack.

Some more questions:

elbe.asc seems unneeded.

What is the advantage of supporting multiple base operating systems?
Why are sources.list installed that are already present?
Instead of using sed on the dockerfile use an ARG to make clear that it is variable.

[t-8ch]

Unused

[t-8ch]

This check will also fail if binfmt_misc is builtin.

Instead check for "binfmt_misc" in /proc/filesystems/.
Or unconditionally call modprobe. It will helpfully do nothing if it's builtin.

[t-8ch]

This disables "abort on error", intentional?
If so, it needs an explanation.

[t-8ch]

use pushd and popd below. Or a subshell.

[t-8ch]

arm64 is in the main Ubuntu archive, so I think the separation is not necessary.
http://archive.ubuntu.com/ubuntu/dists/lunar/Release