Which would seem like it is writing the artifact to the “inactive partition”. In this example, the progress bar goes from 0% to 100% in around 70s.
What I don’t get is that after this, it takes another 45s to reach the point where it says stuff like:
ArtifactInstall_Enter_01: Change: 'INSTALLING' -> 'INSTALLING'
ArtifactInstall_Leave_01: Change: 'INSTALLING' -> 'INSTALLED'
Setting up /dev/mmcblk0p6 for use as /var filesystem for root /dev/mmcblk0p3
Use 'commit' to update, or 'rollback' to roll back the update.
At least one payload requested a reboot of the device it updated.
Which means that the progress bar is actually not giving the progress of the install process. Reading through the code, it seems like the progress bar is related to the Reader on the artifact.
So here is my question: after the installation process has read the full artifact, what takes another 45s before the installation is complete? And would there be a way to reflect that in the progress bar? It feels weird to have a progress bar that only accounts for 2/3 of the time…
More specifically, the progress bar seems to be linked to the image Readerhere, and I see the following message appear around when the installation is actually finished:
I am not aware of all the details between the “progress reader” and this “image reader”, but naively I would have expected it to be the same, such that the progress bar reflects that copy.
Am I completely off? And is the image copied twice, then, for some reason?
I had a closer look and, assuming that above, the “progress reader” is indeed the “image reader” (which would make total sense), then the next assumption is that io.Copy reads the whole image (which makes the progress bar reach 100%), but then the kernel still needs another 40s to finish writing (to sync, so to say).
So I am trying to see if I can make io.Copy write in a synchronized way, so that the Reader represents what’s actually written on disk (and not what’s buffered somewhere on the kernel side).
io.Copy seems to be using out, err = os.OpenFile(device, flag, 0)here.
My next question is therefore whether using a flag like O_SYNC would help .
I tried setting it by hardcoding 00040000 (as per this resource), i.e. with flag |= os.O_SYNC | 0o40000, but while it compiles, it ends up giving an error when running mender install <artifact>:
ERRO[0000] Download failed: Payload: can not install Payload: partition-root: Failed to write the update to the inactive partition: “/dev/mmcblk0p2”: Failed to open the device: “/dev/mmcblk0p2”: open /dev/mmcblk0p2: not a directory