checkout: Error: /etc/*release "no such file or directory"
Error
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
About this issue
- Original URL
- State: open
- Created 4 years ago
- Reactions: 34
- Comments: 45
Commits related to this issue
- Support for using this as `container:` with GitHub Actions Fixes https://github.com/actions/checkout/issues/334 — committed to teamniteo/nix-docker-base by zupo 4 years ago
- TST: Try checkout v1, see actions/checkout#334 [ci skip] — committed to pllim/astropy by pllim 4 years ago
- TST: Try checkout v1, see actions/checkout#334 [ci skip] — committed to namurphy/astropy by pllim 4 years ago
- TST: Try checkout v1, see actions/checkout#334 [ci skip] — committed to namurphy/astropy by pllim 4 years ago
- test.yaml: try checkout@v1 See https://github.com/actions/checkout/issues/334 — committed to mwilck/wft by mwilck 3 years ago
- github 32 bit workflow: use separate workflow and checkout@v1 See https://github.com/actions/checkout/issues/334 — committed to mwilck/minivent by mwilck 3 years ago
- github 32 bit workflow: use separate workflow and checkout@v1 See https://github.com/actions/checkout/issues/334 We must use upload/download@v1, too. — committed to mwilck/minivent by mwilck 3 years ago
- CI: actions/checkout doesn't currently work on 32 bit platforms (https://github.com/actions/checkout/issues/334) — committed to pauldmccarthy/indexed_gzip by pauldmccarthy 3 years ago
- [CI] Use checkout@v1. Upstream issues: actions/runner#1101 and actions/checkout#334 Signed-off-by: hydai <hydai@secondstate.io> — committed to WasmEdge/WasmEdge by hydai 3 years ago
- Reverted back to checkoutv1 on 32 bit, see https://github.com/actions/checkout/issues/334 — committed to RickdeJager/stegseek by RickdeJager 3 years ago
- Using v1 for actions checkout for all workflows Long outstanding issue that github refuses to address with the requirement of the v2 action parse "/etc/os_release". For more information see: https://... — committed to Nebulaworks/nix-garage by sarcasticadmin 2 years ago
- Using v1 for actions checkout for all workflows Long outstanding issue that github refuses to address with the requirement of the v2 action parse "/etc/os_release". For more information see: https://... — committed to Nebulaworks/nix-garage by sarcasticadmin 2 years ago
- Using v1 for actions checkout for all workflows Long outstanding issue that github refuses to address with the requirement of the v2 action parse "/etc/os_release". For more information see: https://... — committed to Nebulaworks/nix-garage by sarcasticadmin 2 years ago
- https://github.com/actions/checkout/issues/334#issuecomment-727146723 — committed to exarkun/gridsync by exarkun 2 years ago
- go back to v1 checkout action https://github.com/actions/checkout/issues/334 — committed to louwers/maplibre-native by louwers a year ago
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 usesnodeit 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
nodebinaries in/__eare 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 examplemuslwhich 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
--versionon everynodebinary 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… Installingnodein the container is - usually - not a problem but it doesn’t make the problem go away since therunnercallsnodethat 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)
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
Still a problem with v3
After all, this PR https://github.com/actions/checkout/pull/70 turned this action into an action called “JavaScript Actions”, so we can use v1 to checkout the code without any extra hacks.
Nice, I also looked into this again and figured it out in Nix’s case as well, see https://github.com/niteoweb/nix-docker-base/commit/0a5ceed0441a32b25a33b6904a47e007231b58c6 for the fix for nix-docker-base In short:
/lib64/ld-linux-x86-64.so.2as the dynamic linker, so make sure that exists. For Nix, this should be${pkgs.glibc}/lib/ld-linux-x86-64.so.2libstdc++.so.6, which by default isn’t found, because Nix’s glibc linker doesn’t look into any/lib, etc. directories for finding libraries. The easiest way to make it find that library is by settingLD_LIBRARY_PATHto${pkgs.stdenv.cc.cc.lib}/lib.What I used for debugging:
nodebinary that GitHub Actions use:externalsfolder mounted like the runner does:fileto inspect the dynamic linker path:lddon the binary to see any missing libraries: Here you can also see all the dynamic libraries the binary depends on. See https://man7.org/linux/man-pages/man8/ld.so.8.html for how these libraries are resolved and more info on how linking works. SettingLD_TRACE_LOADED_OBJECTS=1,LD_DEBUG=allandLD_VERBOSE=1are useful for debugging linking.Hello, Do we have any progress on that issue ? Or a workaround to use v3 with any containers ? At the moment, I’m using v1 as a workaround. However, this workaround cause me an issue when mixing v1 and v3 usage inside a workflow.
Thanks!
It seems that a lot of votes are needed to solve this problem in the upstream. Please check this out if you are interested in that: https://github.com/actions/runner/issues/1011
I was able to reproduce locally using only docker (without anything related to github action). At some point,
docker exec container_id sh -c "cat /etc/*release | grep ^ID"start to fail and never work anymore. As of now, I still don’t know what triggers this failure.However I’m curious of why the post script of the checkout action needs to know the ID of the docker image?
I also have this problem with v2, v1 works fine
Having this issue. Using v1 got me past it.
I’m getting similar error when running
ARMarchitecture container on self-hosted runner withqemu:Here is the run https://github.com/cppfw/myci/runs/1583234188?check_suite_focus=true
Do I understand right that the
checkoutaction, which is a javascript action, in this case is run inside of the container and since there is nonodejspresent in the container it can’t run the action?I tried installing
nodejsinside of the container before performingactions/checkout@v2but it did not help, same error.I wanted to use
i386/ubuntu:bionicas the container and I reach the same issue.Yet
/usr/bin/docker exec 43...53 sh -c "cat /etc/*release | grep ^ID"works locally with that image.Using v2.3.2 makes no difference.
Thanks for that info, helped me understand the error more 😃.
Since some people in this thread also mentioned the
summerwind/actions-controller, I think the actual error message, in that case, is strongly related to the/__edirectory not properly being mounted when you do DinD. In case your workflow hascontainer: <xyz>check that container when your build is running and specifically the/__emount point cc @https://github.com/shussonI’m bumping into the same problem. Using https://github.com/niteoweb/nix-docker-base as the docker image. Works fine locally, on CircleCI and on Heroku, does not work on GitHub Actions.