Description
With the latest cargo xtask test-tmt which mostly just calls out to the new tmt bootc glue, what I get by default is
Cause number 1:
provision step failed
The exception was caused by 1 earlier exceptions
Cause number 1:
Command 'podman run --rm --privileged -v /var/lib/containers/storage:/var/lib/containers/storage --security-opt label=type:unconfined_t -v /var/tmp/tmt/run-004/plans/test-01-readonly/provision/default-0:/output quay.io/centos-bootc/bootc-image-builder:latest build --type qcow2 --rootfs xfs --local localhost/tmtmodified-1741212057' returned 125.
# stderr (1/1 lines)
# ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Error: statfs /var/tmp/tmt/run-004/plans/test-01-readonly/provision/default-0: no such file or directory
# ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
After being confused for a bit what I eventually figured out here is that /var/tmp needs to be part of the podman machine bind mounts when you do podman machine init with e.g. -v /var/tmp:/var/tmp. Except of course if you have an existing machine you need to hand edit ~/.config/containers/podman/machine/qemu/podman-machine-default.json to add that mount, and restart it.
But really we should not require this, it's a logistical annoyance.
The more I think about this, the more strongly of the opinion I am that actually we should always run tmt from a container, not from the "host" (which in my case is a toolbox, but that's mostly irrelevant).
IOW as a bootc developer I should have a flow that's basically
- podman build
- ./ci/script-which-spawns-pods
That latter script should be ideally a low-dependency tool whose job it is just to basically podman run, and we should avoid executing code on the host in the default flow.
(Of course, what I hit last time I tried to go this way is it doesn't work quite as well with IDEs and such, or at least raises the devcontainer issue which again last I looked kind of itself clashes with doing container builds)
Activity