 Faster/Easier Development?

From my perspective, containers are more about standardizing application packaging and deployment than simplifying it. Bootable containers would be in the same scenario, but they also introduce new complexities and trade-offs. For example, they may also require additional tooling and infrastructure to manage container images and ensure compatibility with the underlying hardware. On top of that, developers who are new to containerization may initially move more slowly because of the learning curve.

In my view, the learning curve is roughly the same as using containers with an OCI runtime on top of a traditional Linux distribution, which is already a familiar approach.

Another point to consider is the base distribution for your container image. In embedded Linux, depending on the platform and hardware, it may not be possible to choose a specific base distro or version freely. From my experiments with bootc, and given that it is still a fairly new project, dependency versions tend to be very recent and may not be compatible with older libraries and tools that are common in LTS embedded Linux distributions. That can create compatibility issues and may require extra work to adapt the tooling to specific versions or build dependencies from source, which slows development.

 OS as Container Image?

From the bootc documentation:

A key goal of the bootc project is to think of bootable operating systems as container images. Docker/OCI container images are just tarballs wrapped with some JSON. But in order to boot a system, whether on bare metal or virtualized, one needs a few key components:

•  bootloader
•  kernel (and optionally initramfs)
•  root filesystem rootfs

bootc tooling will not magically make the process of building and maintaining an embedded Linux distribution easier; it mainly changes how you package and deploy it.

Another point to take into consideration is the multi-container/service use of containers. This is not possible with bootc because it is designed to boot a single “container” image as the root filesystem. So, if you want to run multiple services these should be already included, with all the depedencies, in the same container and managed by systemd for example.

 Vendor Agnostic?

Anyone with even a minimal experience bringing up embedded Linux on new hardware knows that these systems are often very vendor-specific and require a lot of custom work to get them running. bootc may provide a standardized way to package and deploy the rootfs, but it does not solve the underlying challenges of hardware enablement and support. You will probably still need build systems like Yocto, Buildroot, or Gaia Build System to build and maintain critical parts of your embedded Linux distribution such as the bootloader, kernel, kernel modules, and so on. You will still need to deal with the specific hardware requirements and constraints of your target platform.

 Bootloader Support?

From the bootc help output, we can see:

bootc install to-disk --help

So there is no u-boot support for now, even though it is the most widely used bootloader in embedded Linux systems. This is a significant limitation. Some workaround, or some way to chain u-boot with systemd-boot, would need to be implemented. That adds more friction to the process.

 Already Known Dev Tools?

So, would I be able to use the same development flow and tools? In theory, yes, but in practice, at least in my experiments, I found that it works much better within the Red Hat ecosystem. I started with the bootc examples using the OCI runtime I already had installed, Docker, and I ran into a lot of issues. After switching to podman, the examples and commands started to work much better.

󰟦 CI/CD

One of the main selling points of bootc is the ability to use it with the infrastructure and tooling that teams already use to build and deploy container images. In my experience, though, this was not as straightforward as it sounds. In my tests, I had to use bootc install to-filesystem. I was running it inside a container, and the CI/CD pipeline was already in a PinP (Podman in Podman) setup. That made it difficult to get a successful build. Why? Because of code like this:

/// Run a command in the host mount namespace
pub(crate) fn run_in_host_mountns(cmd: &str) -> Result<Command> {
    let mut c = Command::new(bootc_utils::reexec::executable_path()?);
    c.lifecycle_bind()
        .args(["exec-in-host-mount-namespace", cmd]);
    Ok(c)
}

Running DinD (Docker in Docker) or PinP (Podman in Podman) in CI/CD pipelines is relatively common, but it can introduce challenges and limitations when you try to use bootc tooling.

 The Successor to OSTree?

From a bootc project page:

but a toplevel goal of `bootc` is to be the successor to `ostree`

I found this statement a bit surprising. I even left a question on the bootc GitHub repository about it:

OSTree, or as some like to call it, “Git for operating system binaries,” has long been a useful and well-known tool for managing and deploying secure, atomic updates to embedded Linux devices. Would bootc be a good replacement for OSTree? I honestly think they are different tools with different goals and use cases.

bootc uses OSTree as the underlying technology for managing the root filesystem, but from what I saw in the repository, the direction seems to be toward using composefs instead, which is already the default for some examples and linting. So, IMHO bootc is not a direct successor to OSTree, but rather a different approach.

 Container image Upgrades?

Still on the subject of bootc as a successor to OSTree, one thing I also noticed in practice was the difference in update size. With OSTree, updates were smaller because it transferred only the differences in the root filesystem, such as file edits, additions, and deletions.

With bootc, the Containerfile needs to be crafted much more carefully. A small change can invalidate an entire image layer, which may cause a larger update to be downloaded than you would expect from the actual filesystem change. That is a significant consideration for embedded Linux devices, where bandwidth and storage constraints are common.

 Conclusion

bootc sounds cool and seems like a good idea for embedded Linux systems, but it is not a magic solution that will solve all the challenges and complexities of building and maintaining an embedded Linux distribution. If you have heard people talk about it that way, I am sorry to disappoint you. It may offer some benefits in terms of packaging and deployment, but it also introduces new trade-offs and limitations that need to be considered carefully.

It is also important to note that bootc is a very new project. Let us pay attention to how it evolves and how the community adopts it, but for now, I would say that the goal of the project is not to be embedded Linux-specific. Rather, it aims to provide a more general solution for bootable containers that can be used in a variety of contexts, with embedded Linux being one of the side effects of that broader goal.

Know you are loved ❤️