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?
Best Answer
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 anotherunionfs
tool) to permit live session changes but in RAM by default, so everything is forgotten at reboot.You could install them by running simply:
Once done, from online doc:
From there, if some file is protected against changes, for sample by
if you use for sample
vi myfile
and try to write on it with command:w!
, this will work and yourmyfile
became changed. You may reboot in order to retrieve unmodifiedmyfile
.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
andmount --bind
:You could before, move all directories who have not to change in normal operation in a
static-var
, than create symlinks in /var: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:
So you will see which files needs to be located on read-write partition.
Logging
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.In this way, if your system break for any reason, everything before is logged.
Upgrading
When running whith some
mount --bind
in use, for doing such an upgrade while system is in use (whithout the need of runninginit 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:
And now: