It is fairly well known that you can boot Linux from read-only media, such as a DVD. This works by booting the OS normally, but uses an invisible, writable overlay stored in RAM to make changes to its pseudo-file system. These alterations are then lost on a reboot.
You might want to start up a system read-only, but still make occasional changes. However, if you boot a Linux system from writable storage — even by cloning the read-only media onto read-write storage — you’ll find it writes some data to the disk. It is possible to change this behaviour, but doing so requires choosing a compatible Linux distribution and you have to rebuild (remaster) the OS yourself.
Comparison to Other Operating Systems
Linux has various overlay file systems, but Windows also has a similar but lesser-known feature called the Unified Write Filter, which allows you to prevent all disk writes. It collects all changes to the disk (usually by file or block), and then once a special kind of reboot is issued, the overlay’s changes are written in bulk just before the actual reboot occurs. There are also similar, third-party utilities for older embedded x86 systems.
Due to the way Linux is built, the overlay cannot usually be committed to disk in the same way, so changes are lost on a reboot. Linux is arguably far more favourable for embedded devices due to how lightweight it can be, but this hurdle makes using it a bit more difficult.
There is, however, an alternative solution so we can still keep Linux — mounting the disk as read-only, using an overlay, but allowing a temporary switch to read-write whilst changes are made. Specific writes then need to be made to the original disk to mirror certain file system changes, and then a reboot should be issued to ensure the device starts back up properly.
Tiny Core Linux on Embedded Systems
Tiny Core Linux is ideal for embedded systems, especially since it can boot a modern OS with as little as 64MB RAM, or 96MB with a GUI.
One small problem exists, just like it does in other distributions of Linux; if a writable volume is supplied to boot from, by default that volume will be mounted in read-write mode. It writes a small amount of data to the disk as it does so, which will be due to setting disk flags or updating the journal.
On an embedded system, we want to protect the boot volume from any kinds of writes, if possible. This maximises disk longevity, especially on some Disk-On-Modules (DOMs), which use NOR or EEPROM instead of NAND, and are much more susceptible to wear.
Mounting a file system as read-only is not a security feature. It does not protect the disk from all kinds of malicious writes. File systems can still be remounted as read-write with superuser elevation.
Verifying Disk Write Statistics
If we install and cleanly boot Tiny Core Linux from hard disk, we can see that it always writes to the disk on boot by running this command in the Terminal:
cat /proc/diskstats | grep sd
Post-boot disk stats (read-write)
This wouldn’t be great if the device was stuck in a boot loop!
Columns 8-11 correspond to different kinds of disk writes. Column 10, for example, is physical sector writes. If we wanted to prevent all disk writes for wear/protection purposes, the goal is to have all these values at 0, all the time, whether it is straight after booting, or after a year of use. This is of course with the exception that on occasion, we might make intentional changes.
Since the numbers are not zero, the disk has been written to upon boot. It’s likely a dirty flag or a journal entry was written to the storage device when the
sda1 partition’s file system was mounted, and these writes would be done again on a shutdown or reboot.
We want to stop all writes, and the only way to do this with Tiny Core Linux is to modify the boot loader so it brings up the boot partition as read-only, like if it was booting from read-only media, like a DVD.
You do this at your own risk. I offer no guarantees this will work properly, and take no responsibility whatsoever for any kind of loss. Ensure you have backups of your system before proceeding. This was done with the full, unmodified version of Tiny Core Linux 12, 32-bit. Other versions may be different. If you get any errors, stop and seek help!
Extract the Tiny Core Linux Root Directory
Elevate to superuser:
Create a temporary folder, switch to it, and extract Tiny Core Linux’s root directory into it:
zcat /mnt/sda1/tce/boot/core.gz | sudo cpio -i -H newc -d > /dev/null
You should see this after the decompression completes:
Modify the Bootloader
Edit the file
vi if necessary, and noting we’re working in the
/tmp/tc folder), and find the first instance of the line:
-o ro to add the read-only flag. Do not change the rest of the file:
mount "$MOUNTPOINT" –o ro
Now, save the file.
Remaster the OS
We now need to make these changes permanent. Remastering involves creating a custom version of the OS for your own purposes, making changes that would otherwise be impossible.
When starting Tiny Core Linux, the root file system is extracted from a GZip image on the boot volume. To get your system to start up completely read-only, you must place any changes in a new version of that file.
Follow the instructions here to extract the OS image, make the changes, and remaster it:
sh -c "find . | cpio -o -H newc | gzip -9" > /tmp/core.gz
Update the Boot Files
We now need to update Tiny Core Linux’s startup files:
Ensure you see core.gz in this folder, and then place the new file where it should be:
mv core.gz core-orig.gz
mv /tmp/core.gz core.gz
You should see both
core.gz in the boot folder. Now, restart the computer:
Verify the Changes
We can now check if our changes are good, by rebooting the system and running the same command as before:
cat /proc/diskstats | grep sd
Post-boot disk stats (read-only)
There are now zero writes since boot.
Applying Changes after Making the OS Read-Only
You may be wondering how to make alterations now you’ve booted the system in read-only mode. This is as simple as remounting the boot volume as read-write:
sudo mount -o remount,rw /mnt/sda1
Install software or make changes, as you normally would, then restart the computer as normal:
The computer will then reboot, but the file system will come back up in read-only mode with your changes intact. You also remount the disk as read-only if you really don’t want to reboot, but I always recommend checking everything works from a clean start!