Using mender install in standalone mode, on the stdout the first 0-99% takes 3 mins and then I’m seeing a further 3 mins to get from 99% to 100%. Is there some kind of verification phase happening causing the duplication of time, as there is no progress state change during this last percent to indicate what is happening
The percentage is based on the artifact size (the download size, if you’re using a link and not a local file), not the size of the contained rootfs. So presumably your artifact has a filesystem with a lot of free space at the end, which compresses extremely well, and therefore the last 1% contains a large section of nulls, which take time to write, but take up almost no space in the artifact.
Ah I see, thanks for the answer. I don’t know what library you are using to write the artifact to the partition, but Is there scope to interleave installing blocks with progress updates to give a more accurate progress?
Could bmaptool or equivalent algorithm be used to speed up the imaging, if its not being used already?
Even simpler, given that the artifact in my case contains a .ext4 file, would it not be better to use the uncompressed artifact size for progress?
It’s difficult for technical reasons: The size of the contained payload is not known when the artifact reading starts, this information only becomes available when the reader hits the internal tar file which contains the ext4 file. With the planned multiple-payload support, there may be several of these after one another which becomes even more difficult to report.
I haven’t looked into it in detail, but your proposed bmaptool might be a good solution, and would reduce writing need in general. I suggest trying to implement this as an Update Module.
ok, thanks for getting back to me. 
I wonder in reference to the multiple-payload support planning, whether some time could/should be allocated to changing the progress feedback pipeline process to more accurately reflect an installation stage for each payload each with their progress with an additional progress to reflect how many installation stages there are basd on how many payload are contained in the artifact?
There are still many unknowns, so I cannot really comment concretely on that, but it’s definitely something to keep in mind. The apt progress bar is perhaps a good example of how it can be done well.
ok, thank you for the reply
Can’t you just put the uncompressed size in the header.tar.gz file? Surely that must be processed first, otherwise how do you know what to do with the images or how to check if the device type is compatible.