Filesystem read-only

[Fohnbit]

Hello,

has someone a link for how to setup the BBB as read only filesystem?
But I need some files to writeable (interfaces, ser2net conf, ...)

Could someone help me? Thank you!
What informations should I post here?

[Tarmo Kuuse]

Actually, that's a relevant question for me too. I got as far as mounting /tmp and /var as ramdisks and configuring logrotate to aggressively compress and prune logs (so they don't swamp the RAM). That's not a very difficult task, e.g. /etc/fstab has these entries:

tmpfs  /var        tmpfs  defaults,noatime,nosuid,size=128M  0  0

tmpfs  /tmp      tmpfs  defaults,noatime,nosuid,size=128M  0  0

And /etc/logrotate.conf needs this:

compress

compresscmd /bin/bzip2

uncompresscmd /bin/bunzip2

compressoptions --best

compressext .bz2

Plus anything needs to be rotated at least weekly, with no more than a month's worth of compressed logs kept. It seems to keep the entire /var/log pretty compact (a few MB). 

I also installed an SD card and stored all the logs which need to survive reboots on it. If the SD card dies, I can simply swap it out and the entire device should still remain functional the whole time.

But then I got stumped. There remain a bunch of files sprinkled around elsewhere which still need to remain writable. I could only come up with /etc/resolv.conf at first, but there are probably others. I guess you could make them readable by symlinking from a read-only root file system to a file on ramdisk. 

I didn't have time to experiment and play around, so I just left root as RW in the hope that removing logs and temporary files will reduce eMMC load sufficiently for it to last longer than the remainder of the device :)

--

Kind regards,

Tarmo Kuuse

[William Hermans]

On Mon, Jan 23, 2017 at 3:01 AM, Tarmo Kuuse <tarmo...@gmail.com> wrote:
>
> Actually, that's a relevant question for me too. I got as far as mounting /tmp and /var as ramdisks and configuring logrotate to aggressively compress and prune logs (so they don't swamp the RAM). That's not a very difficult task, e.g. /etc/fstab has these entries:
>
> tmpfs  /var        tmpfs  defaults,noatime,nosuid,size=128M  0  0
> tmpfs  /tmp      tmpfs  defaults,noatime,nosuid,size=128M  0  0
>
> And /etc/logrotate.conf needs this:
>
> compress
> compresscmd /bin/bzip2
> uncompresscmd /bin/bunzip2
> compressoptions --best
> compressext .bz2

If you're using a Jessie image. It might actually be worthwhile to look into creating a service that initializes, and uses a zram ramdisk. Also, I think, but am not 100% positive that /tmp is already created from a zram ramdisk- By default. I just can not remember where I got this impression. Probably form reading through one of the default scripts that run at boot. Anyway, zram is supposed to be pretty fast, and can offer up to a 2:1 compression ratio.

https://www.kernel.org/doc/Documentation/blockdev/zram.txt

I can say with certainty that is is built into these kernels. As I'm currently running it on a board right now. I have not experimented with using for /var though. . .but if you put any files in /tmp, then reboot. The files, and/or directories will be gone after a restart.

One thing does concern me though . . .
root@beaglebone:~# last -x
debian   pts/0        192.168.254.162  Mon Jan 23 02:59   still logged in

  <many lines of output here - Maybe 100 lines +>
  reboot   system boot  4.4.12-ti-r31    Fri Dec 31 17:01 - 12:14 (6014+19:13)

Anyway, the way I'm using zram is to create a ramdisk at startup through a service that calls a script to create the ramdisk, and rsync persistent data back into the ramdisk. Then two more services that call the same shutdown script. Which rsync's the data back into the persistent directory. Perfect ? I don't know, I'm still experimenting.