Mender with more than 4 partitions

For an caching communication hub we want to use Mender on the device with one extra partition for storing our cached data. This cached data needs to be wiped everytime the hub is redeployed to another customer.

For this purpose we want to make a fifth partition for this cached data so that it can easily be wiped by a format operation (which is the reason not to use the persistent data partition for this).

I’ve just tried to create a fifth partition on my Mender test box and I seem to have walked into a partition limit. GParted tells me that it is not possible to create more than four primary partitions. This could be solved with an extended partition, but in order to create that one I need to remove the persistent data partition and replace it with an extended partition (because the extended partition is also a form of primary position). Then I could recreate the persistent data partition inside the extended partition and add the extra cache data partition.

Since I have no experience with how Linux handles extended partitions, I can foresee that there might be issues with working this way.

My question is: will this mess up Mender’s partition requirements or is this something that can be done without any issues?

Since I’m working from home with limited resources available for me, I don’t want to screw up the current working Mender device install that I have on my Gigabyte Brix if possible!

Yes, this is a limitation of the MBR and as mentioned an extended partition is required to support more then four partitions.

My question is: will this mess up Mender’s partition requirements or is this something that can be done without any issues?

I think it is problematic to do this on a “live device”, since the extended partition that you need to create will need to overwrite the current data partition, which probably means that you will lose the data on there, such as keys for device identity and authentication.

But I do not see any problems with this kind of setup if you at build time create these partitions and they are in place when the device is provisioned. Depending on what you are using to build your images you might need to tweak some variables to get everything mounted, e.g the Mender data part would be at position 5 since the extended partition would be at 4.

Hi Mirzak,

I’d store the current contents of the persistent data partition before doing the conversion and placing them back after the change to the new persistent data partition. If there is no link to the partition information regarding keys it should not cause issues.

My worries where more in the area of partition identification after the conversion. Would the new persistent data partition still have the same partition id as the current one (so for instance sda4) or will the use of a extended partition mess this up somehow?

It will mess up the numbering, so after your changes it would look something like this:

sda1 # Boot part
sda2 # rootfs A
sda3 # rootfs B
sda4 # extended partition
sda5 # data part
sda6 # extra part

To additionally clarify,

Mender client will access the persistent data area by utilizing /var/lib/mender, this location is normally a link to /data/mender. /data is the mount point for the data part.

So what you need to do is to make sure that after your changes /dev/sda5 is mounted to /data instead of /dev/sda4. This entry you can find in /etc/fstab

Hmm. that might be an issue, but not insurmountable I guess.
I’ll make a backup of my current test system and then give it a try.

Well, that failed. Clonezilla refuses to make a backup of the disk because there is both a GPT and a MBR version of the partition table on the disk. And it wants me to repair that first, but it warns me that if I mess up the disk might become unreadable…

Any suggestions?

Note familiar with Clonezilla and do not know why it would think there is both MBR and GPT present.

GPT does allocate the first block of disk for something called protective MBR, I do not know if this is misinterpreted by Clonezilla.