Containerfile: use hummingbird base images

[jbtrystram]

Use hardenned images from the hummingbird project.

[alicefr]

@jbtrystram the hummingbird images don't include nsenter and the CI is failing for that reason. From the daemon logs:

2026-09-15T11:17:17Z	ERROR	Reconciler error	{"controller": "bootcnode", "controllerGroup": "node.bootc.dev", "controllerKind": "BootcNode", "BootcNode": {"name":"testcontrollermembership-67b7ce"}, "namespace": "", "name": "testcontrollermembership-67b7ce", "reconcileID": "5dc5d935-9721-405b-9f17-ca0304cf4dd3", "error": "populating bootc fields: getting bootc status: running bootc status: exec: \"nsenter\": executable file not found in $PATH"}

We are using nsenter in order to execute bootc binary

[jbtrystram]

@jbtrystram the hummingbird images don't include nsenter and the CI is failing for that reason. From the daemon logs:

2026-09-15T11:17:17Z	ERROR	Reconciler error	{"controller": "bootcnode", "controllerGroup": "node.bootc.dev", "controllerKind": "BootcNode", "BootcNode": {"name":"testcontrollermembership-67b7ce"}, "namespace": "", "name": "testcontrollermembership-67b7ce", "reconcileID": "5dc5d935-9721-405b-9f17-ca0304cf4dd3", "error": "populating bootc fields: getting bootc status: running bootc status: exec: \"nsenter\": executable file not found in $PATH"}

We are using nsenter in order to execute bootc binary

Alright, added the nsenter. I feel that's going to be a long game of whack-a-mole :)

[alicefr]

@cheesesashimi @zarcen what is your take if we move from fedora to hummingbird images ?

[cgwalters]

Mmm copying a binary like this is a bit ugly; in practice it's likely going to work because te chance that util-linux gains a dependency on anything other than glibc is probably small, but I think hummingbird should support installing extra packages in the runtime image no?

(Or of course, we could do the nsenter in Go, it's not a lot of code)

[cheesesashimi]

The latest-builder version of the Hummingbird images has dnf. But to keep the final image as distroless as possible, we'd want to use a multistage build where we download util-linux (and any deps), extract them to a directory, then copy that directory on top of the final base image (based on the latest variant instead of the latest-builder variant). I forget the exact syntax to do that, but I know it can be done.

[cgwalters]

This pattern is something we enable in https://docs.fedoraproject.org/en-US/bootc/building-from-scratch/ and would make sense to do in hummingbird too

[jbtrystram]

The latest-builder version of the Hummingbird images has dnf. But to keep the final image as distroless as possible, we'd want to use a multistage build where we download util-linux (and any deps), extract them to a directory, then copy that directory on top of the final base image (based on the latest variant instead of the latest-builder variant). I forget the exact syntax to do that, but I know it can be done.

Alright I did that but that's pulling a lot of deps :

Installing:
 util-linux-core        x86_64 0:2.42.2-3.4.hum1    public-hummingbird-x86_64-rpms   1.5 MiB
Installing dependencies:
 bash                   x86_64 0:5.3.15-2.1.hum1    public-hummingbird-x86_64-rpms   8.5 MiB
 filesystem             x86_64 0:3.18-59.hum1       public-hummingbird-x86_64-rpms 112.0   B
 glibc                  x86_64 0:2.43-8.5.hum1      public-hummingbird-x86_64-rpms   6.9 MiB
 glibc-common           x86_64 0:2.43-8.5.hum1      public-hummingbird-x86_64-rpms   1.0 MiB
 glibc-minimal-langpack x86_64 0:2.43-8.5.hum1      public-hummingbird-x86_64-rpms   0.0   B
 hummingbird-gpg-keys   noarch 0:20251124-1.16.hum1 public-hummingbird-x86_64-rpms  20.5 KiB
 hummingbird-release    noarch 0:20251124-1.16.hum1 public-hummingbird-x86_64-rpms  19.4 KiB
 hummingbird-repos      noarch 0:20251124-1.16.hum1 public-hummingbird-x86_64-rpms 520.0   B
 libblkid               x86_64 0:2.42.2-3.4.hum1    public-hummingbird-x86_64-rpms 282.3 KiB
 libgcc                 x86_64 0:16.2.1-2.hum1      public-hummingbird-x86_64-rpms 270.7 KiB
 libmount               x86_64 0:2.42.2-3.4.hum1    public-hummingbird-x86_64-rpms 404.9 KiB
 libselinux             x86_64 0:3.11-5.hum1        public-hummingbird-x86_64-rpms 205.2 KiB
 libsepol               x86_64 0:3.11-2.hum1        public-hummingbird-x86_64-rpms 862.1 KiB
 libsmartcols           x86_64 0:2.42.2-3.4.hum1    public-hummingbird-x86_64-rpms 192.4 KiB
 libuuid                x86_64 0:2.42.2-3.4.hum1    public-hummingbird-x86_64-rpms  37.2 KiB
 libxcrypt              x86_64 0:4.5.2-4.hum1       public-hummingbird-x86_64-rpms 293.2 KiB
 ncurses-base           noarch 0:6.6-3.hum1         public-hummingbird-x86_64-rpms 329.7 KiB
 ncurses-libs           x86_64 0:6.6-3.hum1         public-hummingbird-x86_64-rpms 968.9 KiB
 pcre2                  x86_64 0:10.48-0.1.hum1     public-hummingbird-x86_64-rpms 726.6 KiB
 pcre2-syntax           noarch 0:10.48-0.1.hum1     public-hummingbird-x86_64-rpms 291.2 KiB
 setup                  noarch 0:2.15.1-2.hum1      public-hummingbird-x86_64-rpms 725.6 KiB
 systemd-libs           x86_64 0:261.2-1.hum1       public-hummingbird-x86_64-rpms   2.7 MiB

which is not great. I guess let's do that for now but aim to do the nsenter with go down the line.

[cheesesashimi]

@alicefr Sounds like a good idea to me! We need to resolve the nsenter issue, but I'll put my comments about that under @cgwalters's comment.

[HarshwardhanPatil07]

I was spending some time learning about this after our meeting.

could anyone please point me to right resources to understand the bigger picture here why we are shifting from fedora to hummingbird images? i tried utilizing ai to understand this why fedora and hummingbrd images but still curious to know if there's bigger picture we are looking upto

cc @jbtrystram @alicefr

[HarshwardhanPatil07]

this is the one humming bird doc which i saw mentioned above is that the why?

[jbtrystram]

@HarshwardhanPatil07 for productization we'll have to use compliant base images, not fedora-minimal.
And as the public hummingbird images are the same as the productized ones (minus the signatures) it's a drop-in replacement. So I thought that would be a good candidate.
That's said we can definitely have a separate containerfile downsteam and close this PR.

[alicefr]

@jbtrystram it seems the podman version of the CI doesn't support heredocs properly can you try with && instead of the EORUN?

diff --git a/Containerfile b/Containerfile
index 315e7f8..b5c529b 100644
--- a/Containerfile
+++ b/Containerfile
@@ -5,18 +5,16 @@ FROM ${HB_REGISTRY}/go:latest-builder AS deps
 # We pull required dependencies and overlay them
 # on top of the runtime image
 ARG DNF_FLAGS="-y --setopt=install_weak_deps=False --nodocs"
-RUN --mount=type=cache,id=dnf,target=/var/cache/libdnf5 <<EORUN
-    mkdir -p /staged
+RUN --mount=type=cache,id=dnf,target=/var/cache/libdnf5 \
+    mkdir -p /staged && \
     dnf install -y \
         --use-host-config \
         --installroot=/staged \
-        util-linux-core
-    # Remove metadata and manpages
+        util-linux-core && \
     rm -rf /staged/var/lib/dnf \
         /staged/var/log/* \
         /staged/var/lib/rpm \
         /staged/usr/share/{man,doc,locale}
-EORUN

[alicefr]

can we use other tags then latest? Like 1.26.8 for go and 2.43 for the runtime?

[alicefr]

@jbtrystram last commit isn't signed. I would also squash all the commits into a single one

[alicefr]

For the rest it looks good to me