Edit single file in read only OS on AM335x EVM SK

Hi Tim,

I have not done this on Sitara, but I know that this is possible in a Debian Linux and I'm sure that this is possible also in a EZSDK 6. You have to have several rw directory to make kernel write a logs and other system files. Also you can runtime change permission of directory. But for details you have to see in Google and:
wiki.debian.org/ReadonlyRoot

BR
Ivan

Hi Ivan,

Thanks for your reply, using the link you gave me as a guide, I was able to put together (what I think is) a pretty decent working read only OS. For anybody trying to do this in the future, I've written below what I did.

I needed an SD card with 3 partitions. The first partition contains the boot information. The second partition contains the root file system, and will be mounted as read only. The third partition contains /var with various subfolders (covered more below) and will allow me to read and write specific files.

I needed to make an SD card with 3 partitions, but first I needed 3 tarballs of the various partitions.  This is because the create-sdcard.sh script that I was going to use required 3 tarballs.

When using the script to make 3 tarballs, the script asks for .tar.gz files containing the OS and some other files. Specifically it asks for rootfs_partition.tar.gz, boot_partition.tar.gz and start_here_partition.tar.gz. I found the simplest method was to copy the partitions from the SD card to my ubuntu computer, and then compress both the boot partition and rootfs partition into their respective .tar.gz files. I then compressed just the /var folder of the rootfs partition into the start_here_partition.tar.gz file.

Now that I had 3 tarballs, I ran the create-sdcard.sh script and selected the option to create an SD card with 3 partitions. The script asked for the folder containing the 3 tar.gz files. In my case I had them stored in my home directory. I then followed the rest of the default options of the script and allowed it to create the SD card.

Now that I had an SD card with 3 partitions, it was time to make the OS read only. I edited my /etc/fstab file. I looked for the line in the file that looked like: 

rootfs     /      auto     defaults       1  1

and changed it to:

   rootfs     /     auto     ro,defaults     1  1

the "ro" indicates read only.

We aren't done in this file yet. The OS requires some files to be writeable. This is the purpose of the third partition. I have made it so that all files that I will need to write are stored somewhere in the /var folder contained within the third partition.

Immediately below the line I just edited, I added the line:

    /dev/mmblk0p3     /var     ext3      rw,defaults     0  0

this mounts the third partition as read/write to the /var location.

At the bottom of the list, I added a few other lines.

    tmpfs     /media     tmpfs     defaults     0  0
    /var/local/home     /home     auto       defaults     0  0
    /var/local/srv     /srv     auto     defaults     0  0
    tmpfs      /tmp     tmpfs     defaults     0  0

These lines will give me a tmp directory that will be erased every time I reboot, and writeable home and /srv directories. The /media directory allows me to mount USB drives if they are plugged in to the USB port.

These are all well and good, however there are some files that are stored in the /etc folder that need writing to. Some files that come to mind are /etc/timestamp, the /etc/networking folder, and the /etc/pointercal (touch screen calibration backup data). What I did for these files was create symbolic links to get around not being able to write them. I copied the files to /var/local/etc, removed them from the /etc directory and linked the files I just made into the location of the files I just deleted using the command "ln -s /var/local/etc/filename /etc/filename" where filename is the name of the file you are making the link for.

I've been playing around with the boot order in order to give the appearance of a faster boot, so I'm not sure what else people might need to do in order to get an error free boot. In the simplest terms, if something gives you an error during boot, either remove it from the boot process if it is unnecessary OR move it to your /var folder and create a symbolic link to the file that is causing the error.

After firing this system up, I noticed that my home folder was not being mounted correctly, in fact it wasn't being mounted at all. After the system had booted I could type in the command "mount -a" (mount all file systems) and nothing would happen. If I navigated to /var/local/home/root and then typed in the command "mount -a" THEN my home folder would mount correctly. I'm not sure why this is, so I had to come up with a workaround. I chose to modify the script that loads my application on my screen. Immediately before calling the application (which is stored in the home directory), I added the following lines to the script stored in /etc/init.d/application.sh: "cd /var/local/home/root" and then on the line below "mount -a". This resulted in the correct files being mounted and the correct applications being run.

From the research I've been doing on-line, it sounds like ext3 is a very robust file system thanks to the journalling, even in the event of unexpected power failures. Keeping as few files as possible in the /var folder cuts down on the number of blocks that are being written to, which again will help provide robustness in the event of unexpected power failures. The rest of the OS is either temporary or read only, and so are pretty much impervious to the effects of power failures.

If anybody else has been trying this, or has thoughts about things I could do better, post them below. Any thoughts are appreciated.

This is a good guide and discussion, thanks for posting it.

One thing I am wondering about is how robust a rw partition on the same physical device is.  If sd cards acted like hard drives this would seem quite robust, but most sd cards have a controller inside the part which provides wear levelling.  The wear levelling algorithm could be oblivious to things like partitions, could it not?

To be honest, I don't know enough about SD cards and how they work to say one way or the other. I'm not sure how the partition mapping would work with regards to a wear levelling system and how the OS would keep everything straight.

If the wear levelling system ignores partitions as you say, then it would seem like the only way to get around something like this would be physical isolation. Anyway, the plan in our final design is to use two separate SD cards, one for read only, one for read/write.

Does anyone else have any thoughts on the wear levelling in SD cards and how it works with partitions?

I've looked into this some more and the short answer is that the wear leveling algorithm in some/most SD cards will ignore partitions and thus your read only file system will not be 100% safe if the same device is being written to.

It will likely end up being less likely to corrupt files in your ro file system though. This is because by partitioning the SD card you keep your rw files together in blocks within the SD card. They'll have to move a lot more frequently than the blocks that are just moving because of wear leveling. This is because flash blocks will move to a new location when they are updated, and the blocks are quite large, so often the data from many files in a partition will move even when just a single small file is updated. So if the data stored in your rw area is not crucial then this is more reliable...but still not 100% if that is your need.

There's lots more data available if you go through the data sheets from manufacturers like Kingston and SanDisk. Panasonic and Swissbit also make industrial grade SD cards which are advertised as being uncorruptable. They are expensive.