Open happz opened 3 weeks ago
@psss @lukaszachy @thrix I'd like to know whether this is something we might ignore for now. I'm working on extending https://github.com/teemtee/tmt/tree/main/tests/prepare/install to cover more distros, because of the recent rpm-ostree
trouble, and one of the newly added distros would be Fedora CoreOS. Unfortunately, some test cases, besides installing packages via prepare/install
, also wish to run a test, to verify the requested packages were indeed installed, and this crashes when it comes to Fedora CoreOS images.
It does not seem to be a regression, I'm wondering whether it's a known issue and whether I can therefore comment out those tests for Fedora CoreOS for now, and get back to them later once we fix the problem of running tests.
I'd ignore it for now, definitely not a know issue to me though.
We have only test executing coreos but it is on VM (/tests/execute/nonroot
) which doesn't suffer from this.
But I'm not sure what is the right thing to do wrt usrlocal. Should we bind it in provision/podman?
Or is this more about supporting 'bootc' containers? The inspect shows image has "containers.bootc": "1",
Note: https://containers.github.io/bootc/filesystem.html#var documents a bit of this
I'd ignore it for now, definitely not a know issue to me though. We have only test executing coreos but it is on VM (
/tests/execute/nonroot
) which doesn't suffer from this.
I am perfectly fine with ignoring it for the purpose of fixing rpm-ostree bug reported and fixing the test runner later.
But I'm not sure what is the right thing to do wrt usrlocal. Should we bind it in provision/podman?
Or is this more about supporting 'bootc' containers? The inspect shows image has
"containers.bootc": "1",
Note: https://containers.github.io/bootc/filesystem.html#var documents a bit of this
No idea. I suppose that in real-life scenarios, such a container gets all the blanks filled by the orchestrator. And I have exactly zero knowledge about this particular kind of image, so I can only guess. I think tmt will need to provide some volumes when running such a container, but now I wouldn't dare to say which, how, and why.
The
/usr/local
in the container is a symlink to/var/uslocal
which does not exist. Therefore tmt fails scripts like/usr/local/bin/tmt-abort
.