img unpack -o option is ignored

[rstyd]

I tried unpacking an image using: img unpack hello_img -o hello

The output was: Successfully unpacked rootfs for hello_img to: /home/rusty/test_containers/rootfs

The output directory was still named rootfs. The --output parameter behaved exactly the same way.

I looked at img/unpack.go, and it looks like the cmd.output variable isn't actually being set.

Thanks!

[westonsteimel]

I believe you have to do img unpack -o hello hello_img See #149 It has to do with how the go flag package works

[rstyd]

Ah, cool! That does set the cmd.output variable, but img unpack -o hello hello_img then hangs. https://github.com/genuinetools/img/blob/adf8197ba89a817df11533c8a6abb86588e0e139/unpack.go#L45-L52 It looks like cmd.output is only a path to the directory if there is no parameter passed. It's just sending hello to the unpack function.

[jessfraz]

the integration tests are succeeded so I don't really understand the problem can you explain more.

[rstyd]

That's really odd. On my Ubuntu 18.04 box, using img unpack -o img-unpack/rootfs testbuildunpack with an image built use the same Dockerfile as in your test just freezes.

rusty@cannonball:~/charliecloud/test$ img build -t testbuildunpack .
Building docker.io/library/testbuildunpack:latest
Setting up the rootfs... this may take a bit.
[+] Building 0.7s (6/6) FINISHED
 => [internal] load build definition from Dockerfile                                                                                                  0.0s
 => => transferring dockerfile: 67B                                                                                                                   0.0s
 => [internal] load .dockerignore                                                                                                                     0.0s
 => => transferring context: 2B                                                                                                                       0.0s
 => [internal] load metadata for docker.io/library/busybox:latest                                                                                     0.7s
 => [1/2] FROM docker.io/library/busybox@sha256:7964ad52e396a6e045c39b5a44438424ac52e12e4d5a25d94895f2058cb863a0                                      0.0s
 => => resolve docker.io/library/busybox@sha256:7964ad52e396a6e045c39b5a44438424ac52e12e4d5a25d94895f2058cb863a0                                      0.0s
 => CACHED [2/2] RUN  echo unpack                                                                                                                     0.0s
 => exporting to image                                                                                                                                0.0s
 => => exporting layers                                                                                                                               0.0s
 => => exporting manifest sha256:f3e88bfec257dc301c9a5948fb0d6c7fdbf1d29e6504eca95a504415405ce577                                                     0.0s
 => => exporting config sha256:1daed1e8e6051d6b95cfbff79f77aea7c1cbe796b0d4318c1d74ec515f357e75                                                       0.0s
 => => naming to docker.io/library/testbuildunpack:latest                                                                                             0.0s
Successfully built docker.io/library/testbuildunpack:latest
rusty@cannonball:~/charliecloud/test$ img unpack -o img-unpack/rootfs testbuildunpack 
(It stops here)

I tried tracing exactly where it was stuck, but I could not find it.

[pwFoo]

Looks like the option / image order with img unpack is important.

img unpack -o <dir> <image> works fine, but option is ignored if given after the image img unpack <image> -o <dir>