I have two interrogations regarding the a rootfs update :
Is the rootfs really stream written to the partition ? i.e. in case of connection shutdown the blobs already downloaded were loaded on disk and not lost so when the connection comes back it proceeds from where it stopped.
Is it possible to extend the rootfs update module with some extra files and operations ? From what I understand it is possible to write custom update module from scratch (those made available by the community for instance), but I would like to keep the dual rootfs update module behaviour and just add some extra files. I know I can add scripts (state files) to realize inter-state operations, but how can I add the other files needed for a full update of my system ? Am I constrained to split it into multiple artifacts ?
Is the rootfs really stream written to the partition ? i.e. in case of connection shutdown the blobs already downloaded were loaded on disk and not lost so when the connection comes back it proceeds from where it stopped.
This is correct, the rootfs images is streamed from the net to the inactive partition and will continue the download if e.g interrupted by a network loss.
Is it possible to extend the rootfs update module with some extra files and operations ? From what I understand it is possible to write custom update module from scratch (those made available by the community for instance), but I would like to keep the dual rootfs update module behaviour and just add some extra files. I know I can add scripts (state files) to realize inter-state operations, but how can I add the other files needed for a full update of my system ? Am I constrained to split it into multiple artifacts ?
Could you maybe specific a bit more details about your use-case? What is meant by “extra files and operations”?
This is correct, the rootfs images is streamed from the net to the inactive partition and will continue the download if e.g interrupted by a network loss.
Ok because when I check the Root Filesystem Image v2 (which is not the official one ofc) I can not see how it is possible to write at the next position in the partition with a simple cat. So I was wondering…
Could you maybe specific a bit more details about your use-case? What is meant by “extra files and operations”?
Let’s say I want to upload a root fs partition with the A/B mechanic (i.e. a dual rootfs artifact) with the kernel inside, but I also want to upload an extra data partition at the same time (in the same artifact). The two partitions are “linked” but still dissociated on disk. That is why I was talking about extending the dual rootfs update module behavior.
The Root Filesystem Image v2 Update Module does not support this as you have seen as well. But the internal rootfs-image updater supports this as it is using HTTP range-requests to write data in chunks (1MiB), and this way it can keep track of where it is.
Let’s say I want to upload a root fs partition with the A/B mechanic (i.e. a dual rootfs artifact) with the kernel inside, but I also want to upload an extra data partition at the same time (in the same artifact). The two partitions are “linked” but still dissociated on disk. That is why I was talking about extending the dual rootfs update module behavior.
Thanks for clarifying. Now I understand. In this case you have two options:
deploy the “extra data partition” as part of the rootfs image and e.g install it in one of the Mender state-scripts
Create two separate Mender Artifacts (.mender) and deploy them individually.
Even though the specification of the Mender Artifact format does allow multiple payloads with different types (which what you ultimately would like I believe), this is not yet implemented in code and something that will be added further down the road.
