a while ago ive made raspbian 4 pi’s into production, these received an size limit of 8gb (standard option)
even though they have 16gb sd-cards, the reasoning behind it was, that it was not going to be sure that all future RPI 4 pi’s would receive 16gb sd-cards, thus i decided to stick to the standaard setting.
As times passes on we came to the conclusion that indeed all future RPI 4 pi’s would get an 16gb sd-card, my question is then.
Is it possible with mender to increase these partitions (eg state-scripts with some best practice commands)
Or to do it single time mannually over ssh.
Or not at all & better make an clean image with an higher MENDER_STORAGE_TOTAL_SIZE_MB
i’m aware of this post
but it was never explained if it was possible or not.
For our Raspbian image (although not merged yet), this is what we are going to use, to expand the data partition to fill the sd-card. This is using parted to resize the last partition only (data), but more advanced workflows should be possible.
The cue is that this needs to be run prior to the partition being mounted, as you can see by the data.mount.wants dependency of the systemd service file.
I hope this brings some inspiration, as I am not completely sure which partition(s) you are looking at expanding.
I do have an last question, if i do enlarge the partitions (MENDER_ROOTFS_PART_A & _B)
is there somewhere a variable that was set during the creation of the image, that has the size of these partitions?
or does the mender client give the mender server a ‘size’ when pushing an artifact and to see if it fits on that client.
The size is part of the format we use for delivering the updates (i.e., Mender-Artifact).
Here is an example output from one I created with mender-convert:
mender-artifact git:(mendersoftware/master) ✗ mender-artifact read *.mender
Signature: no signature
Compatible devices: '[raspberrypi]'
Depends on one of artifact(s): 
Depends on one of group(s): 
modified: 2020-02-12 14:36:42 +0100 CET
As far as I know, there is no size-checks on the backend side, so a bigger update can be pushed in a later installment. The client will accept the update, and then fail, when it discovers that the size of the update is larger than the partition is writes to.
This is the error message you should be encountering in this case:
update (%v bytes) is larger than the size of device %s (%v bytes)