docker: Error response from daemon: failed to create shim task: OCI runtime create failed: failed to create lib container mount: failed to stat mount source

[Eason0729]

I am attempting to run ubuntu-focal-systemd on raspberry pi 4 model b, but it didn't work, and hello-world didn't work neither.

~ docker run --runtime=sysbox-runc --rm hello-world                                                                                             0 [18:09:04]
docker: Error response from daemon: failed to create shim task: OCI runtime create failed: failed to create lib container mount: failed to stat mount source at /var/lib/sysboxfs/878f5e271ee51b3f594e16cac91ad060d68eddf0159e0c25811fc95e1dc0ae7a/sys/devices/virtual/dmi/id/product_uuid: stat /var/lib/sysboxfs/878f5e271ee51b3f594e16cac91ad060d68eddf0159e0c25811fc95e1dc0ae7a/sys/devices/virtual/dmi/id/product_uuid: no such file or directory: unknown.

I got a clean install of sysbox so I got no clue of why it didn't work.

Release v0.5.2 docker: 20.10.17 Ubuntu 20.04.4 LTS (arm64) kernel: 5.4.0

[ctalledo]

Hi @Eason0729, thanks for giving Sysbox a shot!

We've not tried it on Raspberry pi yet, so I am not surprised it did not work.

However the failure is simple: Sysbox is looking for /sys/class/dmi/id/product_uuid file but did not find it on your Linux host.

We are actually working right now to relax this requirement on Sysbox, so a fix should be coming soon. In the meantime you can try to investigate if there is a way to configure you machine's BIOS to provide this info.

Hope that helps!

[Eason0729]

I just realized that raspberry pi doesn't have a BIOS, and it boots with GPU bootloader instead of BIOS.

Thus, I am unable to solve the problem.

Thank for you help.

[ctalledo]

Thus, I am unable to solve the problem.

Thanks @Eason0729, that's too bad. Please be on the look out because the next release of Sysbox will likely relax the host product_uuid requirement, and may allow you to bypass the problem you faced.

Thanks again for giving Sysbox a shot.

[rodnymolina]

@Eason0729, just to let you know that we have just merged changes to address this problem that you reported above. They will be part of our next release, but if you wish, you can give it a try now by building Sysbox binaries yourself. Hope it helps! Thanks.

[Eason0729]

It seems like that building from source in arm64 requires some docker images which don't support arm64. As the result, I follow the guideline and cross compile from source in x86_64 pc, then copy the entire directory to raspberry pi(arm64). Finally, run docker-cfg and make install in raspberry pi. Ultimately, I fall to get it work on raspberry pi. What's wrong in the steps of cross compiling from source?

Here is detail of the script I executing.

On x86_64 :

~ git clone https://github.com/nestybox/sysbox.git
~ cd sysbox
~ git submodule update --recursive --remote --init --force
~ make sysbox TARGET_ARCH=arm64
~ scp -r ./* _______ #dist

On raspberry pi (arm64):

~ sudo ./scr/docker-cfg --sysbox-runtime=enable
~ sudo make
find: ‘/usr/src/linux-headers-5.15.56-v8+’: No such file or directory
Error: either "dev" is duplicate, or "eth0" is a garbage.
<a list of make usage>

Folder /usr/src/linux-headers-5.15.61-v8+ exist

Also of note, I cross compile it on ubuntu on wsl2 with "docker desktop WSL Integration enable". It should act like the normal docker, but may be lack of support on the kernel feature.

By the way, in this case, should I open a new issue about building from source?

[Eason0729]

The previous comment is probably related to version, not related to sysbox itself, but after I solve it, I get a error message similar to the original one.

I solve part of the problems by...

1. create symlink from /usr/src/linux-headers-5.15.61-v8+ to /usr/src/linux-headers-5.15.56-v8+
2. start sysbox-fs and sysbox-mgr manually

And I get the message similar to the original one on the console:

sudo docker run --runtime=sysbox-runc --rm hello-world
docker: Error response from daemon: failed to create shim task: OCI runtime create failed: failed to create lib container mount: failed to stat mount source at /var/lib/sysboxfs/21a886cefdcc1dfe7a533b1bb179d4f8b449e54b3a4b5f922cd0fafc247c9d35/sys/devices/virtual/dmi/id: stat /var/lib/sysboxfs/21a886cefdcc1dfe7a533b1bb179d4f8b449e54b3a4b5f922cd0fafc247c9d35/sys/devices/virtual/dmi/id: no such file or directory: unknown.

What the right way to cross compiling from source and install? Creating symlink and starting manually don't seems to be the right way.

[rodnymolina]

Hi @Eason0729, please see below...

It seems like that building from source in arm64 requires some docker images which don't support arm64.

The problem here is not with arm64, but with the linux-distro that you are running in your raspberry-pi specifically. Which distro-release is that? Please see that these (below) are the linux distro-releases supported for this purpose (building Sysbox). Even if you're running one of these supported distros, there could be a raspberry-pi-specific issue that we haven't detected as we haven't used this platform for dev-testing yet.

$ ls -lrt tests/Dockerfile* | awk '{print $9'}
tests/Dockerfile.ubuntu-jammy
tests/Dockerfile.ubuntu-impish
tests/Dockerfile.ubuntu-focal
tests/Dockerfile.ubuntu-bionic
tests/Dockerfile.systemd.ubuntu
tests/Dockerfile.systemd.debian
tests/Dockerfile.rocky-8
tests/Dockerfile.flatcar
tests/Dockerfile.fedora-34
tests/Dockerfile.fedora-33
tests/Dockerfile.fedora-32
tests/Dockerfile.fedora-31
tests/Dockerfile.debian-buster
tests/Dockerfile.debian-bullseye
tests/Dockerfile.centos-8
tests/Dockerfile.almalinux-9
tests/Dockerfile.almalinux-8

What the right way to cross compiling from source and install?

In regards to x-compilation, I think you are already doing the right things. I suspect this is a raspberry-pi specific issue. Question: from your raspberry-pi console, do you see any of the dir elements in this path:

ls -l /sys/devices/virtual/dmi/id
ls -l /sys/devices/virtual/dmi
ls -l /sys/devices/virtual
ls -l /sys/devices

Also of note, I cross compile it on ubuntu on wsl2 with "docker desktop WSL Integration enable". It should act like the normal docker, but may be lack of support on the kernel feature.

Yes, WSL2 isn't officially supported as a dev-platform either, it may be soon, but not yet.

Thanks.

[Eason0729]

In regards to x-compilation, I think you are already doing the right things. I suspect this is a raspberry-pi specific issue. Question: from your raspberry-pi console, do you see any of the dir elements in this path:

For both Raspberry Pi OS(raspbian) and ubuntu jammy, /sys/devices/virtual exists, but /sys/devices/virtual/dmi doesn't exist.

Raspberry Pi Os

~ ls -l /sys/devices
drwxr-xr-x  3 root root 0 Sep  1 22:26 bcm2835-gpiomem
drwxr-xr-x 27 root root 0 Sep  1 22:26 bdi
drwxr-xr-x 26 root root 0 Sep  1 22:26 block
drwxr-xr-x 25 root root 0 Sep  1 22:26 devlink
drwxr-xr-x  4 root root 0 Sep  1 22:26 dma_heap
drwxr-xr-x  3 root root 0 Sep  1 22:26 graphics
drwxr-xr-x  3 root root 0 Sep  1 22:26 input
drwxr-xr-x  4 root root 0 Sep  1 22:26 leds
drwxr-xr-x 10 root root 0 Sep  1 22:26 mem
drwxr-xr-x 13 root root 0 Mar 21 03:55 misc
drwxr-xr-x 64 root root 0 Sep  1 22:26 net
drwxr-xr-x  3 root root 0 Sep  1 22:26 sound
drwxr-xr-x  3 root root 0 Sep  1 22:26 thermal
drwxr-xr-x 70 root root 0 Mar 21 03:55 tty
drwxr-xr-x 23 root root 0 Sep  1 22:26 vc
drwxr-xr-x  3 root root 0 Sep  1 22:26 vc-mem
drwxr-xr-x  3 root root 0 Sep  1 22:26 vtconsole
drwxr-xr-x 10 root root 0 Sep  1 22:26 workqueue

Ubuntu

~ ls -l /sys/devices
drwxr-xr-x   3 root root 0 Apr 19 10:12 bcm2835-gpiomem
drwxr-xr-x  11 root root 0 Jan  1  1970 bdi
drwxr-xr-x  10 root root 0 Jan  1  1970 block
drwxr-xr-x  28 root root 0 Jan  1  1970 devlink
drwxr-xr-x   4 root root 0 Jan  1  1970 dma_heap
drwxr-xr-x   3 root root 0 Jan  1  1970 graphics
drwxr-xr-x   3 root root 0 Jan  1  1970 input
drwxr-xr-x  10 root root 0 Jan  1  1970 mem
drwxr-xr-x  17 root root 0 Jan  1  1970 misc
drwxr-xr-x  11 root root 0 Jan  1  1970 net
drwxr-xr-x   3 root root 0 Jan  1  1970 powercap
drwxr-xr-x   3 root root 0 Jan  1  1970 ppp
drwxr-xr-x   3 root root 0 Apr 19 10:12 rpivid-h264mem
drwxr-xr-x   3 root root 0 Apr 19 10:12 rpivid-hevcmem
drwxr-xr-x   3 root root 0 Apr 19 10:12 rpivid-intcmem
drwxr-xr-x   3 root root 0 Apr 19 10:12 rpivid-vp9mem
drwxr-xr-x   3 root root 0 Apr 19 10:12 sound
drwxr-xr-x   3 root root 0 Jan  1  1970 thermal
drwxr-xr-x 582 root root 0 Jan  1  1970 tty
drwxr-xr-x  23 root root 0 Jan  1  1970 vc
drwxr-xr-x   3 root root 0 Jan  1  1970 vc-mem
drwxr-xr-x   3 root root 0 Jan  1  1970 vtconsole
drwxr-xr-x   9 root root 0 Jan  1  1970 workqueue
total 0

[rodnymolina]

@Eason0729, just to let you know that we have just merged a few changes that are expected to fix this last issue that you ran into with raspberry-pi and, in general, platforms that don't fully support SMBIOS/DMI tables (which is ultimately the reason you don't see the /sys/devices/virtual/dmi path in your machines). Please, build sysbox from sources again and let us know if this fixes your issue.

Thanks.

[Eason0729]

It work on hello-world image, I will test ubuntu-focal-systemd after building docker image. Thank for you help.