Open riptidewave93 opened 11 years ago
I'm happy to add this, but I'm doubtful of how much use it will actually be (which is why it's not already implemented). As you said, it's not possible to run directly from a zipped or tarred image, so this will be limited to development (or the user will have to extract the eureka_image directory manually). I think a more promising route, and something I plan to add for 1.1 or 1.2, would be to let FlashCast create a temporary directory on the flash drive and use that instead of /tmp for potentially large temporary files. There would be a flag file to disable this in case the user has a reason for not wanting the extra wear on the drive.
As for the implementation of your suggestion, I think I'd prefer to run imager.sh from a unionfs mount which has the directory on the flash drive read-only at the bottom of the stack. That way, nothing on the flash drive will actually be modified by the imager if it writes to its current directory (to match current behavior).
Thanks for the report!
When using flashcast with large eureka_image zips/folders there can be an issue where the /tmp file system runs out of space when the system partition is mounted for modification. Now, for released flashcast mods this shouldn't be an issue, but it would be nice to have a no_copy flag that would tell flashcast to not copy to /tmp, and to work directly from the flash drive.
It would probably be best to make this feature only work with eureka_image folders though, as there is always a chance a large zip extracted could also fill the jump drive, and this flag should really only be used by developers.
This is more of a request then it is an issue.