Which OS and BSP are you using?
I suggest you to use the flashall script to flash the image instead of the reboot ota method. In here you will find how to run this script: How to Run the Flashall Script but you have to use the files created for your own image
I am using a custom build of yocto-linux based off the ww18-15 release. I always use the flashall.sh script when trying to re-size the partition, I understand that you cannot resize the partition when doing an OTA.
I've hit two issues but it's not clear what the root cause.
1) the GPT generated by u-boot does not always seem to be updated.
[ 32.162392] sh: Formatting home partition : Success
[ 32.246846] sh: Mount /home partition : Success
[ 46.061659] sh: Restore home/root contents on new /home partition : Success
[ 46.232696] sh: The number of cylinders for this disk is set to 26624.
[ 46.282353] sh: There is nothing wrong with that, but this is larger than 1024,
[ 46.322554] sh: and could in certain setups cause problems with:
[ 46.357793] sh: 1) software that runs at boot time (e.g., old versions of LILO)
[ 46.402542] sh: 2) booting and partitioning software from other OSs
[ 46.439118] sh: (e.g., DOS FDISK, OS/2 FDISK)
[ 46.473952] sh: Command (m for help): Command action
[ 46.508868] sh: e extended
[ 46.543223] sh: p primary partition (1-4)
*** This is a problem !!! **
[ 46.577478] sh: Partition number (1-4): Partition 1 is already defined, delete it before re-adding
This is the output on the console after doing a flashall.sh when trying to increase the partition size. You can see from the output of the post-install.sh script that it is trying to create the update partition with fdisk but fdisk already believes the partition exist.
2) corrupted file system on upgrade partition
I discovered this when I could copy file over USB to the edison and then see this files on the edison by mounting the partition as a loop device but still could not see the files with fatls in u-boot. I booted back up to Linux and ran fsck.vfat on the upgrade partition and there were problems. I re-formatted and checked again with fsck, and when there were no errors I could see files in u-boot that had been copied over USB.
Do you have updates in this?
Are you following the steps from: Changing partition setup on Edison ?
1) Did you change something else in the image? Could you attached in here the /meta-intel-edison-bsp/recipes-bsp/u-boot/files/edison.env and the meta-intel-edison-distro/recipes-core/images/edison-image.bb you are using?
2) I think there is something wrong while we are building the image with the changes in the partitions.
Have you tried with a clean build? or maybe with the ww25.5 source files?
I have not figured out the root cause of this but did modify the post-install.sh to get the partition in the correct state. So now I always delete the update partition with fdisk before trying to create it. I just ignore the error in the case where the partition does not exist. I also use fsck to check the partition after doing mkfs and if there is a failure I repeat. We have not had any issue repartitioning older edisons with this method.
I don't think there is a problem with the build, I think there is some problem with the GPT. The fact that fdisk still believes the partition still exist after using the flashall.sh script seems to indicate that u-boot is not erasing and re-writing the new one. I have not looked at the u-boot GPT code in-depth.
I have tried clean builds but have not tried ww25.5
I'm not sure if you are following the steps fromChanging partition setup on Edison, if you are not following these steps please post in here the method you are using.
Also, please send us the /meta-intel-edison-bsp/recipes-bsp/u-boot/files/edison.env and the meta-intel-edison-distro/recipes-core/images/edison-image.bb you are using?
Additionally, in the terminal console run the command parted and once you are inside the interface run the command print all and attach a picture of what you get.
Those step are old since the rootfs has changed by default. Also, it's not necessary to use -recovery since the board is rebooted after u-boot has been flashed with the new partitions and flashing continues after that. I did increase the size of the update partition in u-boot.env to 832MiB
# Partition definition
Here is the output of parted
Number Start End Size File system Name Flags 1 1049kB 3146kB 2097kB u-boot0 2 3146kB 4194kB 1049kB u-boot-env0 3 4194kB 6291kB 2097kB u-boot1 4 6291kB 7340kB 1049kB u-boot-env1 5 7340kB 8389kB 1049kB ext2 factory 6 8389kB 33.6MB 25.2MB panic 7 33.6MB 67.1MB 33.6MB fat16 boot 8 67.1MB 1678MB 1611MB ext4 rootfs 9 1678MB 2550MB 872MB fat32 update 10 2550MB 3909MB 1359MB ext4
However, non of this is going to help explain the problems I originally describe where fdisk believes the update partition already exist after a flashall.sh. Nor does it give any insight as to why the update partition is r/w from both the edison and a linux host but u-boot is unable to read the files on that partition.
I am satisfied at the time with the WAR I have put in place in the post-install.sh script. We have not seen any issues since this change. To recreate, you just need the change the update partition size in the u-boot.env, and re-flash with flashall.sh. The issues did not happen 100% of the time but the problem was frequent enough that I was able to easily re-created and debug the issue. I am still using the ww18-15 release.