-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
Error: /etc/*release "no such file or directory" #334
Comments
We're getting the same issue but on a self-hosted runner which was set up following https://github.com/summerwind/actions-runner-controller. The image contains a subset of packages from the GitHub runners, https://github.com/summerwind/actions-runner-controller#softeware-installed-in-the-runner-image. |
@drewmullen This should be resolved in the latest version of actions/checkout. Try: |
@berndvdveen unfortunately not :(
workflow: https://github.com/drewmullen/actions-playground/blob/master/.github/workflows/step_container.yml |
I'm having the same issue with:
Then Post Clone repository step fails:
Note that for an unknown reason, if I remove |
I was able to reproduce locally using only docker (without anything related to github action). However I'm curious of why the post script of the checkout action needs to know the ID of the docker image? |
I'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. |
I wanted to use Yet Using v2.3.2 makes no difference. |
Same here with 2.3.3. |
I did a bit of investigating, and I'm now fairly certain that the A thing I tried that didn't work is something like
This creates a bunch of common directories. No luck though, still the same failure I also tried running the container with In addition, I suspect this has nothing to do with the checkout action even. It's likely a problem with GitHub Actions themselves. Which makes it pretty hard to debug since it's closed source.. |
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. name: 'actions/checkout#334 test'
on:
push:
branches: ['*']
jobs:
test-with-lib-mount:
runs-on: 'ubuntu-latest'
container:
image: 'docker.io/busybox:glibc'
volumes:
- '/lib/x86_64-linux-gnu/libdl.so.2:/lib/libdl.so.2'
- '/lib/x86_64-linux-gnu/libgcc_s.so.1:/lib/libgcc_s.so.1'
- '/usr/lib/x86_64-linux-gnu/libstdc++.so.6:/lib/libstdc++.so.6'
steps:
- run: 'printf "ID=debian\n" > /etc/os-release'
- uses: 'actions/checkout@main'
- run: '/__e/node12/bin/node --version'
test-without-lib-mount:
runs-on: 'ubuntu-latest'
container:
image: 'docker.io/busybox:glibc'
steps:
- run: 'printf "ID=debian\n" > /etc/os-release'
- uses: 'actions/checkout@main'
- run: '/__e/node12/bin/node --version' test-with-lib-mount log
test-without-lib-mount log
|
Nice, I also looked into this again and figured it out in Nix's case as well, see teamniteo/nix-docker-base@0a5ceed for the fix for nix-docker-base
What I used for debugging:
|
After all, this PR #70 turned this action into an action called "JavaScript Actions", so we can use v1 to checkout the code without any extra hacks. |
ping: @ericsciple |
Hey @smorimoto , using checkout@v1 works for me! I know this is a question is related to an entirely different action and repo/project, but I hoped that you might have an idea: I am having the exact same issue/error with
|
@erikkn Both |
Thanks for that info, helped me understand the error more :). Since some people in this thread also mentioned the |
I'm getting similar error when running
Here is the run https://github.com/cppfw/myci/runs/1583234188?check_suite_focus=true Do I understand right that the I tried installing |
@erikkn did you manage to configure the actions properly? |
@ItsReddi yeah that sounds familiar. I got this error while using the summerwind/actions-runner-controler, so my troubleshooting was pretty much limited to that project. I created an upstream PR in that project, which got meged and confirmed to work now. |
Debug of checkout@v2, cache@v2/v1 same error:
|
Here seems to be notable errors:
|
Just had this error, but my issue was that I was trying to do it in Docker-From-Docker (DooD). In order to run it in DooD host has to have the runner files. Hope it helps someone. |
I am experiencing the same issue. With ECS(Ec2 autoscaling group) self hosted runner. When running in DIND, respectively when executing a build with container flag
Error:
Is there any setting we can hardcode in the workflow -> container block to bypass this ? |
Running actions inside a container based on the nix base image, following workaround could others find helpfull: steps:
- name: Apply Workaround for Dynamically Linked NodeJS
run: |
# Hacks to get the mounted nodejs by github actions work as its dynamically linked
# https://github.com/actions/checkout/issues/334#issuecomment-716068696
nix build --no-link --max-jobs 2 --cores 0 'nixpkgs#stdenv.cc.cc.lib' 'nixpkgs#glibc'
echo "LD_LIBRARY_PATH=$(nix path-info 'nixpkgs#stdenv.cc.cc.lib')/lib" >> "$GITHUB_ENV"
ln -s "$(nix path-info 'nixpkgs#glibc' --recursive | grep glibc | grep -v bin)/lib64" /lib64 It makes no sense that the runner uses volume mounts to add dynamically linked stuff into the container. |
Hello, what is the current workaround for this issue ? |
#495) The "[run tests](https://github.com/MIT-LCP/wfdb-python/blob/main/.github/workflows/run-tests.yml)" GitHub workflow is raising [several warnings](https://github.com/MIT-LCP/wfdb-python/actions/runs/9783079800) about deprecated actions: e.g. > `[build (ubuntu-latest, 3.9)](https://github.com/MIT-LCP/wfdb-python/actions/runs/9783079800/job/27011340622) The following actions uses Node.js version which is deprecated and will be forced to run on node20: actions/checkout@v2, actions/setup-python@v2. For more info: https://github.blog/changelog/2024-03-07-github-actions-all-actions-will-run-on-node20-instead-of-node16-by-default/[build (ubuntu-latest, 3.9)](https://github.com/MIT-LCP/wfdb-python/actions/runs/9783079800/job/27011340622) The following actions uses Node.js version which is deprecated and will be forced to run on node20: actions/checkout@v2, actions/setup-python@v2. For more info: https://github.blog/changelog/2024-03-07-github-actions-all-actions-will-run-on-node20-instead-of-node16-by-default/` This pull request updates the actions to the latest versions: - actions/checkout@v2 -> actions/checkout@v3 - actions/setup-python@v2 -> actions/setup-python@v4 Note there is one outdated action that will need addressing at some point. As of today, the issue does not appear to have been addressed: actions/checkout#334 ``` # Note: "actions/checkout@v2" requires libstdc++6:amd64 to be # installed in the container. To keep things simple, use # "actions/checkout@v1" instead. # actions/checkout#334 ```
I had a similar problem with
This occurs because node is missing some required 64-bit libraries.
This step must be runed before other steps. |
According to actions/checkout#334 (comment), which is aboute a different but related problem, some 64-bit libraries are missing that get keep the (it seems, existing and already mapped) Node.js outside the container from being run, and installing Node.js in the container with `apt-get` installs the necessary dependencies, allowing the (existing) Node.js to be used. Although the error is reported differently (here, the error does not say anything about `/etc/*release`, the effect where it looks like the `node` binary does not run but actually something *it* tries to run does not run, seems to be the same. So maybe this will help.
This is a workaround for a problem that is the same or similar to actions/checkout#334: Run actions/checkout@v4 /usr/bin/docker exec a7f94cb30b99bd1ee851270fad4768421eddecd7e8fa674f56c4f2d2d64210b6 sh -c "cat /etc/*release | grep ^ID" exec /__e/node20/bin/node: no such file or directory I had not originally noticed the `cat /etc/*release` part of that output, and had surmised that this was a subtly different problem, but it looks like it's probably exactly the same. The workaround in actions/checkout#334 (comment) is applied in this commit and seems to be working. As noted there, the absence of some 64-bit libraries in 32-bit containers prevents the (existing and already mapped) 64-bit Node.js outside the container from being run, and installing 64-bit Node.js in the container via `apt-get` (even though, in this case, it is a different version) installs the needed dependencies, letting the (existing) Node.js run. (Other problems, related to `safe.directory` protections as well as tests that are known to fail due to assertions about the size of data structures that implicitly assume 64-bit targets, do still prevent the job from succeeding. But `actions/checkout@v4`, which was failing before, seems to be working, as do the other actions.)
Installing `nodejs:amd64` in a 32-bit container to work around actions/checkout#334 works by causing 64-bit libraries the external mapped `node20` needs (even though `nodejs:amd64` in Debian is Node 18), as described in actions/checkout#334 (comment). But this installed more packages than are needed. It turns out that, at least with this image, the only libraries the container is missing are the 32-bit libstdc++ and its dependencies. It is therefore sufficient to install the `libstdc++6:amd64` package. This commit makes that change, squashing a few investigatory steps that led to it (#5). * See if libssl3:amd64 is all we need * Temporarily omit even libssl3:amd64 With only `libssl3:amd64` and its dependencies, `actions/checkout` did fail, but with a different error than before, showing a clear error about a missing library, `libstdc++`. /usr/bin/docker exec c1e55a75713e2c4fd08241fae9f4fecbe3cbb179be45174b3138390a1238090e sh -c "cat /etc/*release | grep ^ID" /__e/node20/bin/node: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory Before trying adding that, I want to check that enabling `amd64` in `dpkg` has the expected *no effect* on the error messages, compared to not enabling it. * Install libstdc++6:amd64 in the container This does not add back libssl3:amd64 yet, in case it is not needed, though I expect that it will be needed.
Installing `nodejs:amd64` in a 32-bit container to work around actions/checkout#334 works by causing 64-bit libraries the external mapped `node20` needs (even though `nodejs:amd64` in Debian is Node 18), as described in actions/checkout#334 (comment). But this installed more packages than are needed. It turns out that, at least with this image, the only libraries the container is missing are the 32-bit libstdc++ and its dependencies. It is therefore sufficient to install the `libstdc++6:amd64` package. This commit makes that change, squashing a few investigatory steps that led to it (#5). * See if libssl3:amd64 is all we need * Temporarily omit even libssl3:amd64 With only `libssl3:amd64` and its dependencies, `actions/checkout` did fail, but with a different error than before, showing a clear error about a missing library, `libstdc++`. /usr/bin/docker exec c1e55a75713e2c4fd08241fae9f4fecbe3cbb179be45174b3138390a1238090e sh -c "cat /etc/*release | grep ^ID" /__e/node20/bin/node: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory Before trying adding that, I want to check that enabling `amd64` in `dpkg` has the expected *no effect* on the error messages, compared to not enabling it. * Install libstdc++6:amd64 in the container This does not add back libssl3:amd64 yet, in case it is not needed, though I expect that it will be needed.
This is a workaround for a problem that is the same or similar to actions/checkout#334: Run actions/checkout@v4 /usr/bin/docker exec a7f94cb30b99bd1ee851270fad4768421eddecd7e8fa674f56c4f2d2d64210b6 sh -c "cat /etc/*release | grep ^ID" exec /__e/node20/bin/node: no such file or directory I had not originally noticed the `cat /etc/*release` part of that output, and had surmised that this was a subtly different problem, but it looks like it's probably exactly the same. The workaround in actions/checkout#334 (comment) is applied in this commit and seems to be working. As noted there, the absence of some 64-bit libraries in 32-bit containers prevents the (existing and already mapped) 64-bit Node.js outside the container from being run, and installing 64-bit Node.js in the container via `apt-get` (even though, in this case, it is a different version) installs the needed dependencies, letting the (existing) Node.js run. (Other problems, related to `safe.directory` protections as well as tests that are known to fail due to assertions about the size of data structures that implicitly assume 64-bit targets, do still prevent the job from succeeding. But `actions/checkout@v4`, which was failing before, seems to be working, as do the other actions.)
Installing `nodejs:amd64` in a 32-bit container to work around actions/checkout#334 works by causing 64-bit libraries the external mapped `node20` needs (even though `nodejs:amd64` in Debian is Node 18), as described in actions/checkout#334 (comment). But this installed more packages than are needed. It turns out that, at least with this image, the only libraries the container is missing are the 32-bit libstdc++ and its dependencies. It is therefore sufficient to install the `libstdc++6:amd64` package. This commit makes that change, squashing a few investigatory steps that led to it (#5). * See if libssl3:amd64 is all we need * Temporarily omit even libssl3:amd64 With only `libssl3:amd64` and its dependencies, `actions/checkout` did fail, but with a different error than before, showing a clear error about a missing library, `libstdc++`. /usr/bin/docker exec c1e55a75713e2c4fd08241fae9f4fecbe3cbb179be45174b3138390a1238090e sh -c "cat /etc/*release | grep ^ID" /__e/node20/bin/node: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory Before trying adding that, I want to check that enabling `amd64` in `dpkg` has the expected *no effect* on the error messages, compared to not enabling it. * Install libstdc++6:amd64 in the container This does not add back libssl3:amd64 yet, in case it is not needed, though I expect that it will be needed.
This is a workaround for a problem that is the same or similar to actions/checkout#334: Run actions/checkout@v4 /usr/bin/docker exec a7f94cb30b99bd1ee851270fad4768421eddecd7e8fa674f56c4f2d2d64210b6 sh -c "cat /etc/*release | grep ^ID" exec /__e/node20/bin/node: no such file or directory I had not originally noticed the `cat /etc/*release` part of that output, and had surmised that this was a subtly different problem, but it looks like it's probably exactly the same. The workaround in actions/checkout#334 (comment) is applied in this commit and seems to be working. As noted there, the absence of some 64-bit libraries in 32-bit containers prevents the (existing and already mapped) 64-bit Node.js outside the container from being run, and installing 64-bit Node.js in the container via `apt-get` (even though, in this case, it is a different version) installs the needed dependencies, letting the (existing) Node.js run. (Other problems, related to `safe.directory` protections as well as tests that are known to fail due to assertions about the size of data structures that implicitly assume 64-bit targets, do still prevent the job from succeeding. But `actions/checkout@v4`, which was failing before, seems to be working, as do the other actions.)
Installing `nodejs:amd64` in a 32-bit container to work around actions/checkout#334 works by causing 64-bit libraries the external mapped `node20` needs (even though `nodejs:amd64` in Debian is Node 18), as described in actions/checkout#334 (comment). But this installed more packages than are needed. It turns out that, at least with this image, the only libraries the container is missing are the 32-bit libstdc++ and its dependencies. It is therefore sufficient to install the `libstdc++6:amd64` package. This commit makes that change, squashing a few investigatory steps that led to it (#5). * See if libssl3:amd64 is all we need * Temporarily omit even libssl3:amd64 With only `libssl3:amd64` and its dependencies, `actions/checkout` did fail, but with a different error than before, showing a clear error about a missing library, `libstdc++`. /usr/bin/docker exec c1e55a75713e2c4fd08241fae9f4fecbe3cbb179be45174b3138390a1238090e sh -c "cat /etc/*release | grep ^ID" /__e/node20/bin/node: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory Before trying adding that, I want to check that enabling `amd64` in `dpkg` has the expected *no effect* on the error messages, compared to not enabling it. * Install libstdc++6:amd64 in the container This does not add back libssl3:amd64 yet, in case it is not needed, though I expect that it will be needed.
This is a workaround for a problem that is the same or similar to actions/checkout#334: Run actions/checkout@v4 /usr/bin/docker exec a7f94cb30b99bd1ee851270fad4768421eddecd7e8fa674f56c4f2d2d64210b6 sh -c "cat /etc/*release | grep ^ID" exec /__e/node20/bin/node: no such file or directory I had not originally noticed the `cat /etc/*release` part of that output, and had surmised that this was a subtly different problem, but it looks like it's probably exactly the same. The workaround in actions/checkout#334 (comment) is applied in this commit and seems to be working. As noted there, the absence of some 64-bit libraries in 32-bit containers prevents the (existing and already mapped) 64-bit Node.js outside the container from being run, and installing 64-bit Node.js in the container via `apt-get` (even though, in this case, it is a different version) installs the needed dependencies, letting the (existing) Node.js run. (Other problems, related to `safe.directory` protections as well as tests that are known to fail due to assertions about the size of data structures that implicitly assume 64-bit targets, do still prevent the job from succeeding. But `actions/checkout@v4`, which was failing before, seems to be working, as do the other actions.)
Installing `nodejs:amd64` in a 32-bit container to work around actions/checkout#334 works by causing 64-bit libraries the external mapped `node20` needs (even though `nodejs:amd64` in Debian is Node 18), as described in actions/checkout#334 (comment). But this installed more packages than are needed. It turns out that, at least with this image, the only libraries the container is missing are the 32-bit libstdc++ and its dependencies. It is therefore sufficient to install the `libstdc++6:amd64` package. This commit makes that change, squashing a few investigatory steps that led to it (#5). * See if libssl3:amd64 is all we need * Temporarily omit even libssl3:amd64 With only `libssl3:amd64` and its dependencies, `actions/checkout` did fail, but with a different error than before, showing a clear error about a missing library, `libstdc++`. /usr/bin/docker exec c1e55a75713e2c4fd08241fae9f4fecbe3cbb179be45174b3138390a1238090e sh -c "cat /etc/*release | grep ^ID" /__e/node20/bin/node: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory Before trying adding that, I want to check that enabling `amd64` in `dpkg` has the expected *no effect* on the error messages, compared to not enabling it. * Install libstdc++6:amd64 in the container This does not add back libssl3:amd64 yet, in case it is not needed, though I expect that it will be needed.
This is a workaround for a problem that is the same or similar to actions/checkout#334: Run actions/checkout@v4 /usr/bin/docker exec a7f94cb30b99bd1ee851270fad4768421eddecd7e8fa674f56c4f2d2d64210b6 sh -c "cat /etc/*release | grep ^ID" exec /__e/node20/bin/node: no such file or directory I had not originally noticed the `cat /etc/*release` part of that output, and had surmised that this was a subtly different problem, but it looks like it's probably exactly the same. The workaround in actions/checkout#334 (comment) is applied in this commit and seems to be working. As noted there, the absence of some 64-bit libraries in 32-bit containers prevents the (existing and already mapped) 64-bit Node.js outside the container from being run, and installing 64-bit Node.js in the container via `apt-get` (even though, in this case, it is a different version) installs the needed dependencies, letting the (existing) Node.js run. (Other problems, related to `safe.directory` protections as well as tests that are known to fail due to assertions about the size of data structures that implicitly assume 64-bit targets, do still prevent the job from succeeding. But `actions/checkout@v4`, which was failing before, seems to be working, as do the other actions.)
Installing `nodejs:amd64` in a 32-bit container to work around actions/checkout#334 works by causing 64-bit libraries the external mapped `node20` needs (even though `nodejs:amd64` in Debian is Node 18), as described in actions/checkout#334 (comment). But this installed more packages than are needed. It turns out that, at least with this image, the only libraries the container is missing are the 32-bit libstdc++ and its dependencies. It is therefore sufficient to install the `libstdc++6:amd64` package. This commit makes that change, squashing a few investigatory steps that led to it (#5). * See if libssl3:amd64 is all we need * Temporarily omit even libssl3:amd64 With only `libssl3:amd64` and its dependencies, `actions/checkout` did fail, but with a different error than before, showing a clear error about a missing library, `libstdc++`. /usr/bin/docker exec c1e55a75713e2c4fd08241fae9f4fecbe3cbb179be45174b3138390a1238090e sh -c "cat /etc/*release | grep ^ID" /__e/node20/bin/node: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory Before trying adding that, I want to check that enabling `amd64` in `dpkg` has the expected *no effect* on the error messages, compared to not enabling it. * Install libstdc++6:amd64 in the container This does not add back libssl3:amd64 yet, in case it is not needed, though I expect that it will be needed.
This is a workaround for a problem that is the same or similar to actions/checkout#334: Run actions/checkout@v4 /usr/bin/docker exec a7f94cb30b99bd1ee851270fad4768421eddecd7e8fa674f56c4f2d2d64210b6 sh -c "cat /etc/*release | grep ^ID" exec /__e/node20/bin/node: no such file or directory I had not originally noticed the `cat /etc/*release` part of that output, and had surmised that this was a subtly different problem, but it looks like it's probably exactly the same. The workaround in actions/checkout#334 (comment) is applied in this commit and seems to be working. As noted there, the absence of some 64-bit libraries in 32-bit containers prevents the (existing and already mapped) 64-bit Node.js outside the container from being run, and installing 64-bit Node.js in the container via `apt-get` (even though, in this case, it is a different version) installs the needed dependencies, letting the (existing) Node.js run. (Other problems, related to `safe.directory` protections as well as tests that are known to fail due to assertions about the size of data structures that implicitly assume 64-bit targets, do still prevent the job from succeeding. But `actions/checkout@v4`, which was failing before, seems to be working, as do the other actions.)
Installing `nodejs:amd64` in a 32-bit container to work around actions/checkout#334 works by causing 64-bit libraries the external mapped `node20` needs (even though `nodejs:amd64` in Debian is Node 18), as described in actions/checkout#334 (comment). But this installed more packages than are needed. It turns out that, at least with this image, the only libraries the container is missing are the 32-bit libstdc++ and its dependencies. It is therefore sufficient to install the `libstdc++6:amd64` package. This commit makes that change, squashing a few investigatory steps that led to it (#5). * See if libssl3:amd64 is all we need * Temporarily omit even libssl3:amd64 With only `libssl3:amd64` and its dependencies, `actions/checkout` did fail, but with a different error than before, showing a clear error about a missing library, `libstdc++`. /usr/bin/docker exec c1e55a75713e2c4fd08241fae9f4fecbe3cbb179be45174b3138390a1238090e sh -c "cat /etc/*release | grep ^ID" /__e/node20/bin/node: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory Before trying adding that, I want to check that enabling `amd64` in `dpkg` has the expected *no effect* on the error messages, compared to not enabling it. * Install libstdc++6:amd64 in the container This does not add back libssl3:amd64 yet, in case it is not needed, though I expect that it will be needed.
This is a workaround for a problem that is the same or similar to actions/checkout#334: Run actions/checkout@v4 /usr/bin/docker exec a7f94cb30b99bd1ee851270fad4768421eddecd7e8fa674f56c4f2d2d64210b6 sh -c "cat /etc/*release | grep ^ID" exec /__e/node20/bin/node: no such file or directory I had not originally noticed the `cat /etc/*release` part of that output, and had surmised that this was a subtly different problem, but it looks like it's probably exactly the same. The workaround in actions/checkout#334 (comment) is applied in this commit and seems to be working. As noted there, the absence of some 64-bit libraries in 32-bit containers prevents the (existing and already mapped) 64-bit Node.js outside the container from being run, and installing 64-bit Node.js in the container via `apt-get` (even though, in this case, it is a different version) installs the needed dependencies, letting the (existing) Node.js run. (Other problems, related to `safe.directory` protections as well as tests that are known to fail due to assertions about the size of data structures that implicitly assume 64-bit targets, do still prevent the job from succeeding. But `actions/checkout@v4`, which was failing before, seems to be working, as do the other actions.)
Installing `nodejs:amd64` in a 32-bit container to work around actions/checkout#334 works by causing 64-bit libraries the external mapped `node20` needs (even though `nodejs:amd64` in Debian is Node 18), as described in actions/checkout#334 (comment). But this installed more packages than are needed. It turns out that, at least with this image, the only libraries the container is missing are the 32-bit libstdc++ and its dependencies. It is therefore sufficient to install the `libstdc++6:amd64` package. This commit makes that change, squashing a few investigatory steps that led to it (#5). * See if libssl3:amd64 is all we need * Temporarily omit even libssl3:amd64 With only `libssl3:amd64` and its dependencies, `actions/checkout` did fail, but with a different error than before, showing a clear error about a missing library, `libstdc++`. /usr/bin/docker exec c1e55a75713e2c4fd08241fae9f4fecbe3cbb179be45174b3138390a1238090e sh -c "cat /etc/*release | grep ^ID" /__e/node20/bin/node: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory Before trying adding that, I want to check that enabling `amd64` in `dpkg` has the expected *no effect* on the error messages, compared to not enabling it. * Install libstdc++6:amd64 in the container This does not add back libssl3:amd64 yet, in case it is not needed, though I expect that it will be needed.
Installing `nodejs:amd64` in a 32-bit container to work around actions/checkout#334 works by causing 64-bit libraries the external mapped `node20` needs (even though `nodejs:amd64` in Debian is Node 18), as described in actions/checkout#334 (comment). But this installed more packages than are needed. It turns out that, at least with this image, the only libraries the container is missing are the 32-bit libstdc++ and its dependencies. It is therefore sufficient to install the `libstdc++6:amd64` package. This commit makes that change, squashing a few investigatory steps that led to it (#5). * See if libssl3:amd64 is all we need * Temporarily omit even libssl3:amd64 With only `libssl3:amd64` and its dependencies, `actions/checkout` did fail, but with a different error than before, showing a clear error about a missing library, `libstdc++`. /usr/bin/docker exec c1e55a75713e2c4fd08241fae9f4fecbe3cbb179be45174b3138390a1238090e sh -c "cat /etc/*release | grep ^ID" /__e/node20/bin/node: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory Before trying adding that, I want to check that enabling `amd64` in `dpkg` has the expected *no effect* on the error messages, compared to not enabling it. * Install libstdc++6:amd64 in the container This does not add back libssl3:amd64 yet, in case it is not needed, though I expect that it will be needed.
Installing `nodejs:amd64` in a 32-bit container to work around actions/checkout#334 works by causing 64-bit libraries the external mapped `node20` needs (even though `nodejs:amd64` in Debian is Node 18), as described in actions/checkout#334 (comment). But this installed more packages than are needed. It turns out that, at least with this image, the only libraries the container is missing are the 32-bit libstdc++ and its dependencies. It is therefore sufficient to install the `libstdc++6:amd64` package. This commit makes that change, squashing a few investigatory steps that led to it (#5). * See if libssl3:amd64 is all we need * Temporarily omit even libssl3:amd64 With only `libssl3:amd64` and its dependencies, `actions/checkout` did fail, but with a different error than before, showing a clear error about a missing library, `libstdc++`. /usr/bin/docker exec c1e55a75713e2c4fd08241fae9f4fecbe3cbb179be45174b3138390a1238090e sh -c "cat /etc/*release | grep ^ID" /__e/node20/bin/node: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory Before trying adding that, I want to check that enabling `amd64` in `dpkg` has the expected *no effect* on the error messages, compared to not enabling it. * Install libstdc++6:amd64 in the container This does not add back libssl3:amd64 yet, in case it is not needed, though I expect that it will be needed.
Error
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 thealpine/git
container that worked in the exact same context: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:
The text was updated successfully, but these errors were encountered: