On the previous version of the firmware download when we did the reboot ota, the complete ota drive was cleared and the home directory was cleared as well. So when we went flashed up to this version, was not sure it succeeded. Probably should be some note, saying that the functionality has changed. I believe 3. Is suppose you are re-flashing because you have corrupted the contents. Maybe I built my own image which is not working well, or I downloaded several packages that were not working well, or I ran out of system space...
Example yesterday when I received my new Edison and mini breakout board (to replace the one I am having issues with), I was not sure it succeeded.
So I did it the other way. I downloaded the image to my linux machine and did a sudo flashall
When flashing from factory build_56 to build_68 performing a reboot ota the ota drive is most definitely cleared.
When flashing from build_68 to build_16 the ota drive is not cleared.
This leaves you with the feeling that it is not complete ...
If it is only the /home directory not being cleared in the flash to build_16, I can get that - was never stated anywhere.
with regard to 3), IF the OTA drive's space is separate from the 4GB on Edison, okay I can understand and have no issue.
but it the space for the OTA drive is not separate, which was my assumption as the only reason you fill it is to wipe out the 4GB, then at some point shared file space would eventually be corrupted by the by either the OTA drive or the Linux 4GB over writing.
I haven't noticed any documentation that showed 4GB MMC + 600M OTA - so if shared, as the 4GB gets filled, one corrupts the other
Can we confirm:
1) it is only the /home dir that is not being cleared - I can certainly write a routine for that.
2) is the OTA drive separate from the 4GB MMC, otherwise what section of the Linux filesystem is it sharing (that might corrupt the ota contents, or the ota contents might corrupt the Linux files)
I've just checked the BSP sources and indeed on the previous image you would have OTA partition cleared - good catch (I've moved off that one quite a while ago and haven't used OTA to do that). Home would be cleared as well,only /home/root would be preserved.
Now on ww42 image (current one in the Downloads section, you call it build_16), they've changed the boot target for the OTA case and it's now ota-update (which doesn't touch home and OTA partitions at all) instead of the first-install one (which should preserve only /home/root and reformats that partition + reformats the OTA partition).
You can check all of this by looking at the BSP sources, namely these files:
- edison-src/device-software/utils/flash/ota_update.cmd (this is what becomes ota_update.scr during postBuild.sh run and then is executed during OTA)
So it's /home and the OTA partitions which aren't being cleared and the OTA partition is separate from all other ones (but is on the same MMC flash), so you can't corrupt it by just overfilling the rootfs with data, you'd need to mess up with fdisk or parted or write to the disk directly to accomplish that. Neither can OTA data corrupt the rootfs.
Thanks, getting my answer piece by piece. So the 766MB ota drive is separate from the Linux system but still part of a 4GB MMC. Not that I am asking the same question but still need clarification. By looking at the df output
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/root 475080 315108 123276 72% /
devtmpfs 491736 0 491736 0% /dev
tmpfs 492048 0 492048 0% /dev/shm
tmpfs 492048 484 491564 0% /run
tmpfs 492048 0 492048 0% /sys/fs/cgroup
tmpfs 492048 484 491564 0% /etc/machine-id
systemd-1 5638 5184 454 92% /boot
tmpfs 492048 4 492044 0% /tmp
systemd-1 2337308 3760 2317164 0% /home
tmpfs 492048 0 492048 0% /var/volatile
/dev/mmcblk0p5 1003 21 911 2% /factory
/dev/mmcblk0p10 2337308 3760 2317164 0% /home
/dev/mmcblk0p7 5638 5184 454 92% /boot
So from the Yocto image Linux side, over filling the Edison Linux filesystem at some point will overwrite/corrupt the OTA drive (if in someway shared) or is the OTA a completely separate partition from what we see here in the df output.
Reasoning is that if the OTA is absolutely completely separated, it could house the image on the module and a reboot ota could reset to start without fear of the ota ever becoming corrupted from operational usage.
It's a separate partition and it's not normally mounted (so you won't see it in the mount or df output), so you can't corrupt it by overfilling any of the mounted partitions. It's not like a hidden directory or something on one of the normally mounted partitions, it's a separate one.
it could house the image on the module and a reboot ota could reset to start without fear of the ota ever becoming corrupted from operational usage
and I've actually did something like that a couple of times when testing new packages. I've written the image to the OTA partition, then ran "reboot ota", it reflashed itself and I've got a fresh system. Then I've tested several packages and during the process I overfilled the rootfs partition, so I just ran "reboot ota" and it was fine again. And a couple of similar cases, so yes, it works in this scenario.