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 am probably filing this issue in the wrong place, but I need pointers and I would appreciate any help.
The problem:
docker run --rm julia:1.9.1-bookworm julia --version
ERROR: Unable to load dependent library /usr/local/julia/bin/../lib/julia/libopenlibm.so
Message:/usr/local/julia/bin/../lib/julia/libopenlibm.so: cannot enable executable stack as shared object requires: Permission denied
Similarly:
docker run --rm julia:1.8.5-bullseye julia --version
julia: error while loading shared libraries: libjulia.so.1: cannot enable executable stack as shared object requires: Permission denied
No earlier than 3 weeks ago, the 1.8.5-bullseye image worked fine. I have updated the host system (openSUSE microOS) multiple times since then. The issue affects Docker, Podman and Buildah (build command). EDIT: ..and Apptainer.
Interestingly, an Alpine-based image still works fine:
docker run --rm julia:1.9.1-alpine3.18 julia --version
julia version 1.9.1
I do not have issues on another OS (Ubuntu:20.04), same Docker version (24.0.2). The kernels are fairly different though:
Another difference I am aware of is nvidia-container-toolkit installed on the microOS system only.
Clearly the issue comes from a common dependency of Docker, Podman and Buildah. EDIT2: Or a new SELinux rule?
I am still confused as to why only Debian-based Julia images are affected. Debian-based Python and Rust images work fine, for example.
Has anyone hit a similar problem on another OS? Should I report this to the openSUSE community?
The text was updated successfully, but these errors were encountered:
You can continue to use the *-bullseye images since for julia, we support and build images for the two latest stable releases of each distribution, so Debian Bookworm and Bullseye and Alpine 3.18 and 3.17.
Thanks for the pointer. *-bullseye images did not work, though.
I have found a "fix" that consists in running sudo semanage boolean --modify --on selinuxuser_execstack on the host. Of course, I would prefer not to relax host security, nor suggest anyone to do so.
I guess this is an SELinux denial then? That's not something we can really fix in the image, and I'm not familiar enough with SELinux to suggest a more secure way to bypass this than disabling it as you've done, unfortunately. 😞
Uh oh!
There was an error while loading. Please reload this page.
I am probably filing this issue in the wrong place, but I need pointers and I would appreciate any help.
The problem:
Similarly:
No earlier than 3 weeks ago, the 1.8.5-bullseye image worked fine. I have updated the host system (openSUSE microOS) multiple times since then. The issue affects Docker, Podman and Buildah (build command). EDIT: ..and Apptainer.
Interestingly, an Alpine-based image still works fine:
I do not have issues on another OS (Ubuntu:20.04), same Docker version (24.0.2). The kernels are fairly different though:
Another difference I am aware of is nvidia-container-toolkit installed on the microOS system only.
Clearly the issue comes from a common dependency of Docker, Podman and Buildah. EDIT2: Or a new SELinux rule?
I am still confused as to why only Debian-based Julia images are affected. Debian-based Python and Rust images work fine, for example.
Has anyone hit a similar problem on another OS? Should I report this to the openSUSE community?
The text was updated successfully, but these errors were encountered: