docker2singularity icon indicating copy to clipboard operation
docker2singularity copied to clipboard

Not Outputting Final Image

Open mkwbritton opened this issue 4 years ago • 5 comments

Running Docker 19.03.5 on macOS 10.14.6. When I run docker2singularity with the following code, everything looks right, but no Singularity image is output anywhere on my system:

docker run \ -v /var/run/docker.sock:/var/run/docker.sock \ -v \Users\my\path\to\folder:/output \ --privileged -t --rm \ singularityware\docker2singularity \ mypackage:version

I get the following output: `Image Format: squashfs Docker Image: brainkey/brainage-standalone:bk-brainage-preproc

Inspected Size: 1712 MB

(1/10) Creating a build sandbox... (2/10) Exporting filesystem... (3/10) Creating labels... (4/10) Adding run script... (5/10) Setting ENV variables... (6/10) Adding mount points... (7/10) Fixing permissions... (8/10) Stopping and removing the container... (9/10) Building squashfs container... INFO: Starting build... INFO: Creating SIF file... INFO: Build complete: /tmp/brainkey_brainage-standalone_bk-brainage-preproc-2019-12-11-b1bd81913114.simg (10/10) Moving the image to the output folder... 765,931,520 100% 247.94MB/s 0:00:02 (xfr#1, to-chk=0/1) Final Size: 731MB`

A search through my full system doesn't turn up a .simg. What's the issue?

mkwbritton avatar Jan 29 '20 18:01 mkwbritton

The output would appear where you bound it, the volume specified as

-v \Users\my\path\to\folder:/output

Is that the correct direction of slashes for a Mac (I had thought only Windows went the other way). Once you figure out the output directory, the extension you are looking for is .sif (.simg was for previous ext3 filesystem, sif is for a squashfs binary).

vsoch avatar Jan 29 '20 18:01 vsoch

But looking at your logs, it looks like it's still generating simg:

INFO: Build complete: /tmp/brainkey_brainage-standalone_bk-brainage-preproc-2019-12-11-b1bd81913114.simg

so it's likely an issue that your output folder path is a bit weird.

vsoch avatar Jan 29 '20 18:01 vsoch

I ran into the same thing as @mkwbritton on Ubuntu when I bind the /output volume to a relative path rather than an absolute one. Changing my path to an absolute one fixed this for me. Just thought I'd chime in!

LiamBindle avatar Nov 03 '20 18:11 LiamBindle

Thanks @LiamBindle ! I think I've run into this as well, but for different containers. E.g., let's say I have a folder "data" in my present working directory. I might start by doing:

docker run --volume data:/output <container>

But actually, for the above Docker might think we want a named volume "data" So I usually need to do something like:

docker run --volume $PWD/data:/output <container>

So it's obviously a path. You could also do:

docker run --volume ./data:/output <container>

The difference I would suspect is specifying a named volume vs. an actual path volume, an example is written out here https://nickjanetakis.com/blog/docker-tip-28-named-volumes-vs-path-based-volumes. For kicks and giggles, you might want to look at your Docker volumes after trying the command that doesn't seem to work, it could be that your final container is saved to a named volume after all.

vsoch avatar Nov 03 '20 19:11 vsoch

Oh interesting—I see! Thanks for the info!

LiamBindle avatar Nov 04 '20 02:11 LiamBindle