# Mender standalone installation progress last few percent very long

**URL:** <https://hub.mender.io/t/mender-standalone-installation-progress-last-few-percent-very-long/1464>\
**Category:** General Discussions\
**Tags:** sumo\
**Created:** [January 22, 2020, 5:22pm UTC](https://hub.mender.io/t/mender-standalone-installation-progress-last-few-percent-very-long/1464 "2020-01-22T17:22:11Z")\
**Posts on this page:** 11\
**Page:** 1

<div class="post-metadata">

**Author:** ![dellgreen](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/dellgreen/32/85_2.png) [@dellgreen](https://hub.mender.io/u/dellgreen)\
**Post date:** [January 22, 2020, 5:22pm UTC](https://hub.mender.io/t/mender-standalone-installation-progress-last-few-percent-very-long/1464/1 "2020-01-22T17:22:11Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![kacf](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/kacf/32/146_2.png) [@kacf](https://hub.mender.io/u/kacf)\
**Post date:** [January 23, 2020, 7:10am UTC](https://hub.mender.io/t/mender-standalone-installation-progress-last-few-percent-very-long/1464/2 "2020-01-23T07:10:53Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![dellgreen](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/dellgreen/32/85_2.png) [@dellgreen](https://hub.mender.io/u/dellgreen)\
**Post date:** [January 23, 2020, 8:03am UTC](https://hub.mender.io/t/mender-standalone-installation-progress-last-few-percent-very-long/1464/3 "2020-01-23T08:03:57Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![dellgreen](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/dellgreen/32/85_2.png) [@dellgreen](https://hub.mender.io/u/dellgreen)\
**Post date:** [January 23, 2020, 8:16am UTC](https://hub.mender.io/t/mender-standalone-installation-progress-last-few-percent-very-long/1464/4 "2020-01-23T08:16:18Z")

</div>

Could bmaptool or equivalent algorithm be used to speed up the imaging, if its not being used already?

---

<div class="post-metadata">

**Author:** ![dellgreen](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/dellgreen/32/85_2.png) [@dellgreen](https://hub.mender.io/u/dellgreen)\
**Post date:** [January 23, 2020, 8:21am UTC](https://hub.mender.io/t/mender-standalone-installation-progress-last-few-percent-very-long/1464/5 "2020-01-23T08:21:50Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![kacf](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/kacf/32/146_2.png) [@kacf](https://hub.mender.io/u/kacf)\
**Post date:** [January 27, 2020, 8:32am UTC](https://hub.mender.io/t/mender-standalone-installation-progress-last-few-percent-very-long/1464/6 "2020-01-27T08:32:32Z")

</div>

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](https://docs.mender.io/2.2/devices/update-modules).

---

<div class="post-metadata">

**Author:** ![dellgreen](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/dellgreen/32/85_2.png) [@dellgreen](https://hub.mender.io/u/dellgreen)\
**Post date:** [January 27, 2020, 8:52am UTC](https://hub.mender.io/t/mender-standalone-installation-progress-last-few-percent-very-long/1464/7 "2020-01-27T08:52:37Z")

</div>

ok, thanks for getting back to me. 🙂

---

<div class="post-metadata">

**Author:** ![dellgreen](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/dellgreen/32/85_2.png) [@dellgreen](https://hub.mender.io/u/dellgreen)\
**Post date:** [January 27, 2020, 9:21am UTC](https://hub.mender.io/t/mender-standalone-installation-progress-last-few-percent-very-long/1464/8 "2020-01-27T09:21:17Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![kacf](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/kacf/32/146_2.png) [@kacf](https://hub.mender.io/u/kacf)\
**Post date:** [January 29, 2020, 7:24am UTC](https://hub.mender.io/t/mender-standalone-installation-progress-last-few-percent-very-long/1464/9 "2020-01-29T07:24:49Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![dellgreen](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/dellgreen/32/85_2.png) [@dellgreen](https://hub.mender.io/u/dellgreen)\
**Post date:** [January 29, 2020, 8:03am UTC](https://hub.mender.io/t/mender-standalone-installation-progress-last-few-percent-very-long/1464/10 "2020-01-29T08:03:33Z")

</div>

ok, thank you for the reply

---

<div class="post-metadata">

**Author:** ![tpiepho](https://avatars.discourse-cdn.com/v4/letter/t/e9a140/32.png) [@tpiepho](https://hub.mender.io/u/tpiepho)\
**Post date:** [March 28, 2020, 12:25am UTC](https://hub.mender.io/t/mender-standalone-installation-progress-last-few-percent-very-long/1464/11 "2020-03-28T00:25:33Z")

</div>

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.
