TorizonCore-builder --storage-directory not accepted

torizoncore-builder --storage-directory won’t accept absolute location but requires absolute location when doing image unpack?
--------------------------------------------------------------- terminal session ------------------
$ cd tcbworkdir-imx6-5.1-build-test-0.0/
$ source tcb-env-setup.sh
You may have an outdated version installed. Would you like to check for updates online? [y/n] y
Setting up TorizonCore Builder with version 3.

Pulling TorizonCore Builder…
3: Pulling from torizon/torizoncore-builder
Digest: sha256:a6695866ca3f74a8350e7e9b2955c5c09363390b6b4f91a2d629573a8d737035
Status: Image is up to date for torizon/torizoncore-builder:3
docker.io/torizon/torizoncore-builder:3
Done!

Setup complete! TorizonCore Builder is now ready to use.


Important: When you run TorizonCore Builder, the tool can only access the files inside the current working directory. Files and directories outside of the current working directory, or links to files and directories outside of the current working directory, won’t be visible to TorizonCore Builder. So please make sure that, when running TorizonCore Builder, all files and directories passed as parameters are within the current working directory.
Your current working directory is: /home/deltamike/tcbworkdir-imx6-5.1-build-test-0.0


For more information, run ‘torizoncore-builder -h’ or go to TorizonCore Builder Tool - Customizing TorizonCore Images | Toradex Developer Center
$
$
$ ls
test-systems-config-0.0 storage tcb-env-setup.sh torizon-core-docker-apalis-imx6-Tezi_5.1.0+build.1.tar

$ torizoncore-builder --storage-directory storage images unpack torizon-core-docker-apalis-imx6-Tezi_5.1.0+build.1.tar
error: storage directory ‘storage’ is not absolute.
$
$
$ torizoncore-builder --storage-directory /home/deltamike/tcbworkdir-imx6-5.1-build-test-0.0/storage images unpack torizon-core-docker-apalis-imx6-Tezi_5.1.0+build.1.tar
error: storage directory ‘/home/deltamike/tcbworkdir-imx6-5.1-build-test-0.0/storage’ does not exist.

$ ls -ld /home/deltamike/tcbworkdir-imx6-5.1-build-test-0.0/storage
drwxrwxr-x 2 deltamike deltamike 4096 Jun 30 19:54 /home/deltamike/tcbworkdir-imx6-5.1-build-test-0.0/storage
~

Greetings @deltamike,

I was able to reproduce this strange behavior on my end. The --storage-directory argument is not often used, so perhaps something changed recently that affected this argument and has gone overlooked. I’ll report this internally and we’ll investigate.

In the meantime could you share why you’re using the --storage-directory? By default a docker volume named storage is used. Does this not work for your uses? Or rather what’s your use-case here?

Best Regards,
Jeremias

Sure - The rationale was to get the customizations in /etc under configuration control. Back when we were using the open-embedded/BSP approach we had that, though various /etc/ files came from different places in our custom layer, so a little harder to track. Using torizoncore-builder now I had been mirroring /etc in a development code repo, so I was happy to see that the contents of the storage directory had the /usr/etc version of that. On a related topic, I notice that I will have to change /etc/issue to provide a tag or some identifier to show which version of /etc customizations was in use for that image.

That all sounds good, but I still don’t see how this requires the usage of the --storage-directory argument.

If you want to check in the tool’s storage into a repo you can just access the default storage. Docker volumes are stored on the host machine, you can see the location via docker volume inspect storage. At least this way you can progress while we investigate the issues with --storage-directory.

Or am I misunderstanding your use case?

Thanks, that sounds like a better approach, I’ll check it out.

Please let me know how this works out for you. Also as an update we have planned in our backlog to improve usage of --storage-directory to improve it and make it more intuitive to use.

Best Regards,
Jeremias