Increasing paritions size of production mender clients

Hello everyone,
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.

Thanks in advance, Gene

In the Yocto layer we have support for systemd-growfs which automatically resizes the data partition on boot. Adding the following to your local.conf should enabled this:

MENDER_FEATURES_ENABLE_append = "mender-growfs-data"

I assume that something similar can be done with Raspbian only the mechanics will differ.


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.


@drewmoseley & @oleorhagen
thanks for the input! yes i will look into it more, will try some things local first.

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.
Greets Gene

Hi @genedupre.

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
Mender artifact:
  Name: dump
  Format: mender
  Version: 3
  Signature: no signature
  Compatible devices: '[raspberrypi]'
  Provides group: 
  Depends on one of artifact(s): []
  Depends on one of group(s): []
  State scripts:

    Type:   rootfs-image
	rootfs_image_checksum: aab96150f7dc51b4c9a8015dd155d7221bd965464ed212e2d71e2e96c02de721
    Depends: Nothing
    Metadata: Nothing
      name:     rootfs.tmp187950712
      size:     513
      modified: 2020-02-12 14:36:42 +0100 CET
      checksum: aab96150f7dc51b4c9a8015dd155d7221bd965464ed212e2d71e2e96c02de721

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)

I hope this answers your question

1 Like

@oleorhagen, yes i know enough now, thanks for the help!