This is a very interesting question, we are looking into it. As soon as we have a response we will get back to you.
As far as I can see (and I haven't tried this yet, just going to), the partitioning itself is done as an u-boot script after flashing. A list of partitions to be created is in edison-src/device-software/meta-edison-distro/recipes-bsp/u-boot/files/edison.env, "partitions" variable. Rootfs one is set to 512MB there, home is set to "all the rest", so you can just increase rootfs and home will shrink automatically.
And a second part of this is the rootfs image size itself, which is set in the edison-src/device-software/meta-edison-distro/recipes-core/images/edison-image.bb and is also 512MB.
I'm not sure if the flashing process would be able to write smaller image to bigger partition automatically, so I'd rather modify both in sync to make sure.
And then first-install shell script runs upon the first boot and creates filesystems on those partitions. It's not affected by this change unless you change the order of partitions.
UPDATE Oct 06: corrected the path to the image recipe, it was identical to the u-boot recipe (except for the file name), cut'n'paste error.
what I typically do: I put an SD card in and mount it to /home/root in /etc/fstab.
This has the additional advantage that I don't loose my files when upgrading the image
my problem is that I am running out of space in '/' (due to installing various packages, opencv, ffmpeg,git, etc.). I changed the partition size at the sports AlexT_Intel mentioned, but the board does not seem to boot. I will report my findings shortly.
1 of 1 people found this helpful
I re-flashed the image I created using AlexT_Intel's instructions this time I ran 'flashall --recovery' first and then 'flashall', and this time it worked!
Note: I may have interrupted the reboot cycle after trying to flash the first time. So I am not sure if 'flashall --recovery' is actually required or not.
Yes, recovery is required, because that repartitions the flash memory. Without it it just rewrites the data on the existing partitions. And... glad you have what you want right now
FWIW, I moved /usr/local to /home/local and created a symbolic link to it. On the Arduino breakout board I added an SD card which is mounted on /media/sdcard.
I've been downloading source packages to the SD card, building them from source, then installing them into the normal /usr/local folder.
So far I've managed to install a lot of extra packages from source without running out of room (still have 22M left on /).
Very useful discussion. I have a need for more space on / and would prefer not to have to softlink directories to other partitions, so this is very useful.
I usually do a flashall.sh -b, which has the same effect as doing a recovery then flash, so it's all done in one step (re-partitioning and flashing).
One downside worth noting though, is that increasing the size of the / partition will increase the size of the ext4 file, which takes longer to flash. Not too bad, but takes quite a while with 2Gig plus root partitions
what's the maximum size you can set the rootfs without breaking OTA, ...?
I think you'd have to increase the size of the vfat partition by the same amount as you've increased the root partition so it still has enough space to pulldown and unpack the update. That has a big downside in that the increase in the vfat partition takes away space from the home partition.
So it's a delicate balance between how big you really need rootfs, and how much space you can afford to loose to the vfat partition for updating...
I'm currently not using OTA updates, though, but I guess if I need to, I'll be looking at ways to shrink the rootfs back down
I do have my home partition mounted to an SD card. So no issues with that
I'm using mini-breakout, so no SD card...
"I think you'd have to increase the size of the vfat partition by the same amount as you've increased the root partition"
I was thinking the same thing, but since I am not doing using OTA updates, I just left it alone.