issue creating containers due to seccomp failure (error adding seccomp filter rule for syscall clone3: permission denied: unknown, Docker 20.10.10)

Description
encountered when doing docker-compose; containerd fails to create a runtime because of seccomp failures.
 ➜ docker-compose up -d
Removing docker-bookstack_mysql_1
Recreating ec5ce780fc1b_docker-bookstack_mysql_1 ... error

ERROR: for ec5ce780fc1b_docker-bookstack_mysql_1  Cannot start service mysql: OCI runtime create failed: container_linux.go:348: starting container process caused: error adding seccomp filter rule for syscall clone3: permission denied: unknown

ERROR: for mysql  Cannot start service mysql: OCI runtime create failed: container_linux.go:348: starting container process caused: error adding seccomp filter rule for syscall clone3: permission denied: unknown
ERROR: Encountered errors while bringing up the project.

Steps to reproduce the issue

start a container, any container

Describe the results you received and expected
received: failure to start container
expected: container starts
What version of containerd are you using?
containerd containerd.io 1.4.11 5b46e404f6b9f661a205e28d59c982d3634148f8
Any other relevant information
➜ runc --version
runc version 1.0.0-rc10+dev
commit: 2c8d668eee4a5d537c47830f0dd932877442b946
spec: 1.0.2
➜ uname -a
Linux localhost.localdomain 5.14.14-300.fc35.x86_64 #1 SMP Wed Oct 20 16:14:50 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
Show configuration if it is related to CRI plugin.
No response

This looks like a docker issue due to using an out of date version of docker.

This looks like a docker issue due to using an out of date version of docker.

 ➜ dockerd -v
Docker version 20.10.10, build e2f740d

latest version AFAIK

I see the same thing on the latest containerd 1.5.7 on RHEL 7
runc did not terminate successfully: exit status 127: unknown

It has libseccomp-dev installed.

@relyt0925

runc: symbol lookup error: runc: undefined symbol: seccomp_api_get

Unrelated to OP.
It seems that your runc binary is built for libseccomp >= 2.4, and you have to get a runc binary built for RHEL 7.

@pontaoski
How did you install Docker/containerd/runc?
Docker 20.10.10 + containerd 1.4.11 is fine, but runc version 1.0.0-rc10+dev looks weird.
Maybe you have to uninstall the packages and reinstall them from https://download.docker.com/linux/fedora/35/x86_64/stable/Packages/ . (containerd.io RPM contains runc too)

I got the same error with the latest version of docker (20.10.10 build e2f740d) on ubuntu 18.04
`ERROR: for fpm_api  Cannot start service fpm_api: OCI runtime create failed: container_linux.go:348: starting container process caused "error adding seccomp filter rule for syscall clone3: permission denied": unknown
ERROR: for webpack  Cannot start service webpack: OCI runtime create failed: container_linux.go:348: starting container process caused "error adding seccomp filter rule for syscall clone3: permission denied": unknown
ERROR: for adminer  Cannot start service adminer: OCI runtime create failed: container_linux.go:348: starting container process caused "error adding seccomp filter rule for syscall clone3: permission denied": unknown
`

Same problem with ubuntu 20.04...

Same problem here.  I updated docker.io and containerd in Ubuntu 18.04 via apt yesterday afternoon.
containerd/bionic-updates 1.5.5-0ubuntu3~18.04.1 arm64 [upgradable from: 1.5.2-0ubuntu1~18.04.2]
docker.io/bionic-updates 20.10.7-0ubuntu5~18.04.2 arm64 [upgradable from: 20.10.7-0ubuntu1~18.04.1]

Downgrading docker, as suggested by @nmtsousa, fixed the issue.

Are you seeing the same if you install the docker-ce, docker-ce-cli and containerd.io packages from https://download.docker.com ?

Are you seeing the same if you install the docker-ce, docker-ce-cli and containerd.io packages from https://download.docker.com ?
(install instructions: https://docs.docker.com/engine/install/ubuntu/)

Yes, i have installed docker with the instructions of the site.
When I search for an answer i found also this blogpost

Same problem with ubuntu 20.04. My solution was to downgrade docker with: sudo apt-get install docker.io=20.10.7-0ubuntu1~20.04.2

This has fixed it for me as well on 20.04.3 LTS

Same problem with ubuntu 20.04. My solution was to downgrade docker with: sudo apt-get install docker.io=20.10.7-0ubuntu1~20.04.2

Same problem with ubuntu 20.04. My solution was to downgrade docker with: sudo apt-get install docker.io=20.10.7-0ubuntu1~20.04.2

This has fixed it for me as well on 20.04.3 LTS
Before the downgrade:
# nvidia-docker run <args> ; echo $?
78cc8d1195126d9e40b087bc36e0608b7fd03a0722c50cb642a4df14699af566
docker: Error response from daemon: failed to create shim: OCI runtime create failed: container_linux.go:380: starting container process caused: error adding seccomp filter rule for syscall clone3: permission denied: unknown.
126
Downgrade
# apt-get install docker.io=20.10.7-0ubuntu1~20.04.2
. . .
dpkg: warning: downgrading docker.io from 20.10.7-0ubuntu5~20.04.1 to 20.10.7-0ubuntu1~20.04.2
. . .
dockerd --version
Docker version 20.10.7, build 20.10.7-0ubuntu1~20.04.2
After the downgrade:
# nvidia-docker run <args> ; echo $?
9fe14058162a8bac4620f1046cf9b6c909d8c3dd03ded17158db524a957562be
0

Are you seeing the same if you install the docker-ce, docker-ce-cli and containerd.io packages from https://download.docker.com ?
(install instructions: https://docs.docker.com/engine/install/ubuntu/)

I followed the instructions on the site, removing all existing versions and installing docker-ce, docker-ce-cli and conainerd.io packages, however the problem persists.
$ docker run --rm -ti alpine docker: Error response from daemon: failed to create shim: OCI runtime create failed: container_linux.go:348: starting container process caused "error adding seccomp filter rule for syscall clone3: permission denied": unknown.
If I downgrade the docker-ce to the previous version with:
apt-get install docker-ce=5:20.10.9~3-0~ubuntu-focal
Everything works:
$ docker run --rm -ti alpine / #

Same problem with ubuntu 20.04 using docker.io but I do not have the ability to downgrade. Switching to docker-ce fixes the issue for me

I have reported this to Ubuntu as a bug in the docker.io package.

Same problem with Docker version 20.10.7, build 20.10.7-0ubuntu5~20.04.2
Fix by changing the runtime back to default
But I really need the nvidia runtime.
{
    "runtimes": {
        "nvidia": {
            "path": "nvidia-container-runtime",
            "runtimeArgs": []
        }
    },
    "default-runtime": "nvidia"
}

Is everyone on this thread using the nvidia runtime?

I'm not using the nvidia runtime. My machine is an intel CPU with its integrated graphics card.

Most likely the root cause is a nvidia-container-toolkit problem affecting 1.5.1-1 with a proposed fix in 1.6.0~rc.2-1
https://issueexplorer.com/issue/NVIDIA/nvidia-container-runtime/157

Most likely the root cause is a nvidia-container-toolkit problem affecting 1.5.1-1 with a proposed fix in 1.6.0~rc.2-1
https://issueexplorer.com/issue/NVIDIA/nvidia-container-runtime/157
It would seem there are two options for temporarily fixing it until 1.6.0 is out:
* Install nvidia-container-toolkit 1.6.0~rc.2-1 https://docs.nvidia.com/datacenter/cloud-native/container-toolkit/install-guide.html#setting-up-nvidia-container-toolkit (the experimental section); I did not test this.

* Downgrade to 20.10.7-0ubuntu1~20.04.2 - This works for me; Ubuntu have just removed the package from the distribution, but can still be found online.

Same problem here, but my docker version is: Docker version 20.10.7, build 20.10.7-0ubuntu5~20.04.2 and I still have the problem.

Is everyone on this thread using the nvidia runtime?

No i'm on a intel CPU and AMD GPU.

Is everyone on this thread using the nvidia runtime?

Not using Nvidia either.

For folks who say they're not using the nvidia runtime, could you check:
# docker info 2>/dev/null | grep Runtime
 Runtimes: io.containerd.runc.v2 io.containerd.runtime.v1.linux nvidia runc
 Default Runtime: runc

If nvidia is set as default runtime when you are using it.
# docker inspect <container name> | grep Runtime
            "Runtime": "nvidia",

If the container has the runtime nvidia then you are using it.

Also you should be able to add your device without the runtime using --gpus flag.

I changed the default runtime, it works

For folks who say they are not using the nvidia runtime, could you please check:
# docker info 2>/dev/null | grep Runtime
 Runtimes: io.containerd.runc.v2 io.containerd.runtime.v1.linux nvidia runc
 Default Runtime: runc

If nvidia is set as default runtime then it is possible all your containers are using it without you knowing.
To make sure:
# docker inspect <container name> | grep Runtime
            "Runtime": "nvidia",

This container is using the nvidia runtime.
# docker inspect <container name> | grep Runtime
            "Runtime": "runc",

This container is not using the nvidia runtime.

so apparently i am using the nvidia runtime for some containers that definitely DONT need it.
but i would rather NOT change the default to runc, since i have containers that use it.
can i restart these containers with a different runtime? ie change the settings

Updated to the latest version of docker-ce to run the test. I do not have the nvidia runtime, just runc.
# docker info 2>/dev/null | grep Runtime
Runtimes: io.containerd.runc.v2 io.containerd.runtime.v1.linux runc
Default Runtime: runc

Trying to run a container yelds:
# docker run --rm -ti alpine
docker: Error response from daemon: OCI runtime create failed: container_linux.go:348: starting container process caused "error adding seccomp filter rule for syscall clone3: permission denied": unknown.
ERRO[0000] error waiting for container: context canceled

I have to downgrade docker-ce to get it working again.

@nmtsousa
Could you provide docker info, dpkg -l | grep docker-ce, dpkg -l | grep containerd.io

# docker info
Client:
 Context:    default
 Debug Mode: false
 Plugins:
  app: Docker App (Docker Inc., v0.9.1-beta3)
  buildx: Build with BuildKit (Docker Inc., v0.6.3-docker)
  scan: Docker Scan (Docker Inc., v0.9.0)

Server:
 Containers: 0
  Running: 0
  Paused: 0
  Stopped: 0
 Images: 40
 Server Version: 20.10.10
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Cgroup Version: 1
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 io.containerd.runtime.v1.linux runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 5b46e404f6b9f661a205e28d59c982d3634148f8
 runc version: v1.0.2-0-g52b36a2
 init version: de40ad0
 Security Options:
  apparmor
  seccomp
   Profile: default
 Kernel Version: 5.4.0-90-generic
 Operating System: Ubuntu 20.04.3 LTS
 OSType: linux
 Architecture: x86_64
 CPUs: 4
 Total Memory: 31.24GiB
 Name: nsousa-ThinkPad-T470
 ID: IH6P:U3TH:O2G3:T2G2:XVCN:KPXB:5K4K:HYKK:WQKU:4EVC:PDEF:IP5H
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: false
 Insecure Registries:
  <IP_ADDRESS>/8
 Live Restore Enabled: false

WARNING: No swap limit support

# dpkg -l | grep docker-ce
ii  docker-ce                                     5:20.10.10~3-0~ubuntu-focal                 amd64        Docker: the open-source application container engine
ii  docker-ce-cli                                 5:20.10.10~3-0~ubuntu-focal                 amd64        Docker CLI: the open-source application container engine
ii  docker-ce-rootless-extras                     5:20.10.10~3-0~ubuntu-focal                 amd64        Rootless support for Docker.

# dpkg -l | grep containerd.io
ii  containerd.io                                 1.4.11-1                                    amd64        An open and reliable container runtime

I'm having a hard time finding a 20.10.7-0ubuntu1~20.04.02 deb location of docker.io to downgrade to.  Can anyone assist with a link?

@bmmiller: I changed to the docker-ce because I couldn't find the previous version of docker.io to downgrade to. For docker.ce the previous versions are available.

You can download it from here:
https://www.dropbox.com/s/keo9i6hx51p5q4b/docker.io_20.10.7-0ubuntu1~20.04.2_amd64.deb?dl=0
The checksums can still be found in the Google cache:
https://webcache.googleusercontent.com/search?q=cache:sUZBwHThu7MJ:https://packages.ubuntu.com/focal/amd64/docker.io/download+&cd=1&hl=en&ct=clnk&gl=sg
# sha1sum docker.io_20.10.7-0ubuntu1~20.04.2_amd64.deb
9996131217d5f3da77b82031048938648b5a7634  docker.io_20.10.7-0ubuntu1~20.04.2_amd64.deb
# md5sum docker.io_20.10.7-0ubuntu1~20.04.2_amd64.deb
7ab81792216a3de59bb663ae48549f7d  docker.io_20.10.7-0ubuntu1~20.04.2_amd64.deb
# sha256sum docker.io_20.10.7-0ubuntu1~20.04.2_amd64.deb
ac7daa552a0a82c91f5bb3777b47907c10bebd0f5a20f6918e56481a6bd3e1c8  docker.io_20.10.7-0ubuntu1~20.04.2_amd64.deb

@nmtsousa Research suggested to me that docker-ce wasn't the preferred package to use on Ubuntu/Debian so I wanted to stick with docker.io instead of creating an additional issue while I'm temporarily fixing this one.  Thanks though.
@danpodeanu Thanks for the link.  My local was gone.  I'm back up and running!

Keep in mind that the engine will autoupdate to the latest version so you'll have to keep that .deb file on hand.
Is there any ETA on a permanent fix from nvidia?

Keep in mind that the engine will autoupdate to the latest version so you'll have to keep that .deb file on hand. Is there any ETA on a permanent fix from nvidia?

I have noticed something Nvidia auto updates without a manual apt upgrade and it's a bit frustrating.
What is responsible for that and can it be disabled?

No ETA thus far, but it should be soon: "These will be promoted to stable in the coming days" as of 11/5, according to https://issueexplorer.com/issue/NVIDIA/nvidia-container-runtime/157
I will update this thread once I validate the fix.
In the meanwhile, if you want to temporarily disable Ubuntu's automated updates, this is how to turn them on and off. As automatic updates are generally a good idea, do not forget to turn them back on once resolved.
# dpkg-reconfigure unattended-upgrades

No ETA thus far, but it should be soon: "These will be promoted to stable in the coming days" as of 11/5, according to https://issueexplorer.com/issue/NVIDIA/nvidia-container-runtime/157
I will update this thread once I validate the fix.
In the meanwhile, if you want to temporarily disable Ubuntu's automated updates, this is how to turn them on and off. As automatic updates are generally a good idea, do not forget to turn them back on once resolved.
# dpkg-reconfigure unattended-upgrades

Thanks for that. Although, in a server situation, I'm not sure I agree with automatic updates being a good idea. Beat practice is regular updates of course, but automatic is just asking for issues....like this for example.

I believe that me and others in this thread are not using nvidia Runtime. Will there be a fix for our issue?

I believe that me and others in this thread are not using nvidia Runtime. Will there be a fix for our issue?

Unless I'm misreading, I think nearly everyone here is using nvidia actually.

No ETA thus far, but it should be soon: "These will be promoted to stable in the coming days" as of 11/5, according to https://issueexplorer.com/issue/NVIDIA/nvidia-container-runtime/157
I will update this thread once I validate the fix.
In the meanwhile, if you want to temporarily disable Ubuntu's automated updates, this is how to turn them on and off. As automatic updates are generally a good idea, do not forget to turn them back on once resolved.
# dpkg-reconfigure unattended-upgrades

Thanks for that. Although, in a server situation, I'm not sure I agree with automatic updates being a good idea. Best practice is regular updates of course, but automatic is just asking for issues....like this for example.

Agreed, provided that updates are tested and automated through different means. It feels like most of us are home users though, where automatic updates are probably a good idea. YMMV.
If anyone wants to disable them via orchestration, this is what dpkg-reconfigure unattended-upgrades does:
# cat /etc/apt/apt.conf.d/20auto-upgrades
APT::Periodic::Update-Package-Lists "0";
APT::Periodic::Unattended-Upgrade "0";

Most likely the root cause is a nvidia-container-toolkit problem affecting 1.5.1-1 with a proposed fix in 1.6.0~rc.2-1
https://issueexplorer.com/issue/NVIDIA/nvidia-container-runtime/157
It would seem there are two options for temporarily fixing it until 1.6.0 is out:
* Install nvidia-container-toolkit 1.6.0~rc.2-1 https://docs.nvidia.com/datacenter/cloud-native/container-toolkit/install-guide.html#setting-up-nvidia-container-toolkit (the experimental section); I did not test this.

* Downgrade to 20.10.7-0ubuntu1~20.04.2 - This works for me; Ubuntu have just removed the package from the distribution, but can still be found online.

Just for completeness sake. I upgraded to the experimental version which fixed the issue for me, but I had to upgrade nvidia-container-toolkit as upgrading nvidia-docker as mentioned in the issueexplorer thread didn't work for me.

I have the same problem with the latest docker.io and even on the latest docker-ce on Ubuntu 18.04 on ESXI. By the way I don´t have any nvidia things installed.
Maybe the following steps will help as long as there is no solution for this problem, I used the old version of docker.io. The official Ubuntu Repo didn´t provide it any longer, so i got it from:
http://repos.reduniv.edu.cu/UBUNTU/ubuntu/pool/universe/d/docker.io/
I installed it with:
sudo dpkg -i /path.to/docker.io_20.10.7-0ubuntu1~18.04.2_amd64.deb
Because of the ubuntu unattended-upgrades it will be changed to the most recent version as soon as possible. But I didn´t change the unattended-upgrades. I just took docker.io out of this.
I did this with:
sudo apt-mark hold docker.io
So it will not be updated till the problem is solved and is unhold with:
sudo apt-mark unhold docker.io
Maybe this helps.

I have the same problem with the latest docker.io and even on the latest docker-ce on Ubuntu 18.04 on ESXI. By the way I don´t have any nvidia things installed.
Maybe the following steps will help as long as there is no solution for this problem, I used the old version of docker.io. The official Ubuntu Repo didn´t provide it any longer, so i got it from:
http://repos.reduniv.edu.cu/UBUNTU/ubuntu/pool/universe/d/docker.io/
I installed it with:
sudo dpkg -i /path.to/docker.io_20.10.7-0ubuntu1~18.04.2_amd64.deb
Because of the ubuntu unattended-upgrades it will be changed to the most recent version as soon as possible. But I didn´t change the unattended-upgrades. I just took docker.io out of this.
I did this with:
sudo apt-mark hold docker.io
So it will not be updated till the problem is solved and is unhold with:
sudo apt-mark unhold docker.io
Maybe this helps.

What runtime are you using? Can you please post the output of docker info 2>/dev/null | grep Runtime and docker inspect <container name> | grep Runtime ?

What runtime are you using? Can you please post the output of docker info 2>/dev/null | grep Runtime and docker inspect <container name> | grep Runtime ?

# docker info 2>/dev/null | grep Runtime
   Runtimes: io.containerd.runc.v2 io.containerd.runtime.v1.linux runc
   Default Runtime: runc

# docker inspect <container name> | grep Runtime
            "Runtime": "runc",
            "CpuRealtimeRuntime": 0,

What runtime are you using? Can you please post the output of docker info 2>/dev/null | grep Runtime and docker inspect <container name> | grep Runtime ?

# docker info 2>/dev/null | grep Runtime
   Runtimes: io.containerd.runc.v2 io.containerd.runtime.v1.linux runc
   Default Runtime: runc

# docker inspect <container name> | grep Runtime
            "Runtime": "runc",
            "CpuRealtimeRuntime": 0,

The only repro I know is related to using the nvidia runtime; this might be something different.
Is this the error message you get when starting a container?
docker: Error response from daemon: failed to create shim: OCI runtime create failed: container_linux.go:380: starting container process caused: error adding seccomp filter rule for syscall clone3: permission denied: unknown.

The only repro I know is related to using the nvidia runtime; this might be something different.
Is this the error message you get when starting a container?
docker: Error response from daemon: failed to create shim: OCI runtime create failed: container_linux.go:380: starting container process caused: error adding seccomp filter rule for syscall clone3: permission denied: unknown.

I get the same error response!
docker: Error response from daemon: failed to create shim: OCI runtime create failed: container_linux.go:348: starting container process caused "error adding seccomp filter rule for syscall clone3: permission denied": unknown.

The only repro I know is related to using the nvidia runtime; this might be something different.
Is this the error message you get when starting a container?
docker: Error response from daemon: failed to create shim: OCI runtime create failed: container_linux.go:380: starting container process caused: error adding seccomp filter rule for syscall clone3: permission denied: unknown.

I get the same error response!
docker: Error response from daemon: failed to create shim: OCI runtime create failed: container_linux.go:348: starting container process caused "error adding seccomp filter rule for syscall clone3: permission denied": unknown.

Could you please post here https://bugs.launchpad.net/ubuntu/+source/docker.io/+bug/1950071, including the evidence that you are not using the nvidia runtime; let's get more info to the Ubuntu devs.

Could you please post here https://bugs.launchpad.net/ubuntu/+source/docker.io/+bug/1950071, including the evidence that you are not using the nvidia runtime; let's get more info to the Ubuntu devs.

Done!

Same error here:
docker: Error response from daemon: failed to create shim: OCI runtime create failed: container_linux.go:380: starting container process caused: error adding seccomp filter rule for syscall clone3: permission denied: unknown.
Using Ubuntu 20.04.3 LTS (Focal Fossa) with nvidia-container-runtime

Are you seeing the same if you install the docker-ce, docker-ce-cli and containerd.io packages from https://download.docker.com ?
(install instructions: https://docs.docker.com/engine/install/ubuntu/)

I followed the instructions on the site, removing all existing versions and installing docker-ce, docker-ce-cli and conainerd.io packages, however the problem persists.
$ docker run --rm -ti alpine docker: Error response from daemon: failed to create shim: OCI runtime create failed: container_linux.go:348: starting container process caused "error adding seccomp filter rule for syscall clone3: permission denied": unknown.
If I downgrade the docker-ce to the previous version with:
apt-get install docker-ce=5:20.10.9~3-0~ubuntu-focal
Everything works:
$ docker run --rm -ti alpine / #

Downgrading to the previous version "5:20.10.9~3-0~ubuntu-bionic" seems to help in my case as well with the same issue (Ubuntu 18.05 with docker-ce installation).

Most likely the root cause is a nvidia-container-toolkit problem affecting 1.5.1-1 with a proposed fix in 1.6.0~rc.2-1
https://issueexplorer.com/issue/NVIDIA/nvidia-container-runtime/157
It would seem there are two options for temporarily fixing it until 1.6.0 is out:
* Install nvidia-container-toolkit 1.6.0~rc.2-1 https://docs.nvidia.com/datacenter/cloud-native/container-toolkit/install-guide.html#setting-up-nvidia-container-toolkit (the experimental section); I did not test this.

* Downgrade to 20.10.7-0ubuntu1~20.04.2 - This works for me; Ubuntu have just removed the package from the distribution, but can still be found online.

Same problem here, but my docker version is: Docker version 20.10.7, build 20.10.7-0ubuntu5~20.04.2 and I still have the problem.
Edit: Downgrading to 20.10.7-0ubuntu1~20.04.2 solve it.

Hi @jogonba2 Could you tell me how you downgraded ? The commands and all

I can confirm that Nvidia has released upgraded packages, which appear to be working fine with docker.io 20.10.7-0ubuntu5~20.04.2. My problem has now been resolved.
# apt-get upgrade -y

docker.io/focal-updates,focal-security 20.10.7-0ubuntu5~20.04.2 amd64 [upgradable from: 20.10.7-0ubuntu1~20.04.2]
libnvidia-container-tools/bionic 1.6.0-1 amd64 [upgradable from: 1.5.1-1]
libnvidia-container1/bionic 1.6.0-1 amd64 [upgradable from: 1.5.1-1]
nvidia-container-runtime/bionic 3.6.0-1 amd64 [upgradable from: 3.5.0-1]
nvidia-container-toolkit/bionic 1.6.0-1 amd64 [upgradable from: 1.5.1-1]
nvidia-docker2/bionic 2.7.0-1 all [upgradable from: 2.6.0-1]

# dockerd --version
Docker version 20.10.7, build 20.10.7-0ubuntu5~20.04.2

# nvidia-docker run <args> ; echo $?
eb0d0259ee5f46c448b7d1878aa262c7feba9012e8acbd52cd2bd8ecfb05849f
0

# docker inspect <name> | grep Runtime
            "Runtime": "nvidia",

Most likely the root cause is a nvidia-container-toolkit problem affecting 1.5.1-1 with a proposed fix in 1.6.0~rc.2-1
https://issueexplorer.com/issue/NVIDIA/nvidia-container-runtime/157
It would seem there are two options for temporarily fixing it until 1.6.0 is out:
* Install nvidia-container-toolkit 1.6.0~rc.2-1 https://docs.nvidia.com/datacenter/cloud-native/container-toolkit/install-guide.html#setting-up-nvidia-container-toolkit (the experimental section); I did not test this.

* Downgrade to 20.10.7-0ubuntu1~20.04.2 - This works for me; Ubuntu have just removed the package from the distribution, but can still be found online.

Same problem here, but my docker version is: Docker version 20.10.7, build 20.10.7-0ubuntu5~20.04.2 and I still have the problem.
Edit: Downgrading to 20.10.7-0ubuntu1~20.04.2 solve it.

Hi @jogonba2 Could you tell me how you downgraded ? The commands and all

@danpodeanu confirms that Nviida has released upgraded packages, try it before. The steps I did were simply downloading the docker.io 20.10.7-0ubuntu1~20.04.2 source package for your distribution (https://launchpad.net/ubuntu/+source/docker.io/20.10.7-0ubuntu1~20.04.2) and run a dpkg -i on it.

I can confirm that Nvidia has released upgraded packages, which appear to be working fine with docker.io 20.10.7-0ubuntu5~20.04.2. My problem has now been resolved.
# apt-get upgrade -y

docker.io/focal-updates,focal-security 20.10.7-0ubuntu5~20.04.2 amd64 [upgradable from: 20.10.7-0ubuntu1~20.04.2]
libnvidia-container-tools/bionic 1.6.0-1 amd64 [upgradable from: 1.5.1-1]
libnvidia-container1/bionic 1.6.0-1 amd64 [upgradable from: 1.5.1-1]
nvidia-container-runtime/bionic 3.6.0-1 amd64 [upgradable from: 3.5.0-1]
nvidia-container-toolkit/bionic 1.6.0-1 amd64 [upgradable from: 1.5.1-1]
nvidia-docker2/bionic 2.7.0-1 all [upgradable from: 2.6.0-1]

# dockerd --version
Docker version 20.10.7, build 20.10.7-0ubuntu5~20.04.2

# nvidia-docker run <args> ; echo $?
eb0d0259ee5f46c448b7d1878aa262c7feba9012e8acbd52cd2bd8ecfb05849f
0

# docker inspect <name> | grep Runtime
            "Runtime": "nvidia",

Upgrading solved the issue for me as well.
Also, I managed to solve this issue by running the container in privileged mode (instead of downgrading). This is not recommended, though.

Running on a jetson, I still get the issue with
Docker version 20.10.7, build 20.10.7-0ubuntu5~18.04.3

Did anyone resolve this issue on Ubuntu 18 ? Is the fix going to be published to 18 too ?

Using the experimental Nvidia runtime repo (linked somewhere above) worked for me. Add repo, then apt update/upgrade.

On Jetson Nano I get this error with
Docker version 20.10.7, build 20.10.7-0ubuntu5~18.04.3

@somera I got confirmation that the fix will be ported to Jetsons in a few days:
https://github.com/NVIDIA/libnvidia-container/issues/148#issuecomment-976814781

@somera I got confirmation that the fix will be ported to Jetsons in a few days: NVIDIA/libnvidia-container#148 (comment)

Thx.

Just ran into this on a Jetson ... not fixed in the default repos as of this post.

Just ran into this on a Jetson ... not fixed in the default repos as of this post.

Right, you have to switch to: https://docs.nvidia.com/datacenter/cloud-native/container-toolkit/install-guide.html#docker

I am still having the problem. I do not have any nvidia related software since this laptop does not have an nvidia card. I removed everything, ran apt purge on all docker and containerd packages. Installed docker-ce following the instructions on the site. Still, when running hello-world I get:
docker run --rm hello-world
docker: Error response from daemon: OCI runtime create failed: container_linux.go:348: starting container process caused "error adding seccomp filter rule for syscall clone3: permission denied": unknown.

My docker version:
docker version
Client: Docker Engine - Community
 Version:           20.10.12
 API version:       1.41
 Go version:        go1.16.12
 Git commit:        e91ed57
 Built:             Mon Dec 13 11:45:33 2021
 OS/Arch:           linux/amd64
 Context:           default
 Experimental:      true

Server: Docker Engine - Community
 Engine:
  Version:          20.10.12
  API version:      1.41 (minimum version 1.12)
  Go version:       go1.16.12
  Git commit:       459d0df
  Built:            Mon Dec 13 11:43:42 2021
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.4.12
  GitCommit:        7b11cfaabd73bb80907dd23182b9347b4245eb5d
 runc:
  Version:          1.0.2
  GitCommit:        v1.0.2-0-g52b36a2
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

containerd -version:
containerd --version
containerd containerd.io 1.4.12 7b11cfaabd73bb80907dd23182b9347b4245eb5d

runc --version:
runc -version
runc version 1.0.2
commit: v1.0.2-0-g52b36a2
spec: 1.0.2-dev
go: go1.16.10
libseccomp: 2.5.1

Downgrading docker-ce solves the issue for me:
apt-get install docker-ce=5:20.10.9~3-0~ubuntu-focal

Any idea how to fix the problem?

Still able to reproduce this issue.
Version information:
 ➜ docker version
Client: Docker Engine - Community
 Version:           20.10.10
 API version:       1.41
 Go version:        go1.16.9
 Git commit:        b485636
 Built:             Mon Oct 25 07:43:46 2021
 OS/Arch:           linux/amd64
 Context:           default
 Experimental:      true

Server: Docker Engine - Community
 Engine:
  Version:          20.10.12
  API version:      1.41 (minimum version 1.12)
  Go version:       go1.16.12
  Git commit:       459d0df
  Built:            Mon Dec 13 11:43:48 2021
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.4.11
  GitCommit:        5b46e404f6b9f661a205e28d59c982d3634148f8
 runc:
  Version:          1.0.0-rc10+dev
  GitCommit:        2c8d668eee4a5d537c47830f0dd932877442b946
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

docker-bookstack on  master [!] ➜ docker inspect docker-bookstack_mysql_1 | grep Run
            "Running": false,
            "Runtime": "runc",
            "CpuRealtimeRuntime": 0,
docker-bookstack on  master [!] ➜ docker info 2>/dev/null | grep Runtime
 Runtimes: io.containerd.runc.v2 io.containerd.runtime.v1.linux runc
 Default Runtime: runc
docker-bookstack on  master [!] ➜

This should be fixed by nvidia-container-toolkit v1.6.0 (1.7.0 for Jetson... based on the Nvidia issue tracker).

I am also not using the nvidia runtime (runc, I checked), ubuntu 18.04, docker-ce.
I started getting OCI runtime create failed: container_linux.go:345: starting container process caused "error adding seccomp filter rule for syscall clone3: permission denied": unknown from RUN within docker build, after upgrading docker.
$ apt-cache policy docker-ce | head -n 15
docker-ce:
  Installed: 5:20.10.9~3-0~ubuntu-bionic
  Candidate: 5:20.10.12~3-0~ubuntu-bionic
  Version table:
     5:20.10.12~3-0~ubuntu-bionic 500
        500 https://download.docker.com/linux/ubuntu bionic/stable amd64 Packages
     5:20.10.11~3-0~ubuntu-bionic 500
        500 https://download.docker.com/linux/ubuntu bionic/stable amd64 Packages
     5:20.10.10~3-0~ubuntu-bionic 500
        500 https://download.docker.com/linux/ubuntu bionic/stable amd64 Packages
 *** 5:20.10.9~3-0~ubuntu-bionic 500
        500 https://download.docker.com/linux/ubuntu bionic/stable amd64 Packages
        100 /var/lib/dpkg/status
     5:20.10.8~3-0~ubuntu-bionic 500
        500 https://download.docker.com/linux/ubuntu bionic/stable amd64 Packages

Resolved the issue by going back to 20.10.9 like sudo apt-get install docker-ce=5:20.10.9~3-0~ubuntu-bionic.

This should be fixed by nvidia-container-toolkit v1.6.0 (1.7.0 for Jetson... based on the Nvidia issue tracker).

I do not have anything related to nvidia installed: no driver, nor nvidia-container-toolkit. The computer I am using has only an intel graphics card.
$ apt list --installed | grep nvidia
WARNING: apt does not have a stable CLI interface. Use with caution in scripts.
$

It seems this issue is only being considered for those that have the nvidia toolkit, but there are some of us that only have runc...

@pontaoski

runc:
Version:          1.0.0-rc10+dev

Your runc seems too old.
Please try updating containerd.io package to 1.4.12-1, which contains runc v1.0.2

I would ask that anyone not using nvidia that is experiencing this issue:
If you are using Docker please make sure to update the containerd.io package.
Otherwise please make sure you are using runc >= 1.0.
Please run your repro with --runtime=io.containerd.runc.v2 to make extra care that we are using the expected runtime.
If it still reproduces, give us:

docker info (if applicable),
runc --version,
distro + version
command you are using that repros the issue
Version of libseccomp

@cpuguy83 yeah sure, I can still reproduce it

$ docker info
Client:
 Context:    default
 Debug Mode: false
 Plugins:
  app: Docker App (Docker Inc., v0.9.1-beta3)
  buildx: Docker Buildx (Docker Inc., v0.7.1-docker)
  scan: Docker Scan (Docker Inc., v0.12.0)

Server:
 Containers: 3
  Running: 0
  Paused: 0
  Stopped: 3
 Images: 7
 Server Version: 20.10.12
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Cgroup Version: 1
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 io.containerd.runtime.v1.linux runc
 Default Runtime: io.containerd.runc.v2
 Init Binary: docker-init
 containerd version: 7b11cfaabd73bb80907dd23182b9347b4245eb5d
 runc version:
 init version: de40ad0
 Security Options:
  apparmor
  seccomp
   Profile: default
 Kernel Version: 4.15.0-156-generic
 Operating System: Ubuntu 18.04.6 LTS
 OSType: linux
 Architecture: x86_64
 CPUs: 8
 Total Memory: 31.29GiB
 Name: joey-ThinkStation-P330
 ID: QJPB:DOX5:DLUG:4R3W:K7WZ:L2NF:RWGP:JGS3:IJRE:OC7Z:3AHC:YXN5
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: false
 Insecure Registries:
  <IP_ADDRESS>/8
 Live Restore Enabled: false

WARNING: No swap limit support

$ apt-cache policy docker-ce | head
docker-ce:
  Installed: 5:20.10.12~3-0~ubuntu-bionic
  Candidate: 5:20.10.12~3-0~ubuntu-bionic
  Version table:
 *** 5:20.10.12~3-0~ubuntu-bionic 500
        500 https://download.docker.com/linux/ubuntu bionic/stable amd64 Packages
        100 /var/lib/dpkg/status

$ runc --version
runc version spec: 1.0.1-dev

$ apt-cache policy containerd.io | head
containerd.io:
  Installed: 1.4.12-1
  Candidate: 1.4.12-1
  Version table:
 *** 1.4.12-1 500
        500 https://download.docker.com/linux/ubuntu bionic/stable amd64 Packages
        100 /var/lib/dpkg/status
     1.4.11-1 500
        500 https://download.docker.com/linux/ubuntu bionic/stable amd64 Packages
     1.4.10-1 500

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 18.04.6 LTS
Release:        18.04
Codename:       bionic

Literally anything that uses the runtime, e.g. docker build, or

$ docker run --runtime=io.containerd.runc.v2 --rm alpine:3.15                                                                                docker: Error response from daemon: OCI runtime create failed: container_linux.go:345: starting container process caused "error adding seccomp filter rule for syscall clone3: permission denied": unknown.

$ apt-cache policy libseccomp2 | head
libseccomp2:
  Installed: 2.5.1-1ubuntu1~18.04.2
  Candidate: 2.5.1-1ubuntu1~18.04.2
  Version table:
 *** 2.5.1-1ubuntu1~18.04.2 500
        500 http://ftp.filearena.net/pub/ubuntu bionic-updates/main amd64 Packages
        500 http://security.ubuntu.com/ubuntu bionic-security/main amd64 Packages
        100 /var/lib/dpkg/status
     2.3.1-2.1ubuntu4 500
        500 http://ftp.filearena.net/pub/ubuntu bionic/main amd64 Packages

Quick note, I CANNOT reproduce using the default Ubuntu 20.04.3 LTS Docker:
# docker info
Client:
 Context:    default
 Debug Mode: false

Server:
 Containers: 6
  Running: 6
  Paused: 0
  Stopped: 0
 Images: 36
 Server Version: 20.10.7
 Storage Driver: overlay2
  Backing Filesystem: xfs
  Supports d_type: true
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Cgroup Version: 1
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 io.containerd.runtime.v1.linux nvidia runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version:
 runc version:
 init version:
 Security Options:
  apparmor
  seccomp
   Profile: default
 Kernel Version: 5.4.0-91-generic
 Operating System: Ubuntu 20.04.3 LTS
 OSType: linux
 Architecture: x86_64
 CPUs: 16
 Total Memory: 62.69GiB
 Name: osiris
 ID: 4PMR:VHJO:M2LM:67K2:VK6B:PB2G:EJFZ:UI5I:Q7R5:A7N3:ONRE:KUSM
 Docker Root Dir: /storage/docker
 Debug Mode: false
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: false
 Insecure Registries:
  <IP_ADDRESS>/8
 Live Restore Enabled: false

WARNING: No swap limit support
WARNING: bridge-nf-call-iptables is disabled
WARNING: bridge-nf-call-ip6tables is disabled

# runc --version
runc version 1.0.1-0ubuntu2~20.04.1
spec: 1.0.2-dev
go: go1.13.8
libseccomp: 2.5.1

# lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 20.04.3 LTS
Release:	20.04
Codename:	focal

N/A, this runs fine:

# docker run --runtime=io.containerd.runc.v2 --rm alpine:latest /usr/bin/id
uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel),11(floppy),20(dialout),26(tape),27(video)

# apt-cache policy libseccomp2
libseccomp2:
  Installed: 2.5.1-1ubuntu1~20.04.2
  Candidate: 2.5.1-1ubuntu1~20.04.2
  Version table:
 *** 2.5.1-1ubuntu1~20.04.2 500
        500 http://sg.archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages
        500 http://sg.archive.ubuntu.com/ubuntu focal-security/main amd64 Packages
        100 /var/lib/dpkg/status
     2.4.3-1ubuntu1 500
        500 http://sg.archive.ubuntu.com/ubuntu focal/main amd64 Packages

@joeycumines from the output of your docker info and runc --version  on the Ubuntu 18.04 machine, I think there's a custom runc binary installed. The runc version does not have the expected output. Here's what I expect it to look like on an 18.04 machine with containerd.io 1.4.12 installed;
 containerd version: 7b11cfaabd73bb80907dd23182b9347b4245eb5d
 runc version: v1.0.2-0-g52b36a2

runc --version
runc version 1.0.2
commit: v1.0.2-0-g52b36a2
spec: 1.0.2-dev
go: go1.16.10
libseccomp: 2.5.1

@cpuguy83, here are the details from my machine

docker info (if applicable)

Client:
 Context:    default
 Debug Mode: false
 Plugins:
  app: Docker App (Docker Inc., v0.9.1-beta3)
  buildx: Docker Buildx (Docker Inc., v0.7.1-docker)
  scan: Docker Scan (Docker Inc., v0.12.0)

Server:
 Containers: 0
  Running: 0
  Paused: 0
  Stopped: 0
 Images: 36
 Server Version: 20.10.12
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Cgroup Version: 1
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 io.containerd.runtime.v1.linux runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 7b11cfaabd73bb80907dd23182b9347b4245eb5d
 runc version: v1.0.2-0-g52b36a2
 init version: de40ad0
 Security Options:
  apparmor
  seccomp
   Profile: default
 Kernel Version: 5.4.0-92-generic
 Operating System: Ubuntu 20.04.3 LTS
 OSType: linux
 Architecture: x86_64
 CPUs: 4
 Total Memory: 31.24GiB
 Name: nsousa-ThinkPad-T470
 ID: MGW7:57NX:2IK4:RC3Q:5MNF:55UW:JZJF:N5CL:LWCL:FHDK:4H6E:32T7
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: false
 Insecure Registries:
  <IP_ADDRESS>/8
 Live Restore Enabled: false

WARNING: No swap limit support

runc --version

runc version 1.0.2
commit: v1.0.2-0-g52b36a2
spec: 1.0.2-dev
go: go1.16.10
libseccomp: 2.5.1

distro + version

$ lsb_release -a
LSB Version:    core-11.1.0ubuntu2-noarch:printing-11.1.0ubuntu2-noarch:security-11.1.0ubuntu2-noarch
Distributor ID: Ubuntu
Description:    Ubuntu 20.04.3 LTS
Release:        20.04
Codename:       focal

command you are using that repros the issue

$ docker run --rm -ti hello-world
docker: Error response from daemon: OCI runtime create failed: container_linux.go:348: starting container process caused "error adding seccomp filter rule for syscall clone3: permission denied": unknown.

Version of libseccomp

# apt list --installed | grep libseccomp
libseccomp2/focal-updates,focal-security,now 2.5.1-1ubuntu1~20.04.2 amd64 [installed]

My workaround has been to down downgrade docker with:
apt-get install docker-ce=5:20.10.9~3-0~ubuntu-focal
apt-mark hold docker-ce

After that, running the hello-world works:
$ docker run --rm -ti hello-world

I was about to come on here and say the minimum version of runc supported should now be 1.0.2, however I see some people saying they have 1.0.2.
The reason I would say 1.0.2 is required is in order to un-break everyone due to a bad mix of clone3 now being used in glibc and elsewhere + the seccomp profile deaulting to EPERM (meaning glibc cannot fallback to older behavior before clone3) forced docker/containerd/everyone to update the default seccomp profiles to add a clone3 filter and a custom return value of ENOSYS: https://github.com/moby/moby/commit/9f6b562dd12ef7b1f9e2f8e6f2ab6477790a6594
For the people who do already have runc @ v1.0.2, there is something else going on here, I think. This version should work.
Depending on if you have libseccomp v2.5 or < v2.5 you may see a slightly different error due to the error parsing in the libseccomp go bindings that are currently used not being up to date.
libseccomp 2.5 returns EACCES in this case, while < 2.5 returns EPERM.
In any case, please make sure you are using at least runc version 1.0.2.

> I think there's a custom runc binary installed

Thanks @thaJeztah ! I guess I must've compiled it myself then forgotten I'd done so, it was using /usr/local/bin/runc.
I am now on v1.0.2-0-g52b36a2, and no longer have the issue. Thanks @cpuguy83 as well.

Great news.
I'm going to go ahead and close this out.
In short, when using the default seccomp profile the OCI runtime needs to support the errnoRet option for seccomp rules added to the runtime-spec here https://github.com/opencontainers/runtime-spec/commit/3bfcde28eab5d7e107ddd3771fc92399332932a8 (fixed json tag here https://github.com/opencontainers/runtime-spec/commit/f9df045810150d856c84d70df7eea25554ef5caa).
This should be in runc >= v1.0.2.
Other runtimes would need to be looked at individually for what version supports it.
If you feel like you are running runc v1.0.2 already, please validate:

That you are using the correct runtime name
That runc in $PATH (as the containerd daemon process can see it) is what you expect it to be.

For folks using Kubernetes thinking "but I'm not using seccomp" (k8s disables seccomp by default), containerd applies the default seccomp policy to the init/pause container of the pod.

@cpuguy83: I still have the problem.
I never compiled runc or any ting else, just installed via apt.
I have runc is version 1.0.2 in my path:
$ runc --version
runc version 1.0.2
commit: v1.0.2-0-g52b36a2
spec: 1.0.2-dev
go: go1.16.10
libseccomp: 2.5.1

It is also shown in docker info:
Client:
 Context:    default
 Debug Mode: false
 Plugins:
  app: Docker App (Docker Inc., v0.9.1-beta3)
  buildx: Docker Buildx (Docker Inc., v0.7.1-docker)
  scan: Docker Scan (Docker Inc., v0.12.0)

Server:
 Containers: 0
  Running: 0
  Paused: 0
  Stopped: 0
 Images: 36
 Server Version: 20.10.12
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Cgroup Version: 1
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 io.containerd.runtime.v1.linux runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 7b11cfaabd73bb80907dd23182b9347b4245eb5d
 runc version: v1.0.2-0-g52b36a2
 init version: de40ad0
 Security Options:
  apparmor
  seccomp
   Profile: default
 Kernel Version: 5.4.0-92-generic
 Operating System: Ubuntu 20.04.3 LTS
 OSType: linux
 Architecture: x86_64
 CPUs: 4
 Total Memory: 31.24GiB
 Name: nsousa-ThinkPad-T470
 ID: MGW7:57NX:2IK4:RC3Q:5MNF:55UW:JZJF:N5CL:LWCL:FHDK:4H6E:32T7
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: false
 Insecure Registries:
  <IP_ADDRESS>/8
 Live Restore Enabled: false

WARNING: No swap limit support

Even if I force the runtime, I still get the error:
$ docker run --rm -ti --runtime=io.containerd.runc.v2  hello-world
docker: Error response from daemon: OCI runtime create failed: container_linux.go:348: starting container process caused "error adding seccomp filter rule for syscall clone3: permission denied": unknown.

This problem started for me with docker-ce=5:20.10.10~3-0~ubuntu-focal

I don't have nvidia runtime/sdk/whatever-related-to-it installed.
Debian Testing. Keep trying to update for 3-4 months in row and have to downgrade every time. Latest working version is: 5:20.10.9~3
# runc -v
runc version 1.0.2
commit: v1.0.2-0-g52b36a2
spec: 1.0.2-dev
go: go1.16.10
libseccomp: 2.5.3

# docker info
Client:
 Context:    default
 Debug Mode: false
 Plugins:
  app: Docker App (Docker Inc., v0.9.1-beta3)
  buildx: Docker Buildx (Docker Inc., v0.7.1-docker)
  scan: Docker Scan (Docker Inc., v0.12.0)

Server:
 Containers: 9
  Running: 0
  Paused: 0
  Stopped: 9
 Images: 208
 Server Version: 20.10.12
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Cgroup Version: 1
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 io.containerd.runtime.v1.linux runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 7b11cfaabd73bb80907dd23182b9347b4245eb5d
 runc version: v1.0.2-0-g52b36a2
 init version: de40ad0
 Security Options:
  apparmor
  seccomp
   Profile: default
 Kernel Version: 5.15.0-2-amd64
 Operating System: Debian GNU/Linux bookworm/sid
 OSType: linux
 Architecture: x86_64
 CPUs: 8
 Total Memory: 31.24GiB

# docker run --rm -ti --runtime=io.containerd.runc.v2  hello-world
docker: Error response from daemon: OCI runtime create failed: container_linux.go:348: starting container process caused "error adding seccomp filter rule for syscall clone3: permission denied": unknown.

Wow!!
I just read one more time the post by @cpuguy83 and in particular this part:

If you feel like you are running runc v1.0.2 already, please validate:

That you are using the correct runtime name
That runc in $PATH (as the containerd daemon process can see it) is what you expect it to be.

The runtime surely is not nvidia and none of containers have it, just double checked.
The $PATH surely has runc in it, as runc -v  shows the info quoted above however, I decided to run whereis runc and was quite amazed when saw next result:
runc: /usr/bin/runc /opt/containerd/bin/runc

WHAT? I haven't installed it into /opt. /opt/containerd/bin/runc -v shown me the version is less than 1.0. I just deleted this folder and restarted the laptop (probably just restart of docker service would be enough, but I had another reason to restart the machine as well). Docker and docker-compose works fine now!
@nmtsousa , check if you have similar case, pls.

@SCIF You solved it. That´s exact the same problem on my installation. Deleting /opt/containerd/bin/runc is the right way. I also never have installed runc there. Never compiled runc myself. Just using apt install , apt update and apt upgrade.
THX

Thanks @SCIF, that also solve the problem for me.
I also never compiled anything or installed anything without using apt. I tryied running "dpkg -S ..." to get the package that installed those files held an empty result:
# dpkg -S /opt/containerd/bin/runc
dpkg-query: no path found matching pattern /opt/containerd/bin/runc

Don't know what package left that file there, but not I removed /opt/containerd completely (it also had a /opt/containerd/bin/containerd-shim-process-v1 file)

Glad to see it helps not just me :) Yeah, I checked with dpkg -S prior deletion. And my assumption that this folder came from docker.io package which used to be installed until I migrated to recommended docker-ce (that happened a while ago, but apparently, the package legacy left on disk).

I decided to run whereis runc and was quite amazed when saw next result:

Hmm.. interesting; yes, that could explain the issue.

my assumption that this folder came from docker.io package

hmm.. could be the case yes. I don't think the docker-ce or containerd.io packages ever used that location (did some searching in history, but at least couldn't find a reference to it installing inside /opt/containerd/ 🤔)

To me it seems docker.io installed runc in this location (/opt/containerd/bin) in the past. I just use docker.io, never used docker-ce in the past on this machine.
I only tried docker-ce to find a solution for this problem and got the same problems with docker-ce. Now I know why.

After installing docker.io with apt install docker.io again the folders /opt/containerd/bin and /opt/containerd/lib are back again, but with nothing in it.

I suspect those may be related to https://github.com/containerd/containerd/blob/35b96f9b1c27c71607a9d038819c6c9a4223c96f/services/opt/service.go#L40 (part of https://github.com/containerd/containerd/pull/2518)

On Ubuntu 18.04, I had to downgrade Docker to 20.10.7-0ubuntu1~18.04.1

Hi, I have a similar problem, I have been fighting it for a week with no success. I have the same problem on every system image available for bananapi m5 that I have.
sudo docker run --rm -it hello-world
Unable to find image 'hello-world:latest' locally
latest: Pulling from library/hello-world
7050e35b49f5: Pull complete
Digest: sha256:80f31da1ac7b312ba29d65080fddf797dd76acfb870e677f390d5acba9741b17
Status: Downloaded newer image for hello-world:latest
docker: Error response from daemon: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: error setting cgroup config for procHooks process: bpf_prog_query(BPF_CGROUP_DEVICE) failed: invalid argument: unknown.
docker info
Client:
Context:    default
Debug Mode: false
Plugins:
app: Docker App (Docker Inc., v0.9.1-beta3)
buildx: Docker Buildx (Docker Inc., v0.8.2-docker)
compose: Docker Compose (Docker Inc., v2.5.0)
Server:
Containers: 2
Running: 0
Paused: 0
Stopped: 2
Images: 4
Server Version: 20.10.16
Storage Driver: overlay2
Backing Filesystem: extfs
Supports d_type: true
Native Overlay Diff: true
userxattr: false
Logging Driver: json-file
Cgroup Driver: systemd
Cgroup Version: 2
Plugins:
Volume: local
Network: bridge host ipvlan macvlan null overlay
Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
Swarm: inactive
Runtimes: runc io.containerd.runc.v2 io.containerd.runtime.v1.linux
Default Runtime: runc
Init Binary: docker-init
containerd version: 212e8b6fa2f44b9c21b2798135fc6fb7c53efc16
runc version: v1.1.1-0-g52de29d
init version: de40ad0
Security Options:
apparmor
seccomp
Profile: default
cgroupns
Kernel Version: 4.9.241-BPI-M5
Operating System: Debian GNU/Linux 11 (bullseye)
OSType: linux
Architecture: aarch64
CPUs: 4
Total Memory: 3.625GiB
Name: raspberrypi
ID: DQ6Y:M3MV:6BFM:VEG2:PL4M:GRBS:KIP6:GO2S:K4QD:F3UO:QWIF:PAVO
Docker Root Dir: /var/lib/docker
Debug Mode: false
Registry: https://index.docker.io/v1/
Labels:
Experimental: false
Insecure Registries:
<IP_ADDRESS>/8
Live Restore Enabled: false
WARNING: No swap limit support
WARNING: No cpu cfs quota support
WARNING: No cpu cfs period support
WARNING: No cpu shares support
WARNING: No cpuset support
WARNING: No io.weight support
WARNING: No io.weight (per device) support
WARNING: No io.max (rbps) support
WARNING: No io.max (wbps) support
WARNING: No io.max (riops) support
WARNING: No io.max (wiops) support
apt-cache policy docker-ce | head
docker-ce:
Installed: 5:20.10.16~3-0~debian-bullseye
Candidate: 5:20.10.16~3-0~debian-bullseye
Version table:
*** 5:20.10.16~3-0~debian-bullseye 500
500 https://download.docker.com/linux/debian bullseye/stable arm64 Packages
100 /var/lib/dpkg/status
5:20.10.15~3-0~debian-bullseye 500
500 https://download.docker.com/linux/debian bullseye/stable arm64 Packages
5:20.10.14~3-0~debian-bullseye 500
runc --version
runc version 1.1.1
commit: v1.1.1-0-g52de29d
spec: 1.0.2-dev
go: go1.17.9
libseccomp: 2.5.1
whereis runc
runc: /usr/bin/runc
lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:    Debian GNU/Linux 11 (bullseye)
Release:        11
Codename:       bullseye
apt-cache policy libseccomp2 | head
libseccomp2:
Installed: 2.5.1-1+deb11u1
Candidate: 2.5.1-1+deb11u1
Version table:
*** 2.5.1-1+deb11u1 500
500 http://deb.debian.org/debian bullseye/main arm64 Packages
100 /var/lib/dpkg/status

docker: Error response from daemon: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: error setting cgroup config for procHooks process: bpf_prog_query(BPF_CGROUP_DEVICE) failed: invalid argument: unknown.

Seems irrelevant to the OP.
Please recompile your kernel with CONFIG_CGROUP_BPF=y. Perhaps you need CONFIG_CGROUP_DEVICE=y too.
Another workaround is to disable cgroup v2 by appending systemd.unified_cgroup_hierarchy=0 to the kernel cmdline.

Please recompile your kernel with CONFIG_CGROUP_BPF=y. Perhaps you need CONFIG_CGROUP_DEVICE=y too.
Another workaround is to disable cgroup v2 by appending systemd.unified_cgroup_hierarchy=0 to the kernel cmdline

problem is that I have CONFIG_CGROUP_BPF=y and
# cat /boot/cmdline.txt console=serial0,115200 console=tty1 root=PARTUUID=d97f5830-02 rootfstype=ext4 fsck.repair=yes rootwait quiet init=/usr/lib/raspi-config/init_resize.sh splash plymouth.ignore-serial-consoles systemd.unified_cgroup_hierarchy=0
does not do anything :(

I have the same problem on ubuntu 20.04 with docker version 20.10.12-0ubuntu2~20.04.1.
I tried to downgrade the version to 20.10.7-0ubuntu1~20.04.2 as suggested from this issue. However, this version can no longer be found.
apt-get install docker.io=20.10.7-0ubuntu1~20.04.2 Reading package lists... Done Building dependency tree Reading state information... Done E: Version '20.10.7-0ubuntu1~20.04.2' for 'docker.io' was not found
Is there any other version i can use?

Still getting this on Fedora 36.

Same problem here. I updated docker.io and containerd in Ubuntu 18.04 via apt yesterday afternoon.
containerd/bionic-updates 1.5.5-0ubuntu3~18.04.1 arm64 [upgradable from: 1.5.2-0ubuntu1~18.04.2]
docker.io/bionic-updates 20.10.7-0ubuntu5~18.04.2 arm64 [upgradable from: 20.10.7-0ubuntu1~18.04.1]

Downgrading docker, as suggested by @nmtsousa, fixed the issue.

Which commands did you use for downgrade? I have the same issue, also on Ubuntu 18.04

Wow!!
I just read one more time the post by @cpuguy83 and in particular this part:

If you feel like you are running runc v1.0.2 already, please validate:

That you are using the correct runtime name
That runc in $PATH (as the containerd daemon process can see it) is what you expect it to be.

The runtime surely is not nvidia and none of containers have it, just double checked. The $PATH surely has runc in it, as runc -v  shows the info quoted above however, I decided to run whereis runc and was quite amazed when saw next result:
runc: /usr/bin/runc /opt/containerd/bin/runc

WHAT? I haven't installed it into /opt. /opt/containerd/bin/runc -v shown me the version is less than 1.0. I just deleted this folder and restarted the laptop (probably just restart of docker service would be enough, but I had another reason to restart the machine as well). Docker and docker-compose works fine now!
@nmtsousa , check if you have similar case, pls.

This was our issue, an old runc bin hanging around, not even in our users path, so I had to just check for the /opt/containerd/bin/runc path to find it. Removing this resolved my issue with 1804. Thanks a ton!


Logo or Logout

Is right "Logo" ?
https://github.com/IdentityServer/IdentityServer4/blob/a984fc7b3ad32a17a0430fdeadf0b11deb8644cf/src/IdentityServer4/Models/Client.cs#L64

Hey there,
don´t know if we should keep up the work in different branches since I managed to get most of it working, but to answer your question:
LogoutUri got renamed to FrontChannelLogoutUri
https://github.com/IdentityServer/IdentityServer4/blob/a984fc7b3ad32a17a0430fdeadf0b11deb8644cf/src/IdentityServer4/Models/Client.cs#L121

ok, thanks ... another breaking change to add at list.


Wrong DuckDNS TXT record update URL

I'm trying to get Traefik+DuckDNS+LetsEncrypt to work on my hass.io system, this is my configuration:
log_level: INFO
access_logs: false
forwarded_headers_insecure: false
dynamic_configuration_path: /share
letsencrypt:
  enabled: true
  email<EMAIL_ADDRESS>  challenge_type: dnsChallenge
  provider: duckdns
env_vars:
  - DUCKDNS_TOKEN=abcd1234efgh5678ijkl90

But it's unable to get the Certificates, it returns the following error:
time="2020-07-01T22:40:59-03:00" level=error msg="Unable to obtain ACME certificate for domains \"subdomain.domain.duckdns.org\": unable to generate a certificate for the domains [subdomain.domain.duckdns.org]: error: one or more domains had a problem:\n[subdomain.domain.duckdns.org] [subdomain.domain.duckdns.org] acme: error presenting token: request to change TXT record for DuckDNS returned the following result (KO) this does not match expectation (OK) used url [https://www.duckdns.org/update?clear=false&domains=domain.duckdns.org&token=abcd1234efgh5678ijkl90+&txt=ABCDEFGHTASDF]\n" providerName=le.acme rule="Host(`subdomain.domain.duckdns.org`)" routerName=homeAssistantRouter@file

Right after the token value and before de "&txt=" theres a plus sign, when I type that URL (with the plus sign) on Chrome navigator, it returns KO, but if I remove the plus sign (https://www.duckdns.org/update?clear=false&domains=domain.duckdns.org&token=abcd1234efgh5678ijkl90&txt=ABCDEFGHTASDF) it returns OK
Any idea on how can I solve this?
(EDIT: By the way, this is only preventing me from having a working certificate, routing works just fine, Traefik is able to redirect the "subdomain.domain.duckdns.org" to the proper internal url and port)

Thanks for using this add-on.
I have just updated the add-on to version 3.0.1 which re-enabled logging for environment variables. I also created #9 to fix logging levels. Could you please run the add-on and share the logging which relates to environment variables. In your case it should be something like this:
[18:27:20] INFO: Extracting environment variables...
[18:27:20] INFO: Extracted variables DUCKDNS_TOKEN=abcd1234efgh5678ijkl90

I really want to know whether or not this is a Treafik issue, ACME / LEGO issue or perhaps an issue with this add-on.


Clarify spec requirements for overpadded positive zero decimals

(Broken out of https://github.com/amzn/ion-docs/issues/133#issuecomment-873636960 as a separate issues.)
The spec for binary decimals gives

If the value is 0. (aka 0d0) then L is zero, there are no length or representation fields, and the entire value is encoded as the single byte 0x50.

As was initially the case in https://github.com/amzn/ion-docs/issues/93, this can be interpreted as requiring that 0x50 is the only valid representation of 0d0.
Should this likewise be reworded? It seems unlikely that this wording was intended to convey a requirement for binary decimals, but similar wording was not intended to convey a similar requirement for binary ints.
Support for the "0x50 is required" reading comes from the fact that the equivalent wording for ints (before it was changed in https://github.com/amzn/ion-docs/issues/93) did not go so far as to explicitly mention the byte representation 0x20.
Support for the "0x50 is optional" reading comes from the next section on Timestamps, which uses 0d0 as an example of a decimal value being represented with exponent and coefficient fields.

The fraction_exponent and fraction_coefficient denote the fractional seconds of the timestamp as a decimal value. The fractional seconds’ value is coefficient * 10 ^ exponent. It must be greater than or equal to zero and less than 1. A missing coefficient defaults to zero. Fractions whose coefficient is zero and exponent is greater than -1 are ignored. The following hex encoded timestamps are equivalent:
...
69 80 0F D0 81 81 80 80 80 80    // The same instant with 0d0 fractional seconds and implicit zero coefficient
6A 80 0F D0 81 81 80 80 80 80 00 // The same instant with 0d0 fractional seconds and explicit zero coefficient

This could be interpreted as an artifact of Timestamps needing to distinguish between the presence/absence of the fractional second component for precision reasons, but it implies that 80 and 80 00 are valid as a representation of 0d0.
It could be that the "... as a decimal value" wording should not actually be understood as meaning a valid representation of a decimal value, but this seems to conflict with the fact that fraction_exponent is a VarInt and fraction_coefficient is an Int.
Because "the fractional seconds' value... must be greater than or equal to zero", fraction_coefficient never needs to represent a negative integer, and could have been chosen to be a UInt. Because "the fractional seconds' value... must be less than 1", fraction_exponent never needs to represent a positive number, and could have been chosen to be a VarUInt.
The fact that less compact representations were chosen over more compact representations indicates that they were chosen to align with the exponent [VarInt] and coefficient [Int] of decimal, and that the "... as a decimal value" wording should be understood literally.

Closed by merging of https://github.com/amzn/ion-docs/pull/153.


Add support for parsing modules that contain multiple functions

Currently there is only support for AST parsing of TS modules which contain only one Cloud Function and its associated Runtime Conf.
Ideally, it will be more useful to have the ability to bundle modules which contain multiple Functions and Confs.
Proposal
Define an interface as such, which is used for containing a record of all functions and confs inside one variable. Then export that variable as the default.
interface FunctionsModule {
  [name: string]: {
    fn: (...args: any[]) => any,
    runtimeConf: GcpConfig,
  };
}

Closing issue, as we can get around the current limitation by having multiple TypeScript modules per folder, with one function in each module.


[BUG] Broken CosmosDB Spring Data Repository entity projection

Hi. We have encountered an issue related to inconsistent entity properties projection while switching to the latest version of azure-spring-data-cosmos library.
For example, given that CosmosDB spring data repository interface contains below method -
@Query("SELECT VALUE c.productId FROM c WHERE c.uid = @uid")
String getProductIdByUID(@Param("id") String uid);

Once such a method will be executed the following exception will be raised:
java.lang.IllegalArgumentException: Entity is null.
    at org.springframework.util.Assert.notNull(Assert.java:201)
    at com.azure.spring.data.cosmos.core.convert.MappingCosmosConverter.read(MappingCosmosConverter.java:65)
    at com.azure.spring.data.cosmos.core.CosmosTemplate.toDomainObject(CosmosTemplate.java:893)
    at com.azure.spring.data.cosmos.core.CosmosTemplate.lambda$runQuery$23(CosmosTemplate.java:774)

It is caused by broken CosmosPersistentEntity mapping by 'Repository Entity'/'Repository derived method return' types.
Our assumption - the root cause of such a behavior was introduced during below code updates related to CosmosTemplate class:
https://github.com/Azure/azure-sdk-for-java/commit/3719570edb49ecceb8c8a874ae60a6c90fa9761a#diff-9d1b72616d654841a02e8a58ff64d4121a68b5009a9f62a9a233dae5df119403
Thanks!

@kushagraThapar PTAL

@PavelKhatsimtsau - Is this issue happening consistently? What do you mean by inconsistent entity properties projection ?
cc - @Blackbaud-MikeLueders - Can you please help taking a look at this issue?
Is it a regression in this PR - https://github.com/Azure/azure-sdk-for-java/pull/19438 ?

Hi, everyone! Sorry for delayed respond.
I have tried to reproduce above problem with the latest 3.6.0 released version - and it is still an actual issue.
I am agree - inconsistent entity properties projection - is a bit frustrated term - let me explain what I exactly was trying to describe:
Let`s assume - that we have cosmos db repository for some abstract Product type with below methods:
@Query("SELECT VALUE c.productId FROM c WHERE c.uid = @productId")
String getProductIdByUID(@Param("productId") String uid);

@Query("SELECT VALUE COUNT(1) FROM c WHERE c.uid= @productId")
Long countByProductId(@Param("productId") String uid);

For both above methods MappingContext,  CosmosPersistentProperty> mappingContext field from com.azure.spring.data.cosmos.core.convert.MappingCosmosConverter will contain the following entity mapping items:

{ClassTypeInformation@11111} "java.lang.String" -> {Optional@22222} "Optional.empty"
{ClassTypeInformation@33333} "java.lang.Long" -> {Optional@44444} "Optional.empty"
{ClassTypeInformation@18397} "com.example..model.Product" -> {Optional@55555} "Optional[com.azure.spring.data.cosmos.core.mapping.BasicCosmosPersistentEntity@5173ef95]"

So when methods have some property model projection or any aggregated value as its return type  - empty CosmosPersistentEntity<?> object will be returned in scope of below code
com.azure.spring.data.cosmos.core.convert.MappingCosmosConverter#read:64
@Override
    public <R> R read(Class<R> type, JsonNode jsonNode) {

        final CosmosPersistentEntity<?> entity = mappingContext.getPersistentEntity(type);
        Assert.notNull(entity, "Entity is null.");

        return readInternal(entity, type, jsonNode);
    }

Hopefully it will be useful information to reveal the problem we encountered. Thanks!

@PavelKhatsimtsau - thanks for the explanation, I understand the issue somewhat now. Would it be possible for you to provide a sample repo for this issue ? So that I can look into a possible fix for this.

circling back much later, has anyone gotten projections to work successfully in latest versions?
I am running into similar issues as above.. It looks like the implementation is not respecting the return type of the projection, and is instead returning the entire entity

@trande4884 can you please take a look at this issue, thanks!

@snimmagadda1 is there a sample repo you can link that shows this issue?
I ask because our integration tests have functions that are the same as what you are listing and they do not throw this error:
@Query(value = "SELECT VALUE COUNT(1) from c where c.title = @title") Long countByQueryWithNonPrimitive(@Param("title") String title);

Hey,
I have recently stumbled over a similar issue as well, not sure if it is the one above though. I have created a sample repository here: https://github.com/PlayAnyData/demo-cosmos-spring
From my point of view, there are some things that are not that obvious in the first place. I have added three different queries there, from which the first one throws the Exception:
@Query("SELECT count(1) FROM c")  long countObjects();
Compared to @trande4884 integration test, we are missing the VALUE in here, which is a keyword for returning the value instead of the json (see here https://learn.microsoft.com/en-us/azure/cosmos-db/nosql/query/select) and was present in the original poster's issue.
The second query here, does not work as well, although we have the VALUE keyword in there. I guess the problem is with the alias (AS). However, be aware that in case you have an ALIAS, it seems the VALUE keyword with CosmosRepository does not work as expected.
@Query("SELECT VALUE count(1) as counter FROM c") long countObjects2();
This third one works fine. Although this is not exactly elegant, as now we are returning a projection as a list. Afterwards, we need to access the first object from it to get the value. MyDataProjection in this case is just containing one object named counter.
@Query("SELECT count(1) as counter FROM c")  List<MyDataProjection> countObjectsWrapped();
I hope this sheds some lights into what might have caused the issue?!

@trande4884 / @TheovanKraay please take a look at this. Is it worth opening a new GitHub issue altogether?


replace serde_yaml

serde_yaml is unmaintained, we need to find an alternative https://github.com/dtolnay/serde-yaml/releases/tag/0.9.34

Oh this is fun. Thanks for the heads up

Looks like that still depends on serde_yaml under the hood and is more focused on config (though I really want to try it for config stuff now)

Though I think this is an important issue to keep track of, it doesn't seem like there is a defacto replacement at this time so I'm going to remove it from our prioritized v1.1 roadmap. We should certainly still be looking for alternatives here


Swapped two variable defaults

The default values of the variables $layout-drawer-navigation-link-active-background, and $layout-drawer-navigation-link-active-color were swapped.

I signed it!

LGTM

_Before swap_

_After swap_


eventTime not following the standard

eventTime (https://dwc.tdwg.org/terms/#dwc:eventTime) doesn't look to be following ISO 8601:2004(E)

I managed to change all event times it to hh:mm:ss in the upcoming version of the data conform ISO 8601. But I think for the timezones required by ISO 8601:2004(E), we need to be pragmatic in the sense that figuring this out based on geographic coordinates for millions of records is computationally unfeasible.

What does eventTime currently hold? Is it local time at the release location? Then maybe a conversion to UTC (HH:MMZ) is feasible?

Anton informed me that all times are UTC, so the format is now HH:MM:SSZ (with timezone stamp)


NixOS 15.09 ISO images cannot be mounted under Mac OS

For some reason i cannot boot my partition with NixOS 14.12 anymore (after i have reinstalled Mac OS on another partition), so i wanted to reinstall NixOS.
I have downloaded the minimal ISO image of 15.09 and tried to create a bootable USB drive (for (U)EFI MacBook) as i had done before: by mounting the ISO image and dragging and dropping its contents to a properly formatted USB drive labelled NIXOS_ISO.
However, clicking on the ISO image of 15.09 (under Mac OS) failed to mount it and opened a window of DiskImageMounter with a warning: "nixos-minimal-15.09-... no mountable file system". The same operation works fine with ISO images of 14.12.
Can this be fixed? Should i maybe follow a different procedure to create a bootable NixOS USB drive?

I have managed to unpack the ISO image instead of mounting it, so this has solved my problem. I am not closing the issue yet because i am not sure that making the "Mac-OS-unmountable" ISO image for 15.09 was intentional.

I am not sure i would have time to make a pull request to update the installation documentation, but here is my account of installing NixOS on a MacBook, in case it helps.

(triage) do you still have a problem with this?

With 16.03 -- yes.
However, i succeeded to create a bootable flash drive from it with dd command.

Okay, then we can close. @jagajaga

The same with Ubuntu image 16.04, by the way. Maybe it is ok, as long as dd works.

As long as the procedure is explained in the documentation!


[Question] Regardings External Tasks executed in parallel

Hi,
just wanted to ask if there is a standard approach when facing External Task that run in parallel, when customizing the TestExecutors, e.g., like here:

If I understand correctly the plugin tries to use simple flows through the model, and therefore omits creating parallel paths.
However, in the case shown, I get the problem that the process never can go past the merging gateway.
In the repository there is an example with Delegates, however, in this case we have External Tasks.
If I understand the framework completly I should now create my own ExternalTaskHandler, e.g., like this:
ExternalTaskHandler extTaskHandler = new ExternalTaskHandler(tc.getProcessEngine(), "ActivityId", "TopicName");
tc.createExecutor().execute();

But what I am missing is: how can I customize the executor so that the ExternalTaskHandler is executed in the test?
Any help would be appreciated!

hi @nyuuyn,
after selecting the path and adding the test case. please go to the BPMN XML and add the parallel element as node to the test case (I manually added the selected line):

when this is done, the test case gets a problem marker ("Path is invalid...") - but you can ignore it, since this is only related to the path finding:

now the test code generation should consider the second external task (generate a handle* method, handle its wait state, assert that the process instance has passed it). please keep in mind that the execution order is fixed - in my example: first "externalTaskA", second "externalTaskB".
i hope this helps!
best regards

Ahhh great, thank you very much! I didn't think that would even work :D


Clarify that only SI-based units are supported and / or add support for power-of-two based units

In addition to power-of-ten based "kilo", "mega", "giga" units, it would be nice to also support power-of-two based "kibi", "mebi", "gibi" IEC units, which are esp. common in Information Technology, see e.g. multiple byte units.

#5

Both SI and IEC units are now available in https://github.com/saket/byte-size/releases/tag/2.0.0-beta02


[Feature-Request] Display selected item on title box

Hi, it'd be great to be able to config if on the title box to display either the default option of "Selected: x" or to display the text of the selected options, like the following:

The way I did it for now is:
Add the optional parameter displaySelectedItems default false (a better name could be great) and the on setSelectState
https://github.com/afonja14755/ux-select/blob/386732ac97cae87c1af7b008d3355aa1b0dd33d8/src/ux-select.ts#L168-L170
Replace with:
if (this.config.displaySelectedItems) {
  selectTitle.textContent = selectedTexts.join(', ');
} else {
  selectTitle.textContent = `${this.localization.selectedText} ${selectedTexts.length}`;
}

And to avoid the text overflow when there are too many selected items then on the styles we have this:
. ux-select__title {
    user-select: none;
    flex-grow: 1;
    white-space: nowrap;
    overflow: hidden;
    text-overflow: ellipsis;
  }

Thanks

Thank you for your request. I will look into this feature and try to add it.


fail to build source code

hello everyone,
Sorry to bother. When I build source code, I encounter one problem. can not find file: openssl/rsa.h
C:\Users\royhsu\ipfs-desktop>npm start

<EMAIL_ADDRESS>start C:\Users\royhsu\ipfs-desktop
electron-forge start

√ Checking your system
√ Locating Application
× Preparing native dependencies: 6 / 7
An unhandled error has occurred inside Forge:
�b���ѨM��פ��@���ظm�@�ӱM�סC�Y�n�ҥΥ���ظm�A�зs�W "/m" �ѼơC
ursaNative.cc
win_delay_load_hook.cc
c:\users\royhsu\ipfs-desktop\node_modules\ursa-optional\src\ursanative.h(13): fatal error C1083: �L�
k�}�ҥ]�t�ɮ�: 'openssl/rsa.h': No such file or directory (���b�sĶ��l�{���� ..\src\ursaNative.cc) [C:
Users\royhsu\ipfs-desktop\node_modules\ursa-optional\build\ursaNative.vcxproj]
gyp ERR! build error
gyp ERR! stack Error: C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\15.0\B in\MSBuild.exe failed with exit code: 1
gyp ERR! stack     at ChildProcess.onExit (C:\Users\royhsu\ipfs-desktop\node_modules\node-gyp\lib\bu
ild.js:262:23)
gyp ERR! stack     at ChildProcess.emit (events.js:182:13)
gyp ERR! stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:240:12)
gyp ERR! System Windows_NT 6.1.7601
gyp ERR! command "C:\Program Files\nodejs\node.exe" "C:\Users\royhsu\ipfs-desktop\node_module
s\node-gyp\bin\node-gyp.js" "rebuild" "--target=2.0.7" "--arch=x64" "--dist-url=https://atom.io/d
ownload/electron" "--build-from-source"
gyp ERR! cwd C:\Users\royhsu\ipfs-desktop\node_modules\ursa-optional
gyp ERR! node -v v10.13.0
gyp ERR! node-gyp -v v3.8.0
gyp ERR! not ok
my environment:
os: win7
nodejs version: 10.13.0
npm version: 6.4.1
openssl version: 1.0.2p
also use npm install --global windows-build-tools
Did I miss something?
Thanks for everybody's help~~

To build on windows, you need windows-build-tools. I can assure you it will work since it's the platform I use 😄  Do not forget though that new isn't finished.


Update scala-compiler, scala-library to 2.13.10 to fix CVE

At least one commit author<EMAIL_ADDRESS>is not linked to a user. See https://help.github.com/en/articles/why-are-my-commits-linked-to-the-wrong-user#commits-are-not-linked-to-any-user


Webhook endpoint

Am I the only one with a webhook URL http://jenkins-host/ghprbhook/? (Notice the lack of jenkins in the path)

This depends on how your server is set up.  Bitnami on aws does use /jenkins,  but the work server we are running with Ubuntu doesn't.


Unnecessary Documentation: screencasts.md

ISSUE: Unnecessary Documentation in zod/docs. Documentation ( screencasts.md) contains random strings making no sense of its purpose.
PROPOSED: Removal of screencasts.md documentation from the repository.

Created Pull Request to remove screencasts.md


Great Expectations Suite Steps - getting rid of method='CSV' on sd2df

Please include answers to these questions as part of your pull request
In the GitHub webUI, use the Write tab to modify the Markdown text that is part of the pull request. For each question simply place an X inside the square brackets, [X], that represents your answer. Make sure there are no blanks inside the brackets, otherwise MarkDown doesn't render properly. Using the Preview tab while editing this form, you can see the formatted/rendered version of the message.

Q1: Confirm that you have the right to submit the code that is being contributed. Please consider the origin of your code and confirm you have the appropriate rights to make the submission subject to the Apache 2.0 license that applies to everything in this repository of custom steps. If so, follow the instructions for the Contributor Agreement (which is based on the industry-standard Developer Certificate of Origin (DCO)).

[X] Yes, I have the right to submit the contributed code on behalf of myself, my company, or any other owner of the code. I have also attached my signed copy of the DCO to this message.
[ ] No

Q2: Confirm that your contribution does not include any personally identifiable information (PII), for example, in any examples used in your README file.

[X] My contribution does NOT include PII data
[ ] My contribution includes PII data

Q3: Confirm your contribution does not include any encryption or other export-controlled technology.

[X] My contribution does NOT contain encryption or other export-controlled technology
[ ] My contribution includes encryption or other export-controlled technology

Thanks for cleaning up and simplifying the code. Also thanks for cleaning up all the temporary files on disk that are created by the Python routines. It is indeed best practice to cleanup at the end of the custom step, this includes macro variables, tables in SAS work, temporary flatfiles created by Python routines that are then read into SAS tables, etc.
Will merge the update.

SAS Internal Due Diligence Review - COMPLETED on 23OCT2023.


"and" should be omitted

First of all, this library is great.  Thank you.  I was writing a program to teach my kid to read numbers and this made that a breeze.
I think, however, you're supposed to omit the word "and" from written numbers.
See this.

Thanks, Dave. Yes, you're absolutely right. I'm not a native speaker, so didn't realize the 'and' was unnecessary. Fixed in https://github.com/divan/num2words/commit/c342fa97901369bdc545123062ea7aef26568ea7.

Awesome thanks.
On Sun, Nov 8, 2015 at 2:08 PM Ivan Daniluk<EMAIL_ADDRESS>wrote:

Thanks, Dave. Yes, you're absolutely right. I'm not a native speaker, so
didn't realize the 'and' was unnecessary. Fixed in c342fa9
https://github.com/divan/num2words/commit/c342fa97901369bdc545123062ea7aef26568ea7
.
—
Reply to this email directly or view it on GitHub
https://github.com/divan/num2words/issues/1#issuecomment-154879543.


build not create

i have create build  use npm run build command but not working any idea build file successfully working

Hi @ErNisha4800 - can you share the error message you are getting?

build file is done but not show exe application create two folder dist and  .parcel-cache
npm run build

<EMAIL_ADDRESS>build
rm -rf ./dist && rm -rf ./.parcel-cache && npx parcel build --public-url '.' index.html
'rm' is not recognized as an internal or external command,
operable program or batch file.

It looks like you are on a Windows machine, and not running under WSL (Windows Subsystem for Linux).
A couple of options:

Install WSL: https://learn.microsoft.com/en-us/windows/wsl/install
Just run npx parcel build --public-url '.' index.html instead of npm run build. This will still run the parcel build (although it won't clean up the directories).

This command is try already
npx parcel build --public-url '.' index.html
✨ Built in 6.97s
dist\index.html                                        2.5 KB     68.84s
dist\RobotoMono-VariableFont_wght.d253a266.ttf       177.9 KB     29.98s
dist\logo.85c4afc1.svg                                5.05 KB     66.89s
dist\upload.9ca0346b.svg                                325 B     66.89s
dist\drag.f08018c0.svg                                 1001 B     66.89s
dist\index.e87fef9f.css                               9.53 KB     29.99s
dist\restart.a14a3877.svg                               468 B     66.89s
dist\toggle_on.0d0ca82b.svg                             416 B     66.90s
dist\toggle_off.c1469258.svg                            414 B     66.90s
dist\fullscreen.d53ede56.svg                            202 B     66.90s
dist\vr.a808a8dc.svg                                    743 B     66.90s
dist\debug.052b56a0.svg                                 701 B     66.90s
dist\media.3f3ca70d.svg                                 342 B     66.90s
dist\delete.cef9850f.svg                                275 B     66.90s
dist\download.030d8fba.svg                              232 B     66.90s
dist\help.b1bb460c.svg                                  419 B     66.90s
dist\index.ecbbedc1.js                            ⚠  7.27 MB    130.56s
Thankyou for reply me

It looks like you are trying to open the index.html file locally, which will not work due to CORS policy.
Instead, run the server using this command:
npx parcel serve index.html -p 55000
Once the server is running, browse to http://localhost:55000 (make sure this is http and not https) - and this should work.


Rename legacy roles to Roles

Related to https://github.com/ansible-community/community-topics/issues/272
Change Legacy Roles & Legacy Namespaces to Roles & Namespaces,
add /ui/standalone/roles and /ui/standalone/namespaces (but also support old /ui/legacy/... for now).

This is great, thanks for doing this so quickly @himdel !

Any time :)
Updated Roles > Namespaces to Roles > Role Namespaces to reflect discussion in https://github.com/ansible-community/community-topics/issues/272.
(Now I just need to fix tests to cope with Roles > Roles and Access > Roles being a different thing :).)


bug: modern ECMAScript syntax not supported by recast

Recast uses Esprima by default as its parser. As you can see in https://npm.im/esprima, its last version was published 4 years ago. It doesn't support modern ECMAScript syntax like optional chaining and nullish coalescing operators.
Because of that, I was getting the error Error during compilation! Set skipOptimize to true to fix this problem. in a bunch of files in my project.
I was able to fix it by patching vite-plugin-million (with https://npm.im/patch-package) at https://github.com/aidenybai/million/blob/main/packages/vite-plugin-million/plugin.ts#L60 to use Espree (which does support modern ECMAScript syntax) instead of Esprima:
-          const ast = parse(code);
+          const ast = parse(code, {
+            parser: {
+              parse(source, options) {
+                return espree.parse(source, {
+                  ...options,
+                  ecmaVersion: "latest"
+                });
+              }
+            }
+          });

PS: I'm not following the issue template because I'm in a hurry, but I hope my explanation is enough.

Interesting find! Would you like to PR this fix? If not, no worries :)

Unfortunately not, very busy here with work already.


add using smi-adapter-istio to smi-spec.io?

There is a website/landing page at smi-spec.io that talks about the spec but doesn't mention any implementations. Do we want to start adding links to the website around how to use SMI with Istio and other providers?

When merged, https://github.com/servicemeshinterface/smi-spec.io/pull/7 will provide more visibility into available implementations.


🎃 Simplify and unify gitignore

[!WARNING]
This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

#21  👈
#12 : 1 other dependent PR (#20 )
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @MiksuJak and the rest of your teammates on  Graphite


add desired replication factor option

for situation in which you want to increase replication factor on a topic, besides moving partitions amond nodes

Thanks for the contribution!

This change (and this project in general) is very helpful. Would you consider uploading a new tarball release?

Cool! FWIW I found #6 to be necessary as well.
It's hard for me to believe that this isn't just how kafka-reassign-partitions.sh works by default!

Hi @glasser, thanks for your interest in kafka-assigner! I have created a new release 1.1, which includes this PR.
-Eugene

I will also release a 1.2 which includes #6.


PatternMatching

Line 65 under the TODO works, so it can be re-enabled, #25 was merged:
# TODO: reenable line below when roc-lang/examples/issues/25 is fixed
# && (patternMatch [Foo, Bar, Baz, Barry] != Bingo)

Thanks @Ivo-Balbaert, I updated the code


Two occurrences of the whitespace dots have different meanings

Description
In the editor, one dot is one whitespace, three whitespaces are three dots, and so on.
In the grid result set, one whitespace dot seems to have a different meaning.
New dots only appear with an odd number of whitespaces. With an even number, only a little more space is added to the right of the dot.
I like the editor variant better because it is easier to count spaces, but in general, I would like it better if both editor and grid result would be consistent and would display the whitespace dots the same way.
DBeaver Version
CE Version <IP_ADDRESS>308201919
Operating System
macOS 13.5
Database and driver
No response
Steps to reproduce

Enable showing whitespaces in editor and grid result.
Compare whitespace dots in editor and result

select ' abc'
union
select '  abc'
union
select '   abc'
union
select '    abc'
union
select '     abc'
union
select '      abc'
order by 1 desc;

Additional context
No response

Hello @marcelmore,
Thanks for the bug report.


Latexify AbstractSingleBosonOp instead of AbstractSingleBosonGate

Fixes latexify of expressions containing subtypes of AbstractSingleBosonOp such as NumberOp, CreateOp, DestroyOp.
Relatedly it doesn't look like AbstractSingleBosonGate is used anywhere, and the comment seems like it may be outdated since it seems like implementing isunitary is the way such checks are handled?

yup, we do have some outdated types that we should probably just drop
Thanks for the fix!


LSM6DSL: Isse with spi_config

Seems that since recent SPI API update, spi_config as lost dev element.
In LSM6DSL new SPI interface is not in line: in lsm6dsl_spi_init
	lsm6dsl_spi_conf.dev = data->comm_master;
This should be reviewed

@avisconti , can you have a look?

Ah, seems like I forgot that one when rebasing to add dev parameter again to spi functions. I can fix that

Ah, seems like I forgot that one when rebasing to add dev parameter again to spi functions.
I can fix that

@tbursztyka
OK, good. I was looking into that, but for you it is definitely easier, as you know the SPI API evolution