Extending mender /data partition to fill the SD card

[Ahmed abdelhalim]

Hi everyone,

I built a yocto image with mender integration for RPI3. In yocto image configuration file "local.conf" , if I specify only this parameter MENDER_BOOT_PART_SIZE_MB = "40" and when my image boots on the PI, I end up with 5 partitions. The boot partition is exactly as I specified 40 Mbytes, 2 RootFS partitions with 392Mbytes, one extended partition with 128Mbytes and one data partition with 128Mbytes. 

So I have the following partitions:

/dev/mmcblk0p1 -> Boot Partition

/dev/mmcblk0p2 -> RootFS1

/dev/mmcblk0p3 -> RootFS2 

/dev/mmcblk0p4 -> Extended partition

/dev/mmcblk0p5 -> Data partition (128 Mbyts)

In each RootFS there is data folder (/data) where  /dev/mmcblk0p5 is always mounted to /data according to the current active RootFS. I want to know please, how can I change the size of /dev/mmcblk0p5 and extend its size to fill the full size of the SD card ? 

I know I can set the variables MENDER_STORAGE_TOTAL_SIZE_MB and MENDER_DATA_PART_SIZE_MB in local.conf but I don not want to do that as I will end up with a very large image, besides this is considered to be size fixed to a specific SD card size, if the card is changed, then the image won't fit anymore. I need to have small image which can be extend its /data (or its mmcblk0p5) to fill the remaining size of the SD card. 

Last thing, I use fdisk when the image loads to change the partition table and their correspondin sizes.

Thanks,

Ahmed

[Mirza Krak]

I have used something similar to this to expand the "data" part size
to fill up SD card (on first-time boot if it not resized already).

parted /dev/mmcblk1 resizepart 4 100% -s
resize2fs /dev/mmcblk1p4

Might work in your case as well. Above is a bit simplified example but
should be enough for inspiration.

Note that you need "parted" and "e2fsprogs-resize2fs" installed on
your target. The mmc part should NOT be mounted when running above
commands.

--
Med Vänliga Hälsningar / Best Regards

Mirza Krak

[Kristian Amlie]

A large sdimg you will inevitably get if you want data to fill the
remaining space. But this is only for the initially deployed image,
subsequent updates only depend on the size of the rootfs.

Mender out of the box is set up for leaving the data partition size
static, and elastically adjust the sizes of the rootfs partitions. In
retrospect perhaps it would have been better the other way around. But
it should be pretty straightforward to reverse this relationship, using
something like this:

MENDER_DATA_PART_SIZE_MB = " \
${@str(eval('${MENDER_STORAGE_TOTAL_SIZE_MB} - 512'))}"

where 512 is some sensible number of MB that leaves enough space for the
boot partition and the two rootfs partitions. Then the data partition
will depend on the total size of the card, and the rootfs partitions
will always be the same size unless 512 is changed.

--
Kristian

[Ahmed abdelhalim]

Thanks Mirza and Kristian,

I used fdisk normally without having to install parted. @Mirza, when you mentioned that mmc part shall be demounted, I found that my problem actually was that I didn't notice that /dev/mmcblk0p5 is mounted in /etc/fstab. In this case when I delete /dev/mmcblk0p4 using fdisk and recreate it again, then I have to reboot. When it reboots, the partition was still mounted in fstab before I do the formatting using mkfs.ext4. So to summarize, what worked for me:

1- uncomment the /dev/mmcblk0p5 line from /etc/fstab

2- using fdisk or parted and deleting /dev/mmcblk0p4 (the other /dev/mmcblk0p5 will be deleted as well)

3- recreate partition 4 (extended type) and create partition 5 (logical) with the suggested sizes by fdisk

4- save the new tables by 'w' 

5- reboot and mkfs.ext4 /dev/mmcblk0p4 

6- remove the commented line in fstab

@Kristian, The only issue with your sugestion and as you mentioned is the invitable large sdimg. For example, transferring 64 Gbytes and writting such amount to the SD card will take very long time. So choosing adequate size for rootfs and boot partitions, plus very small amount for data, then resizing /data to fill the sd-card is much faster and will fill every single block on the SD card after all.

Thanks to both of you for your replies. 

[Kristian Amlie]

On 08/01/18 15:50, Ahmed abdelhalim wrote:
> @Kristian, The only issue with your sugestion and as you mentioned is
> the invitable large sdimg. For example, transferring 64 Gbytes and
> writting such amount to the SD card will take very long time. So
> choosing adequate size for rootfs and boot partitions, plus very small
> amount for data, then resizing /data to fill the sd-card is much faster
> and will fill every single block on the SD card after all.

It will get much much smaller if you compress it with gzip before
transferring, since it contains so much null space, but yeah, the write
will be big no matter what.

--
Kristian