Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create a no_copy flag / allow mods to run directly from USB #1

Open
riptidewave93 opened this issue Oct 23, 2013 · 1 comment
Open

Comments

@riptidewave93
Copy link
Member

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.

@tchebb
Copy link
Member

tchebb commented Oct 24, 2013

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants