Migrating eMMC from 8GB to 16GB: Partition and Filesystem Expansion
- Partition boundary adjustment via partition tools does not expand the underlying filesystem automatically.
- Hardcoded offsets in bootloaders or OTA scripts must be audited against new addressable sector counts.
- Hardware parameters, boot partitions, and RPMB configurations must be verified independently of user area capacity.
Moving a product from an 8 GB to a 16 GB eMMC changes the available user-area capacity, but it does not automatically expand an existing image, partition or filesystem. First check that the exact replacement part is electrically and mechanically compatible with the board and host. Then treat the image and update path as a separate migration.
Where can an 8 GB assumption remain?
| Layer | Evidence to inspect | Migration question |
|---|---|---|
| Source image | Partition table, last partition end and filesystem size | Will the image write to the new device, and where is unused space? |
| GPT or other layout | Primary and backup metadata positions, actual addressable sectors | Does the imaging tool repair or relocate end-of-device metadata? |
| Boot/update scripts | Fixed sector numbers, image-size checks and rollback logic | Will an OTA or recovery step recreate the old layout? |
| eMMC configuration | Boot areas and any protected regions needed by the product | Is the new part provisioned as the system expects? |
| Application | Free-space checks, log limits and database settings | Does the application actually use the extra capacity? |
The parted manual makes an essential distinction: changing a partition's end with resizepart does not resize its filesystem. For ext2/3/4, resize2fs is a separate operation with filesystem and mounted-state requirements. Other filesystems need their own documented procedure. A larger user area does not imply identical eMMC boot or RPMB configuration.
Validate a copy before changing production images
On an approved test copy, record the source and destination part numbers, exact sector counts and partition starts. After flashing, inspect both partition-table metadata and filesystem capacity. Exercise a cold boot, update, rollback and recovery path on the target board. Verify data and application behavior before declaring the migration complete. Avoid a generic one-line resizing recipe: changing the wrong partition or backup header can make the system unbootable. Include the target image layout and board revision with a quote request.
References
We publish measured usable capacity and define trial-batch verification against the quoted product and agreed test scope.