Just a quick worklog to give an idea of how you set this up and how it
works. Of course, you may want todo things a little differently. It depends
on if you want to keep the cloud9 directory "updated" Meaning over time
maybe updates have updated the files, so perhaps one could make a fresh img
file very time the cloud9 directory is mounted for use. Perhaps that part
could be done in memory, but keep in mind once the board loses power, that
stored "data" will also be lost. Which is why I think the best way to go
about things would be to store the directory structure we don't care about
in memory.
Also keep in mind that this is just an example, and the files I'm
demonstrating with have nothing to do with cloud9. The overall concept
however should be solid. As such, you may need to double check permissions
etc. But if you use dd to create your image, directory structure along with
file permissions should remain intact.
*Load the zram kernel module:*
root@wgd:~# *modprobe zram zram_num_devices=1*
*Test to make sure driver module loaded:*
root@wgd:~# *lsmod |grep zram*
zram 25049 0
zsmalloc 13745 1 zram
lz4_compress 3334 1 zram
Notice here that zram is using the lz4 compression algorithm. This can be
changed.
*Set the zram memory constraints:*
root@wgd:~# *echo '256M' > /sys/block/zram0/disksize*
root@wgd:~# *echo '128M' > /sys/block/zram0/mem_limit*
*Make a file system on our ramdisk:*
root@wgd:~# *mkfs.ext4 /dev/zram0*
mke2fs 1.43 (17-May-2016)
Discarding device blocks: done
Creating filesystem with 65536 4k blocks and 65536 inodes
Filesystem UUID: 2a08c7dd-234f-497a-a89b-fe4ecbb78c3f
Superblock backups stored on blocks:
32768
Allocating group tables: done
Writing inode tables: done
Creating journal (4096 blocks): done
Writing superblocks and filesystem accounting information: done
*List directory contents( note" 'testfile' is empty ):*
root@wgd:~# *ls*
git testfile
*Get our current working directory:*
root@wgd:~# *pwd*
/root
*Find our ramdisk device:*
root@wgd:~# *ls /dev |grep zram**
zram0
*Mount our ramdisk at /root/ ( root's home directory ):*
root@wgd:~# *mount /dev/zram0 /root*
*The interesting part here is that we're still seeing our original file
structure:*
root@wgd:~# *ls*
git testfile
*But once we change directory . . . The new structure shows up:*
root@wgd:~# *cd /root/*
root@wgd:~# *ls*
lost+found
*Create a new test file, and test:*
root@wgd:~# *touch testfile*
root@wgd:~# *ls*
lost+found testfile
root@wgd:~# *echo "Hello World" > testfile*
root@wgd:~# *cat testfile*
Hello World
*Unmount the ramdisk( note: one must change out of the mountpoint before
unmounting ):*
root@wgd:~# *cd ..*
root@wgd:/# *umount /root/*
*Change back into our root home directory and retest:*
root@wgd:/# *cd ~*
root@wgd:~# *ls*
git testfile
root@wgd:~# *cat testfile*
<no output>
On Wed, Apr 19, 2017 at 1:10 PM, William Hermans <yyrk...@gmail.com> wrote:
> By the way Mark my last comment was directed at you. But one thing I
> forgot to mention is that once you unmount the tmpfs directory I mention
> above, the original directory would be there still. So you'd want to take
> steps to keep from overwriting files there. I mean you could technically
> just revert the directory from the img file I suppose, but that would be a
> minor hassle at best. Also, using the zram tmpfs method i mentioned above
> would not require chroot at all.
>
> On Wed, Apr 19, 2017 at 1:06 PM, William Hermans <yyrk...@gmail.com>
> wrote:
>
>> How about using a chroot ? Basically you keep a chroot image where ever
>> you want, mount it where ever you want, and just wipe it out for a fresh
>> start when you need to get back to pristine. I am trying to think what
>> would be the smartest way to do this as you wouldn't necessarily want to
>> spend a long time trying to get all this done. Then it may also make better
>> sense to run this chroot from a tmpfs. So perhaps you copy the content of
>> the cloud9 directory, into an img file. make a zram tmpfs, then just mount
>> it over the top of the original cloud9 directory, and extract the img
>> contents into that ramdisk ?
>>
>> On Wed, Apr 19, 2017 at 12:38 PM, Mark A. Yoder <mark.a.yo...@gmail.com>
>> wrote:
>>
>>> The big picture is: I'd like to use these in a workshop and the the
>>> participants play all they want. Once we are done I want to run one
>>> command to reset everything.
>>>
>>> I can't count on having internet, so a local git repo sounds like a good
>>> idea.
>>>
>>> --Mark
>>>
>>> On Wednesday, April 19, 2017 at 3:33:01 PM UTC-4, RobertCNelson wrote:
>>>>
>>>> On Wed, Apr 19, 2017 at 2:26 PM, Robert Nelson <robert...@gmail.com>
>>>> wrote:
>>>> > On Wed, Apr 19, 2017 at 1:34 PM, Mark A. Yoder <mark.a...@gmail.com>
>>>> wrote:
>>>> >> Robert:
>>>> >> It looks like all the files in /var/lib/cloud9/examples are owned
>>>> by
>>>> >> root:cloud9ide and are mode 664. They need to be mode 665, or maybe
>>>> 667.
>>>> >>
>>>> >> Mode 667 would let people easily edit the files and experiment.
>>>> Though it
>>>> >> would also let people mess up the files.
>>>> >>
>>>> >> How about we have a parallel directory to examples that serves as a
>>>> backup.
>>>> >> They could all me mode 665 and the examples files would be 667.
>>>> >
>>>> > The debian user is part of the cloud9ide group, so the 664 should
>>>> > work, or do you think it should be 674? so the cloud9ide group can
>>>> > execute the file..
>>>>
>>>> The other issue, that whole directory get's extracted from the bone101
>>>> package, so any changes to the package will wipe out that dir.
>>>>
>>>> Unless we move the examples to github and just create a local git
>>>> clone?
>>>>
>>>> Regards,
>>>>
>>>> --
>>>> Robert Nelson
>>>> https://rcn-ee.com/
>>>>
>>> --
>>> For more options, visit http://beagleboard.org/discuss
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "BeagleBoard" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to beagleboard+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit https://groups.google.com/d/ms
>>> gid/beagleboard/eaa04298-81a4-4af0-a033-fe369e458cc7%40googlegroups.com
>>> <https://groups.google.com/d/msgid/beagleboard/eaa04298-81a4-4af0-a033-fe369e458cc7%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/beagleboard/CALHSORrJuniY9ZkT8ByR9bBZK%2BS99%3DfBW4unO40qF%2BHG8Ow9%2BA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
