Is it possible to auto-update a Toolbx container with Podman Quadlet?

I’m running Silverblue 38 and I’d like to automatically update my Toolbx containers. I want my system to periodically reach out to the remote image registry to see if a Toolbx image has been updated, pull it down if a new one is found, and then recreate the Toolbx based on the new image.

I’ve tried to do this using Podman’s Quadlet feature, which relies on systemd to manage containers and volumes, but have been unsuccessful. I used the initial example in podman-auto-update(1) to start my little project.

From that example, I was able to have a new image automatically pulled down upon detection of a different container image digest, which is great. The Quadlet file I’m using (see below) defines an official Toolbx image. The fundamental issue: the container produced through this process is incompatible with Toolbx.

Running toolbox list doesn’t show the resulting “systemd-fedora-toolbox” container, while podman container list does. When entering the new container, I’m greeted by a vanilla prompt (the prepended diamond symbol is gone). Additionally, the usual file to help you identify a Toolbx container is missing:

$ podman exec systemd-fedora-toolbox stat /run/.toolboxenv
stat: cannot statx '/run/.toolboxenv': No such file or directory

I assume the general problem is related to podman being called directly instead of toolbox, and so the toolbox init-container command isn’t being used for the container’s entry point. Other reasons aside, my newness to the tech is most likely why it’s not working.

Any insights or pointers would be appreciated.

Contents of the Quadlet .container file.
cat $HOME/.config/containers/systemd/fedora-toolbox.container
Exec=sleep infinity
Contents of the service file generated by Quadlet.
/usr/libexec/podman/quadlet -dryrun -user
quadlet-generator[1091319]: Loading source unit file /var/home/jrandom/.config/containers/systemd/fedora-toolbox.container
Exec=sleep infinity


ExecStop=/usr/bin/podman rm -f -i --cidfile=%t/%N.cid
ExecStopPost=-/usr/bin/podman rm -f -i --cidfile=%t/%N.cid
ExecStart=/usr/bin/podman run --name=systemd-%N --cidfile=%t/%N.cid --replace --rm --cgroups=split --sdnotify=conmon -d --label io.containers.autoupdate=registry sleep infinity

See Also

1 Like

I think the container images only get created once at release and only get replaced if there is a problem with that image. So basically, every release cycle there will be a corresponding image created. Quadlet seems more in tune with keeping a custom OCI image you created up to date. You could use quadlet the way you have and then create an image from the resulting podman container and have toolbox create a new toolbox container based on that new image.

To go this path, you would have to make sure your quadlet uses the exact same arguments as toolbox uses to create the containers.

Otherwise, you can make a small bash scripts that does toolbox rm; podman pull; toolbox create and call it in a systemd unit.

To elaborate, I’m actually creating my own Toolbx images with<version-id> as the parent, inspired by Timothée’s quay-containerfiles project.

I tested Quadlet to see if my custom Toolbx images were causing issues. I added the line in a separate Quadlet file, as shown in my example, but the result was the same, whether using the official or custom image.

So essentially, grab the output of podman inspect --type container --format ' {{ .Config.CreateCommand }}' <containerfoo> (similar to this post) and translate that into the appropriate options for [Container] in the Quadlet file, right? I see PodmanArgs= in the Podman documentation as a potential target option to use in the Quadlet file.

Thanks, I may give that a try. Squeezing Toolbx into the Quadlet approach may be too much of a headache right now.

Unrelated, but I had intended my last message to be a direct reply to Stephen. It seems @mentioning someone (I had originally done so by writing Timothée’s handle as @siosm in that message) is interpreted by the forum as a reply as well, which I noticed only after the message was posted. problem