Skip to main content
Version: 6

How to implement a Read-Only Rootfs (Linux)

info

This page has not been fully updated to reflect the changes made in Toradex Linux BSP 6. Some information may still apply to Toradex Linux BSP 6 configurations. If you encounter issues, please Send Feedback.
If you are using version 5 LTS, please visit the 5 LTS version documentation.

Introduction

In this article we have three distinct sections with complementary goals regarding the implementation of a Read-Only Rootfs on Toradex BSP and Reference Images. The sections aim to:

  1. Overview: Present an overview of read-only rootfs, its advantages and limitations;
  2. Implementing a Read Only Rootfs: Guide on how to implement such a system using yocto project;
  3. Considerations: Warn and discuss some important points to consider in your embedded software project that might be affected when using a read-only rootfs.

Overview

A read-only root filesystem is an interesting characteristic when in embedded systems. Under many advantages, there are some we can highlight:

  • Reduce wear leveling on flash memory devices;
  • Reduce the probability of corruption of system files;
  • Enable rootfs images to be easily updated;
  • Allow easier reset to factory state.

On the other side, it's not simple to develop such a system, since there are features that won't work with a system read-only. In other words, the features of the read/write filesystem are used in several parts of the system, limiting the possibility to mount a RO filesystem. These limitations emerge in several situations. For example:

  • Passwords;
  • Module hostname;
  • SSH keys;
  • Systemd machine-id.

If you want to go deeper into this topic, refer to Read-only rootfs - Theory and practice.

Supporting a read-only root filesystem requires that the system and applications do not try to write to the root filesystem. Because of this, our base BSP layers and reference images do not support read-only filesystems, although in the section Implementing a Read Only Rootfs we present a workaround for you to make your system (based on Toradex BSP) read-only.

Torizon

TorizonCore uses a read-only rootfs system by default i.e., most of the filesystem is mounted read-only. So, if you are looking for a rootfs read-only you may consider using Torizon.

If you are looking for information about read-only rootfs on TorizonCore, refer to OSTree and TorizonCore Technical Overview - Root Filesystem.

Implementing a Read-Only Rootfs

If you are trying to make your system RO, you may start with the reference minimal image, since this kind of rootfs may cause many problems on the reference multimedia image. So, the following steps were tested with the tdx-reference-minimal-image.

  1. Add the following line to the conf/local.conf file:
EXTRA_IMAGE_FEATURES = "read-only-rootfs"
  1. Create a patch file to add back the defaults option on the fstab. This patch should be applied to the meta-toradex-demos layer.
/recipes-core/base-files/base-files/fstab b/recipes-core/base-files/base-files/fstab
diff --git a/recipes-core/base-files/base-files/fstab b/recipes-core/base-files/base-files/fstab
index 6ccd038..8131cd4 100644
--- a/recipes-core/base-files/base-files/fstab
+++ b/recipes-core/base-files/base-files/fstab
@@ -1,6 +1,6 @@
# stock fstab - you probably want to override this with a machine specific one

-/dev/root / auto noatime 1 1
+/dev/root / auto defaults,noatime 1 1
/dev/boot-part /boot auto noatime,noauto 0 0
proc /proc proc defaults 0 0
devpts /dev/pts devpts mode=0620,ptmxmode=0666,gid=5 0 0
  1. If you are using a Verdin SoM, you must disable the alsa-state package hooks. To perform this, create an append file in your meta-custom layer to overwrite these configurations. The changes proposed below essentially disable the automatic configuration setup. So, if you are interested in using audio, create the append to install the proper alsa configuration according to your codec setup.
meta-custom/recipes-bsp/alsa-state/alsa-state.bbappend
pkg_postinst_${PN}_mx8m_tdx () {
}

pkg_postinst_ontarget_${PN}_mx8m_tdx () {
}

do_install_append_mx8
  1. Bitbake your image and deploy it to the module.

  2. When inside the module, check the /etc/fstab to make sure your system is now read-only.

# cat /etc/fstab

/dev/root / auto ro 1 1
/dev/boot-part /boot auto noatime,noauto 0 0
proc /proc proc defaults 0 0
devpts /dev/pts devpts mode=0620,ptmxmode=0666,gid=5 0 0
tmpfs /run tmpfs mode=0755,nodev,nosuid,strictatime 0 0
tmpfs /var/volatile tmpfs defaults 0 0

Another simple test to see if everything works fine is to check if you can create a file inside your system. If you can't, your rootfs is read-only.

Considerations

If you wish to proceed with a read-only rootfs, there are some project decisions you may have to consider before implementing it.

  1. File creation and editing: If your project requires to create or update files and directories at runtime, you may conflict in adopting a read-only solution, because you are not allowed to create a file inside your rootfs, since it is stateless.

  2. Multimedia features: Toradex multimedia reference image chooses tradeoffs for usability and testability that conflict with the use of a RO rootfs. So the tdx-reference-multimedia-image should not be used if you are interested in a system such as this.

  3. Alsa with Verdin SoMs: As mentioned in step 3 of the Implementing a Read Only Rootfs section, the alsa alsa-state package may be a problem if you are trying to make your system read-only. However, if your project does not require audio features, you can easily proceed with the steps to a RO rootfs. However, as explained before, if you are interested in using audio, you can create an append to install the proper alsa configuration according to your codec setup.

Send Feedback!