search

ukontainer / dockerd-darwin

Moby Project - a collaborative project for the container ecosystem to assemble container-based systems
https://mobyproject.org/
Apache License 2.0
6 stars 0 forks source link

cannot run alpine image #10

Closed thehajime closed 5 years ago

thehajime commented 5 years ago

while we can run thehajime/runu-base:0.1 image, I can't with alpine:latest while ctr can.

% docker -H tcp://127.0.0.1:3939 run --rm -e UMP_VERBOSE=1  --runtime=runu-dev --platform=linux/amd64 --net=none  alpine:latest uname -a
Unable to find image 'alpine:latest' locally
latest: Pulling from library/alpine
docker: operating system is not supported.
See 'docker run --help'.
Aniketh01 commented 5 years ago

Is this the command you used to test alphine with ctr? ctr --debug -a /tmp/ctrd/run/containerd/containerd.sock \ run --fifo-dir /tmp/ctrd --env RUMP_VERBOSE=1 \ --env RUNU_AUX_DIR=$RUNU_AUX_DIR --env LKL_USE_9PFS=1 \ docker.io/library/alpine:latest alpine1 /bin/busybox ls -l

thehajime commented 5 years ago

Is this the command ?

yes

Aniketh01 commented 5 years ago

I was looking at the cause of this bug. It wasn't able to pass the OS supported or not condition. So, I added a small line to fix it. Now it pulls/downloaded properly.

This is the function call to register the image that has been downloaded with the layer store: https://github.com/ukontainer/dockerd-darwin/blob/darwin-port/distribution/xfer/download.go#L169

In this call, it seems rootFS.ChainID() is empty. I think we need to fill that?

thehajime commented 5 years ago

i'm not sure, but it sounds right.

but why runu-base:0.1 can be downloaded while we cannot alpine is still questionable.

Aniketh01 commented 5 years ago

I was looking into this issue: Currently I am letting this check passed IsOSSupported(). But once that is the done, the image/layers are getting downloaded, but I end up with such an error:

DEBU[2019-07-23T16:56:40.202393000+09:00] Downloaded 050382585609 to tempfile /private/var/lib/docker/tmp/GetImageBlob465682208 panic: runtime error: invalid memory address or nil pointer dereference [signal SIGSEGV: segmentation violation code=0x1 addr=0x58 pc=0x101238fad]

goroutine 125 [running]: github.com/docker/docker/distribution/xfer.(LayerDownloadManager).makeDownloadFunc.func1.1(0xc0008de660, 0xc0008de540, 0x1023efe80, 0xc000c6e0b0, 0x0, 0xc00020bb00, 0xc000161d80, 0xc0008de600, 0xc000c739e0) /Users/aniketh/go/src/github.com/docker/docker/distribution/xfer/download.go:351 +0xffd created by github.com/docker/docker/distribution/xfer.(LayerDownloadManager).makeDownloadFunc.func1 /Users/aniketh/go/src/github.com/docker/docker/distribution/xfer/download.go:233 +0x1ac

Is it because of the failure to read/write into this file /private/var/lib/docker/tmp/GetImageBlob465682208?

Aniketh01 commented 5 years ago

The above error is since the ldm.layerStores[os] is empty: https://github.com/ukontainer/dockerd-darwin/blob/darwin-port/distribution/xfer/download.go#L230 and henceforth d.layerStore is nil.

In linux these are the items filled in d.layerStore while using vfs as the graphdriver: &{%!s(layer.fileMetadataStore=&{/var/lib/docker/image/vfs/layerdb}) %!s(graphdriver.NaiveDiffDriver=&{0xc0008351a0 [] []}) %!s(bool=true) map[] {%!s(int32=0) %!s(uint32=0)} map[] {%!s(int32=0) %!s(uint32=0)} %!s(*locker.Locker=&{{0 0} map[]}) linux}

Aniketh01 commented 5 years ago

I suspect this to be originating from the graph driver, vfs as it is not able to deflate the image to bundle properly and fill in the layer store.

thehajime commented 5 years ago

I tentatively push a commit to work around this issue. let's go back again and reopen this issue once we found nicer/proper fix.