Closed chrislowth closed 2 years ago
As per Alpine 3.14.0 Release Notes, the easiest way to fix this is to upgrade Docker to version 20.10.0 or later.
Looks like this was introduced in the last 15 days. The builds from 3 months ago seem to work
I encountered the same error as you when compiling nginx.
Then I switched to version alpine:3.12 、alpine:3.13,Found that both are OK!
// Omit irrelevant code
RUN \
addgroup -S www && adduser www -D -S -s /bin/sh -G www \
&& wget -P /home/soft https://github.com/vozlt/nginx-module-vts/archive/v0.1.18.tar.gz \
&& wget -P /home/soft http://nginx.org/download/nginx-1.21.1.tar.gz \
&& wget -P /home/soft https://ftp.pcre.org/pub/pcre/pcre-8.44.tar.gz \
&& cd /home/soft && tar -zxf nginx-1.21.1.tar.gz && tar -zxf v0.1.18.tar.gz && tar -zxf pcre-8.44.tar.gz \
&& cd /home/soft/nginx-1.21.1 \
&& ./configure --user=www --group=www --prefix=/usr/local/nginx --with-http_stub_status_module --with-http_ssl_module --with-http_v2_module --with-http_gzip_static_module --with-stream --with-http_sub_module --with-pcre=/home/soft/pcre-8.44 --add-module=/home/soft/nginx-module-vts-0.1.18 \
&& make && make install \
// Omit irrelevant code
The error is as follows:
make -f objs/Makefile
make: make: Operation not permitted
make: *** [Makefile:10: build] Error 127
Confirming that this is failing.
Docker 20.10.5 Compose 1.28.5
Gist: https://gist.github.com/jufemaiz/a5512eb7f87a0f33f512b806dec49e5a
Related: https://github.com/docker-library/golang/issues/378
Now for the fun part.
Docker 20.10.6 and 20.10.7 both work.
As release notes said update of docker required https://wiki.alpinelinux.org/wiki/Release_Notes_for_Alpine_3.14.0#faccessat2
As release notes said update of docker required https://wiki.alpinelinux.org/wiki/Release_Notes_for_Alpine_3.14.0#faccessat2
Sure, but it also says:
Docker 20.10.0 (which contains moby commit a181391) or greater
Which is incorrect. Docker 20.10.5 is incompatible.
As release notes said update of docker required https://wiki.alpinelinux.org/wiki/Release_Notes_for_Alpine_3.14.0#faccessat2
Sure, but it also says:
Docker 20.10.0 (which contains moby commit a181391) or greater
Which is incorrect. Docker 20.10.5 is incompatible.
you cannot stop reading nine words in. AND is the very next word, in all caps. for those unfortunately living with dyslexia, i have now set the already all-caps AND in additional bold and italic font.
Suggest toning down the antagonism and the use of medical conditions as slurs @Hello71.
Looks like I failed to add I'm using the Docker for Mac solution. Ergo any attempt to validate the libseccomp version and compatibility of the host is destined for failure as far as I can tell for non-linux solutions. As point two notes, the existence of Docker for Mac or Windows as a solution is known, so surely there's a reasonable expectation that the version of Docker Desktop recommended would have been validated.
Cheers for the contribution to the release notes.
Suggest toning down the antagonism and the use of medical conditions as slurs @Hello71.
it is not i who started any "antagonism".
Docker 20.10.0 (which contains moby commit a181391) or greater
Which is incorrect. Docker 20.10.5 is incompatible.
i generously assumed that you accidentally misread the documentation instead of gratuitously insulting the release notes that i spent several hours writing and revising to be comprehensive and clear.
i suggest you spend 2.5 minutes (244 words times 100 wpm for "remedial students" on advanced material) reading it; in all likelihood, that is less time than you've spent cherry-picking fragments of it and unnecessarily downgrading and upgrading Docker.
with that in mind, you have apparently still not read the release notes, since you say:
As point two notes, the existence of Docker for Mac or Windows as a solution is known, so surely there's a reasonable expectation that the version of Docker Desktop recommended would have been validated.
it was validated; stop insulting my work. the Alpine Linux 3.14 release notes say:
if using Docker Desktop for Windows or Mac, this is part of Docker Desktop 3.3.0
when using Docker Desktop, you cannot cite only the Docker Engine version number. you also cannot stop reading fourteen words in and shrug "well i'm using docker desktop so wHy iSNt iT WorKInG". as explained in both the Alpine and Docker Desktop release notes, newer versions of Docker Desktop contain newer Docker Engine, but also newer runc:
Docker Desktop 3.2.1: Docker Engine 20.10.5 Docker Desktop 3.3.0: runc v1.0.0-rc93 Docker Desktop 3.3.2: Docker Engine 20.10.6
and here, we return to the Alpine Linux 3.14 release notes, which says that Docker Desktop 3.3.0 contains runc v1.0.0-rc93, which satisfies the faccessat2 requirement for Alpine Linux 3.14.
this was already pointed out to you at https://github.com/docker-library/golang/issues/378 (quote in full, emphasis added):
Yep, as noted in docker-library/php#1177, this is something related to the containerization combined with newer musl. If you're not on the latest release of Docker, libseccomp, and runc, I'd suggest starting with an update to all of those.
if, after fully reading the Alpine release notes, anybody is still experiencing this issue, please post:
docker version
(not docker --version
) and docker info
. if you don't have access to the Docker host, then your provider name and relevant information (e.g. advertised VM configuration).to avoid cluttering the issue, please use <details>
element for big output, e.g. https://gist.github.com/ericclemmons/b146fe5da72ca1f706b2ef72a20ac39d.
i appreciate any information that can help improve the usability and reliability of Alpine Linux, and am willing to assist (for free!) in resolving issues. i do not appreciate wasting volunteer support time and propagating misinformation instead of spending two minutes to properly read the documentation. if you don't want to read the documentation, that's fine (although your loss), but don't subsequently go around complaining that nothing works properly and you have no idea why.
@Hello71 I run into this problem too. Here is my configuration to reproduce the issue.
As far as I can tell, my system meets the minimum requirements mentioned in the Alpine 3.14 release notes.
The command scmp_sys_resolver faccessat2
returns 439
both on the host and within the container.
@mmachatschek thank you for providing the information. you're not using any sort of nested Docker/dind? it also seems that you've enabled buildkit somewhere. can you try overriding it with DOCKER_BUILDKIT=0 docker build -f Dockerfile .
?
@Hello71 Executing docker build without buildkit didn't work for me so I reinstalled docker. After reinstalling I was able to execute docker build issues.
Before reinstalling I turned of the experimental mode with the same result.
Now I installed docker with rootless mode and it started working with the 3.14 alpine release. The difference in the docker info output is that the apparmour security option is gone (I don't know if apparmour is not installed with rootless mode).
I wonder if it would make more sense to ask docker community for help fixing this. The bug is in docker and libseccomp and is triggered by any use of faccess2(2)
regardless of distro.
I suggest that we close this issue unless there are any specific ideas what we can do to fix it on the Alpine side.
Just on the off chance, someone has a similar situation like me: I also experienced this issue, when Docker (on linux) was latest version, and libseccomp and scmp_sys_resolver faccessat2
returned 439
. In my case the issue was that I had a rogue very old runc in /usr/local/bin that was used instead of the correct one in /usr/bin. Once I deleted it, it started working.
On this note, the instructions on that wiki seem inaccurate, it's not "at least one of the following". runc had to be the correct version to work. Even with the up-to-date docker it failed with an older runc.
I use Alpine with version 3.15.4,also met this problem。But when I use docker desktop which docker version is 20.10.14,this problem is not reproduced。so,you can try this method。
Okay folks, Docker 24.0.2, runc 1.1.7, libseccomp 2.5.4 ... so this should pass, right?
Alpine images: 3.17, 3.18
Except, it doesn't: doas throws up with "doas: Operation not permitted". And yes, the syscall is there. How to deal with this?
"make" reports "/bin/sh: Operation not permitted".
To reproduce ...
This works with alpine 3.13.4 ...