docker2singularity
docker2singularity copied to clipboard
Not Outputting Final Image
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?
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).
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.
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!
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.
Oh interesting—I see! Thanks for the info!