Closed busykai closed 5 years ago
@bryteise, I cannot reproduce the issue on my system. Any idea why /run/lock/clrtrust.lock
may have stayed on the filesystem?
@busykai is the problem that the docker images coming from devops have the /run file in it? My guess would be clrtrust is running against the chroot and creating the $chroot/run path itself and that is stored in the image via overlay fs. Seems weird since I would expect docker to mount over /run anyway with tmpfs though.
it's all done with swupd verify --install -p ...
, so clrtrust
runs as part of update hooks. i tried what the base fs creation does and could not reproduce it. the very least we should do is to re-generate and re-publish the docker image. we then need to keep an eye on how this could have happened.
/run/lock/clrtrust.lock
stays on the filesystem after image creation which results in failure to run subsequentclrtrust generate
whether within the container or from Dockerfile.I'm filing this issue here because it seems to be the issue with image generation rather then clrtrust itself.