This is what I see from the output:
mender-artifact version a530ec0
And I have been using Mender since four months, And I followed this article,
https://docs.mender.io/hosted/downloads
So, It must be new one.
I shall try updating the mender-artifact also then , and I’ll give a try.
But I was using this mender-artifact for all my previous releases, using single file, directory update module.
@nishad1092 That is the problem: you are using a buggy mender-artifact. You must have build it locally or get confused somehow…
I manually built the one you are pointing to (git sha a530ec0) and get the exact same error as you (Required flag " f" not set).
From https://docs.mender.io/hosted/downloads you will always download the latest mender-artifact, and when you run --version on it you must have a tag, not a git hash. For example:
$ mender-artifact --version
mender-artifact version 3.4.0
Please download mender-artifact again and retry.
And for future reference, make sure you use verified versions of our tools.
Sure @lluiscampos ,
I will make sure all versions are correct.
But wondering how the system ended up having buggy mender-artifact, and if that is the case how did it work for this long with other update modules,
See, if it had issues with other modules also, then I would have understood to upgrade the mender-artifact. anyways ill do it asap.
When I deploy the release with the docker module, do I need to docker login to my remote device too?
Hi @lluiscampos
I just want to update,
So The deployment is successful and it downloaded the docker image in the remote device:
But there were two concerns,
firstly, the image had no tag, it was shown ,
secondly, the docker container didnt run, it failed, but it also made the running container failed, ( I guess the issue might be that I’m passing a volume while docker run in the running container, so maybe while deploying thru mender, it isn’t replacing the new container with the previous containers docker run passing arguements) - so I guess the rollback mechanism isn’t working here.
Is it possible to fix these two issues?
Hi @nishad1092
But wondering how the system ended up having buggy mender-artifact
This bug only affected Artifacts with no files (i.e. docker Update Module). Hence it has gone unnoticed. I also wonder how you compiled a random version…
firstly, the image had no tag, it was shown ,
??
secondly, […] might be that I’m passing a volume while docker run in the running container
The module does not handle any kind of parameters. It only does docker stop on the running containers and docker run -dt with the new images. See the source code. You probably need to write your own module for this.
Hi @lluiscampos,
-
I meant after deploying the image to the device, the image got pulled but didn’t have the tag i wanted which Im compiling using
DOCKER_IMAGES=“0.azurecr.io/cam/local:4.0.1”
instead it came as,
So this has to be resolved, otherwise I cant update the tags.Because it didnt update with the tag name, It failed to start\ even if I want to deploy script module to start docker, the tag has come as “none” -
Sure, Instead I was thinking I’ll update docker using this module and I can pass docker run -volume using script module. But then wonder how to previous container didnt rollback to the previous running state when this failed.
Hi @nishad1092
-
That is expected. The docker update module passes Docker digests/SHAs, not tags. See the source code.
-
Combining two Update Modules that way seems complicated. If any, would be better to add an State Script to your Docker Update Module Artiafct, so that it can be executed during the update. Alternatively, and given that you seem to prefer using tags, I encourage you to write your own module instead
1 Like
sure @lluiscampos i just wanted to confirm about the tags that it isnt happening just for me but thats how the module is written, I’ll see the source code.
@lluiscampos Brilliant work, I just wanted to say, how easy that updates.