Finally had a situation where an mmc was swapped out for an alternate of a different size and now see that the mender-grow-data service never really worked.
We have to use an override to the mender GPT service so we aren’t 100% standard usage, but I don’t believe the issue I’m seeing is related to this. Disclosing it in case I’ve overlooking something.
The summary is:
- Mender-grow-data service fails because /usr/bin/mender-client-resize-data-part calls the wrong parted command, using 3 instead of 4.
# All sizes are in blocks of 512 bytes
MENDER_DATA_PART=/dev/mmcblk0p4
mender_data_part_base=$(basename ${MENDER_DATA_PART})
mender_storage_device_base=$(basename $(readlink -f /sys/class/block/${mender_data_part_base}/..))
mender_storage_device=/dev/${mender_storage_device_base}
total_disk_size=$(cat /sys/block/${mender_storage_device_base}/size)
data_part_size=$(cat /sys/block/${mender_storage_device_base}/${mender_data_part_base}/size)
data_part_start=$(cat /sys/block/${mender_storage_device_base}/${mender_data_part_base}/start)
....
/usr/sbin/parted -s ${mender_storage_device} resizepart 3 100%
/dev/mmcblk0p1 1024 9215 8192 4M Microsoft basic data
/dev/mmcblk0p2 10240 11120639 11110400 5.3G Linux filesystem
/dev/mmcblk0p3 11120640 22231039 11110400 5.3G Linux filesystem
/dev/mmcblk0p4 22231040 30619647 8388608 4G Linux filesystem
- When looking at why this was 3, it turns out that this isn’t parsed from MENDER_DATA_PART in the script like the other pieces and instead uses the very rarely used (I see only 3 reads of this variable) MENDER_DATA_PART_NUMBER
/usr/sbin/parted -s ${mender_storage_device} resizepart @MENDER_DATA_PART_NUMBER@ 100%
- I checked my configuration and MENDER_DATA_PART_NUMBER isn’t set in a conf, this is the partition configuration, and while it looks iffy, it works as MENDER_DATA_PART is set correctly to /dev/mccblk0p4 in the script:
# No boot partition required
# U-Boot Env is not required on mmcblk0, it lives on mmcblk0boot1
#MENDER_BOOT_PART = "${MENDER_STORAGE_DEVICE_BASE}1"
MENDER_DATA_PART = "${MENDER_STORAGE_DEVICE_BASE}4"
MENDER_ROOTFS_PART_A = "${MENDER_STORAGE_DEVICE_BASE}2"
MENDER_ROOTFS_PART_B = "${MENDER_STORAGE_DEVICE_BASE}3"
- So then I investigate where MENDER_DATA_PART_NUMBER would be set if not specified and that terminates here:
As my BSP has other required partitions, this function is a pretty basic attempt to guess the number of partitions and assume the data part will be the last one.
So the fix paths could be:
-
I will add redundant definitions for both MENDER_PART and MENDER_PART_NUMBER as these failures are subtle.
-
Each usage could be revised (or at least the growfs script, to parse the number from MENDER_DATA_PART in the beginning of the script) to have its correct usage.
-
Or this one is an ask, but it does seem that having separate MENDER_PART and MENDER_PART_NUMBER variables invites unnecessary inconsistency in the configuration. I see the appeal of having the top level config be a part and then numbers, but for many embedded BSPs the required partitions are growing more and more complicated.
EBBR requires like 13+ partitions on its own.
https://arm-software.github.io/ebbr/
The current fallback if the PARTs are set but the PART_NUMBERs are not is essentially to guess based on some other configuration parameters. I’m not sure if anyone is NOT setting either, which is definitely too laissez faire for my taste. 
I could see a solution where the mender-helpers.bbclass does a check of splitting the final MENDER_PARTs and MENDER_PART_NUMBERs and fatals the build if they don’t match. Then at least all of us who have inconsistent settings would know.
But truly, I only see 3 or 5 uses of each PART_NUMBER in meta-mender and it could be more authoritative to always use MENDER*_PART and parse the number where necessary. But that’s probably too breaking for historical reasons so it might be stuck?