Sorry, I get into thinking about some things, and forget the minor details of other things. So, dd will not work directly on a directory per se. Technically dd can be used on single files, but that's a rather difficult way of going about things. To clarify: Using dd on a single directory, that directory would have to be on it's own block device. e.g. You'd need to mount the cloud9 directory form it's own /dev/sdX device. However, you could also use tar( whcih might be easier ) with I think it's the -P flag option to preserve permissions. Double check that, I'm going form pure memory.
On Wed, Apr 19, 2017 at 2:29 PM, William Hermans <yyrk...@gmail.com> wrote: > 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/CALHSORpZcL37QsqyxYh-oLsmphRfPchyy5hos4oL-WFeA8j%3D%3Dg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
