I have been tasked with running Linux as an operating system on an embedded device.

The target has an x86 processor and has 8 GB CompactFlash device for storage.

I have managed to use buildroot to create the kernel image and cross compilation tools. I have partitioned the CF device into a small FAT partition where the kernel image resides as well as syslinux boot configuration and an ext3 file system where I have decompressed the root file system generated by buildroot to.

The system boots successfully using syslinux by setting the root directory to the CF ext3 partition where my buildroot file system is located.

My question is centred around the need for robustness in the face of immediate (and frequent) power loss as it is crucial for the device to boot successfully after power outages. I have read that mounting the root file system as read only is a way of ensuring data integrity. Is this a sensible way for me to proceed?

I have also read about the possibility of loading the root file system into RAM to achieve the same thing but as yet do not know how to do so.

Is there a preferred way of achieving this goal and if so what is the best way for me to proceed?

2 Answers 2


New answer (2015-03-22)

(Note: This answer is simpler than previous, but not more secure. My first answer is stronger because you could keep files read-only by fs mount options before permission flags. So forcing to write a files without permission to write won't work at all.)

Yes, under Debian, there is a package: fsprotect (homepage).

It use aufs (by default, but could use another unionfs tool) to permit live session changes but in RAM by default, so everything is forgotten at reboot.

You could install them by running simply:

apt-get install fsprotect

Once done, from online doc:

After that:

  • Edit /boot/grub/menu.lst or /etc/default/grub2 or /etc/lilo.conf and add "fsprotect=1G" to kernel parameters.
  • Modify 1G as needed.
  • Apply changes (i.e. run update-grub)
  • Edit /etc/default/fsprotect if you want to protect filesystems other than /.
  • reboot

You may also want to password protect the grub bootloader or forbid any changes to it.

From there, if some file is protected against changes, for sample by

chmod ugo-w myfile

if you use for sample vi myfile and try to write on it with command :w!, this will work and your myfile became changed. You may reboot in order to retrieve unmodified myfile.

That's not even possible with my following first solution:

Old (first) answer:

Yes, it is a strong solution, but powerfull!

Making r/o useable

You have to mount some directories in rw, like /var, /etc and maybe /home. This could by done using aufs or unionfs. I like this another way, using /dev/shm and mount --bind:

cp -a /var /dev/shm/
mount --bind /dev/shm/var /var

You could before, move all directories who have not to change in normal operation in a static-var, than create symlinks in /var:

mkdir /static-var
mkdir /static-var/cache
mkdir /static-var/lib
mv /var/lib/dpkg /static-var/lib/dpkg
ln -s /static-var/lib/dpkg /var/lib/dpkg
mv /var/cache/apt /static-var/cache/apt
ln -s /static-var/cache/apt /var/cache/apt
... # an so on

So when remounting in ro, copying /var in /dev/shm won't take too much space as most files are moved to /static-var and only symlinks are to be copied in ram.

The better way to do this finely is to make a full power-cycle, one day of full work and finely run a command like:

find / -type f -o -type f -mtime -1

So you will see which files needs to be located on read-write partition.


As in this host no writeable static memory exist, in order to store history and other logs, you have to config a remote syslog server.

echo >/etc/syslog.conf '*.* @mySyslogServer.localdomain'

In this way, if your system break for any reason, everything before is logged.


When running whith some mount --bind in use, for doing such an upgrade while system is in use (whithout the need of running init 1, for reducing down-time), the simplier way is to re-build a clean root, able to do the upgrade:

After remounting '/' in read-write mode:

mount -o remount,rw /

for mpnt in /{,proc,sys,dev{,/pts}};do
    mount --bind $mnpt /$mnt$mpnt;

chroot /mnt

apt-get update && apt-get dist-upgrade


umount /mnt/{dev{/pts,},proc,sys,}

mount -o remount,ro /

And now:

shutdown -r now
  • Thanks for your answer. I do not completely understand it as my Linux skills are not great at the moment. It is still very helpful though and gives me some more areas to research. Jan 14, 2013 at 10:23
  • Answer edited! New solution and explained diffs! Mar 22, 2015 at 9:22
  • This doesn't answer the question, it's a great answer for a debian based system, but Buildroot isn't debian based.
    – LovesTha
    May 16, 2016 at 1:01
  • @LovesTha Have a look at Old (first) answer! This is less Debian based and U could understand principle and implemant same mechanism for any kind of distribution/installation. (even if Upgrading section show Debian commands, U could do same for manual upgrading or any other distrib based upgrade.) May 16, 2016 at 8:31
  • Your old answer would be a great answer to a generic question about setting up read only Linux systems. Once I've finished my exploration of making our buildroot's read only I hope to come back and give a great detailed answer on the specific question here. Buildroot already has the temporary bits of /var symlinked to /tmp which is a tempfs. /etc shouldn't be used as a scratch space for programs, so it shouldn't need to be handled specially.
    – LovesTha
    May 19, 2016 at 2:06

I only have experience using a more recent buildroot (2014-02). In that version you can disable 'remount root filesystem read-write duing boot' in the config file with:


I managed to create an image that just uses its ext4 / partition as read only so unplugging the power of the system does not harm at all. It works great, so if you don't need to write to your filesystem, maybe this is a far simpler solution than the one mentioned above (which seems more or less applicable to a Debian system as it refers to apt-get).

  • Thanks for the answer - however in the end I opted for a initramfs setup with mounting just a couple of directories with sync option on the CF drive for data persistence. This has served me pretty well for the time being. Oct 1, 2014 at 11:40
  • To add to this: using older buildroot versions, check /etc/inittab if remounting of / happens there. If so, change it to your needs.
    – evnu
    Jun 19, 2015 at 8:10
  • 1
    This answer is an important piece of the 'buildroot way' to do it. Much of the advice in the accepted answer will be needed to make more complex systems work. Chances are though that all that will need to be done is set up a few extra symlinks to /tmp (tempfs) and everything works.
    – LovesTha
    May 19, 2016 at 2:00

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .