-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
podman cp under vfs: ENOENT #20282
Comments
Seems to be a race. A subsequent retry succeeds. |
I think this is something different than #20299, there is no real mountpoint with VFS since it is a plain directory so it cannot be "unmounted" unless it is deleted |
A friendly reminder that this issue had no activity for 30 days. |
Seen in: sys podman+remote fedora-38 root+rootless host boltdb+sqlite |
Possibly related: Looked at the test in Ideally, this test would use some mechanism to first check (inside the container) if the launch command (i.e. |
Nice catch, thank you! Fix in progress. |
Some of the tests were doing "podman run -d" without wait_for_ready. This may be the cause of some of the CI flakes. Maybe even all? It's not clear why the tests have been working reliably for years under overlay, and only started failing under vfs, but shrug. Thanks to Chris for making that astute observation. Fixes: containers#20282 (I hope) Signed-off-by: Ed Santiago <[email protected]>
Some of the tests were doing "podman run -d" without wait_for_ready. This may be the cause of some of the CI flakes. Maybe even all? It's not clear why the tests have been working reliably for years under overlay, and only started failing under vfs, but shrug. Thanks to Chris for making that astute observation. Fixes: containers#20282 (I hope) Signed-off-by: Ed Santiago <[email protected]>
podman cp
system tests flake under VFS, with pretty consistent symptoms:or
I've been chasing this one all week because it's a hard blocker for #20161. It's a BAD flake, failing on almost every run, and pretty easily reproducible in 1minutetip. Despite my hopes this morning in seeing containers/storage#1724, that does not fix the problem: the
10-05
failures below include a vendored c/storage.Seen in: podman/remote fedora-38 root/rootless boltdb/sqlite
"fedora-38" is only special because that's
prior-fedora
which meansforce VFS
under the rules of #20161. It could possibly be a kernel or distro bug only on f38, but I choose not to even bother considering that right now. I'm treating it as a VFS driver bug.The text was updated successfully, but these errors were encountered: