Rootfs resizing causing failure on update

Hi @rossbcan @mirzak,
First time fiddling with embedded hardware, so have been on quite the wild, hair-thinning ride getting to grips with your work here but am very grateful to have had it as a guide.

Can you give any further instruction around adapting the scripts to smaller disk sizes?

I must be missing something.
Im trying to build with a reduced rootfs of 400MB, still for a 8GB sd so not changing the total sectors.
My understanding is that I have to modify one place - the openwrt_config ie the .config file to CONFIG_TARGET_ROOTFS_PARTSIZE=400mb for when i initially make my openwrt image and that does the rest.
If the rootfs partsize is changed will this also require changes to fstab i havent accounted for?

I can get a bootable base image but any update i make rolls back to the original partition, with very limited logging output.

Current steps in failure:
With /dev/mmcblk0p2 as active partition the update writes to /dev/mmcblk0p3, marks inactive partition as a boot candidate successfully but on reboot uses /dev/mmcblk0p2 still. Is this something you ever ran into?


From memory: consider the flash script CAREFULLY there may be (documented in script) limitations and assumptions regarding conversion from partsize (owrt .config) and perhaps power of 2 considerations to convert to sector ranges.

Also: Confirm your flash geometry (total sectors…) may vary tween suppliers.

ADVICE: do ALL the math

Luck & regards;



Thanks Bill. I think you’re painfully correct about the flash geometry.

I wrote the below before re-reading your comment ha.
So i begin again…

Can I ask for a final sense check on the matter?

I have a theory i cant test now as i only have one micro SD card of a set brand but… I would bet money I used to be able to flash to 8GB sds and now that I am using a different brand 8gb sd that has a lower actual capacity than before the sectors dont match and updates therefore cause overlaps in memory space, resulting in rollbacks.

I have kept the total sectors in mender_flashdisk constant at 15523840 so the total image size is should be a constant too. Recently ive been using 16gb sd cards for testing as the mender.img is 7.95GB and the capacity of the current brand 8gb sd cards is 7.85GB.

Would there be sense in thinking that this use of 16gb cards (or those of a capacity less than the 7.95 image produced by the mender_flashdisk with that total sector size) definitely wont work? Given that the is hard set to an 8GB sd and the sectors are going to be different on a 16GB or will vary by brand of SD.

Want to check as this assumes the 8GB SDs that you used had an actual flashable capacity of 7.95GB or more, which also seems unlikely

For the record: My app / verification used Sandisk Industrial SD’s

May be a “good” idea to confirm (fdisk) total sectors of disk versus alleged and err out if less. More OK – unallocated space

Please submit any updates to me and mender so we can stay current…


Thanks Bill. Definitely what i would like to have done previously but I’m using a hosted amazon instance as the build server at the moment so am unable to insert such an error handler in mender_flashdisk.

I ran diskutil list which also gave me the sector size for the SD (PNY 8GB microsdhc with 15335424 as the stated exact sectors). In adjusting this the image is now the right size to be flashed to the actual capacity of the SD (~7.85GB).
Unfortunately, the underlying behaviour is unchanged, the image in the first partition is bootable but update write to auxiliary rootfs reports success but fails to boot and results with rollback.

From mender server reported log cites failure due to:
running with image x, expected updated image y and then enacts rollback

But from serial console/attachment to device I am getting this error when the initial reboot occurs to try the new updated partition, whether I use the amended sector size or a 16GB SD:

Did you run into this? It implies that my address ranges are incorrect ie I speculate that there is still an overlap in partitions on update write(?)/uboot is somehow getting mangled when booting from the auxiliary rootfs partition but not the first.

The only thing left for me to ask is if the comment of yours in, that i found a bit confusing, would have any bearing on this (though i haven’t changed anything but the TOTAL_SECTORS): If you change openwrt image partition size, must also alter ORIG_P2_START_SECTOR ?