Read-only file system and custom RW data partition in iMX7D

Hello everyone,

I have divided the iMX7D eMMC in multiple partitions as follows:

  • p1 → Kernel / device tree partition (as default)
  • p2 → Root FS (as default)
  • p3 → Root FS 2 (used for FS update)
  • p4 → Flags (used for FS update)
  • p5 → Data partition

I would like the root file system to be mounted as read-only and use p5 partition as the only RW partition for storage purpose.

I am compiling the “console-tdx-image” with the following mods in local.conf (as suggested here Unable to mount file filesystem as read only - Toradex Community).

EXTRA_IMAGE_FEATURES = "debug-tweaks tools-debug eclipse-debug package-management read-only-rootfs"
DISTRO_EXTRA_RDEPENDS_remove = " angstrom-libc-fixup-hack"

The compile ends with no errors, but when I install the new image on my module, the filesystem is still mounted in RW. (I also tried a complete new image build).

I have analyzed the kernel boot arguments passed by u-boot and they seem ok:

emmcargs ip=off root=/dev/mmcblk0p2 ro rootfstype=ext4 rootwait

The only working solution I found was to modify the /etc/fstab file in Yocto like this:

/dev/root            /                    auto       ro,noatime               1  1
proc                 /proc                proc       defaults              0  0
devpts               /dev/pts             devpts     mode=0620,gid=5       0  0
usbdevfs             /proc/bus/usb        usbdevfs   noauto                0  0
tmpfs                /run                 tmpfs      mode=0755,nodev,nosuid,strictatime 0  0
tmpfs                /var/volatile        tmpfs      defaults              0  0

Is it the correct way? Why the boot argument “ro” is uninfluent?

I’m working with BSP v2.8.

Thank you in advance for your help.


Hi @marcel.tx ,

if the root file system is usually re-mounted as RW, which is the best practice to prevent any unwanted write access to critical file system areas?
I would like that my application can potentially write only in a specific memory partition and that someone with malitious intents cannot modify system configurations.


I’m not saying your approach is flawed, not at all. You’re probably just missing a vital detail in how to get the read-only root file system to work. I just wanted to give you a hint about how that nowadays works in the regular “distro” case.

Usually, nowadays all Linux systems are initially booted with a read-only root file system and systemd re-mounts it read-write after completing certain checks. So, that ro boot argument is basically only applicable at the very beginning during the boot process.