Error: /etc/*release "no such file or directory"
See original GitHub issueError
Run actions/checkout@v2
/usr/bin/docker exec 432276a4e63948fd1ce317e06c553d8b59da3899e0254e9381f32d34cf40b653 sh -c "cat /etc/*release | grep ^ID"
OCI runtime exec failed: exec failed: container_linux.go:349: starting container process caused "no such file or directory": unknown
Description
checkout is not able to find the /etc/*release file for some reason. A previous issue asserted it had to do with being alpine
but i have tested the alpine/git
container that worked in the exact same context:
$ docker run -it --rm drewmullen/lambda-build-python:0.1 -c 'cat /etc/*release | grep ^ID'
ID=alpine
$ docker run -it --rm drewmullen/lambda-build-python:0.1 -c '/bin/ls -l /etc/os-release'
-rw-r--r-- 1 root root 10 Jan 1 1970 /etc/os-release
one thing to note is that this container was built by a nix expression so its quite bare. perhaps there are some other requirements that yall could point to that i could be missing?
Example failure: https://github.com/drewmullen/actions-playground/runs/998812222?check_suite_focus=true Example workflow:
name: test checkout on diff versions
on:
issue_comment:
types: [created]
jobs:
build:
if: >
startsWith(github.event.comment.body, 'build')
&& startsWith(github.event.issue.pull_request.url, 'https://')
runs-on: ubuntu-latest
container:
image: drewmullen/lambda-build-python:0.1
steps:
- name: 'Code Checkout'
uses: actions/checkout@v2
Issue Analytics
- State:
- Created 3 years ago
- Reactions:27
- Comments:41
Top Results From Across the Web
How to know which Linux Distribution I'm using? - Super User
I already tried $ cat /etc/*release cat: /etc/*release: No such file or directory Running the mensioned script gives a result simalr to uname...
Read more >no such file or directory" when trying to start Cluster Service in ...
When trying to start ICS in EDC 10.5., the startup fails with the below error : [InfaClusterServiceException_00017] Unsupported OS current ...
Read more >Getting results plus no file or directory with docker run command
Your local shell sees /etc/*release* and replaces it with the set of matching files present on your host system; then.
Read more >1766754 – /usr/lib/os-release doesn't exist ... - Red Hat Bugzilla
Summary: /usr/lib/os-release doesn't exist and /etc/os-release is not a ... I had briefly discussed this with sgallagh on IRC before filing this bug....
Read more >cat: /etc/lsb-release: No such file or directory
Hello I just upgarded a server (SuSE Linux 9.2) to Webmin 1.590. It seems to work ok but it gave multiple errors: cat:...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Yesterday I stumbled across this error using a BusyBox container and found this issue, today I took some time to debug it.
The reason for this is that GitHub Actions are written in JavaScript, so in order for an action to run inside a container, Node.js must be present, so the runner copies a Node.js build into the container.
The problem is that this build may not be compatible with the container. In my case, BusyBox doesn’t have the required shared libraries.
My armchair suggestion is that the Node.js build should be completely static to avoid these situations, but perhaps this has other disadvantages which make it impractical.
I’ve done a quick experiment that allows the action to run inside BusyBox, but I warn that no one under any circumstances should use it as a workaround.
test-with-lib-mount log
test-without-lib-mount log
What is happening: when a docker container is used the action runner adds a volume mount for the
/__e/
directory. When running an ‘actions’ task that usesnode
it will use something like:/__e/node16/bin/node ....
The problem: this only works if the architecture on the host-runner is the same as the architecture in the container. If the host is x86_64 (64-bit) and you try to run a container with i386 (32-bit) then you’re out of luck. The
node
binaries in/__e
are not suitable for that so they fail. A possible similar problem [but I did not fully verify that]: if the container is not using glibc as libc library but another one (for examplemusl
which is used on Alpine) then you might be out of luck. Running an Alpine container should be possible tho since that is special cased in the actions runner.Relevant code links:
What can be done to check if you’re running into the same issue: extend the workflow and add this as an extra step:
It will try to call
--version
on everynode
binary it can find in/__e/
. Very likely none of them are working (if they were working you wouldn’t be reading this…) due to different architecture/different libc.The bad news: the
/__e/
path appears to be hard-coded and impossible to overrule… Installingnode
in the container is - usually - not a problem but it doesn’t make the problem go away since therunner
callsnode
that is installed in/__e/
.The only way this can ever be fixed is if https://github.com/actions/runner is updated… https://github.com/actions/runner/issues/1011 was linked earlier in this ticket but it’s not 100% related… (~so I will likely create a new issue in that project~ see https://github.com/actions/runner/issues/2115)