You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have a machine where #919 doesn't seem to work as intended
[core@seed ~]$ uname -a
Linux seed 5.14.0-284.55.1.el9_2.x86_64 #1 SMP PREEMPT_DYNAMIC Mon Feb 19 16:57:59 EST 2024 x86_64 x86_64 x86_64 GNU/Linux
It's basically just an 4.15.2 SNO
Without -v /var/lib/containers/storage:/var/lib/containers/storage:
ERROR Installing to filesystem: Creating ostree deployment: Pulling: Creating importer: failed to invoke method OpenImage: failed to invoke method OpenImage: reference "[overlay@/var/lib/containers/storage+/run/containers/storage:overlay.mountopt=nodev,metacopy=on]quay.io/foo/bar@sha256:4051f73db7428c9e78d699fc803df8aba04bcdfdbe7db360926674755f24a506" does not resolve to an image ID: identifier is not an image
With -v /var/lib/containers/storage:/var/lib/containers/storage it works
The text was updated successfully, but these errors were encountered:
Humm fun. We'll probably need to do some live debugging.
5.14.0-284.55.1.el9_2.x86_64
OK so RHEL 9.2, I only tested on 9.5+. I wonder if there's some subtleties in the new mount API going on here.
Actually...looking into things here I think the error handling in that code is at best suboptimal, I can't say for sure that if we got an error in the forked child it'd propagate correctly to the parent. Looking...
Motivated by containers#957
but probably not any kind of fix in reality. Our error handling here
was buggy. What we really should do is avoid `fork()` and do
an execve here, but that's a larger refactor.
- Close the other side of the socket in the forked child so
the parent doesn't hang indefinitely if the child dies
before sending
- Change the parent to return a clean error if the child
doesn't write anything instead of an `assert!`
- Check the exit code of the child
Signed-off-by: Colin Walters <[email protected]>
I have a machine where #919 doesn't seem to work as intended
It's basically just an 4.15.2 SNO
Without
-v /var/lib/containers/storage:/var/lib/containers/storage
:With
-v /var/lib/containers/storage:/var/lib/containers/storage
it worksThe text was updated successfully, but these errors were encountered: