Put rootfs in readonly


I have build a monitoring system which is "portable" and based on OpenWrt (and docker for the monitoring part of app) and a raspberry pi 3.

Why OpenWrt ? Because it is very convenient for managing the network access (WiFi + ethernet + 4G dongle + VPN) and also for the easy upgrade process.
I made a custom build with more packages and my configuration preloaded.
I added a additional ext4 partition mounted as /opt for docker persistence over upgrade.

My only issue today is the rootfs corruption when using ext4. It happened once that network config as resetted (removed IP settings and so...)

The first solution I found is to remount / as readonly in rc.local.
Then I moved to squashfs and it seems to be better, but I would like to put the rootfs in readonly mode.

Is there any better solution or any advise for my use case ?

Thank you

you want to put it as ro instantly, while booting ?


ro parameter.

1 Like

Yes, I would like to be readonly by default (and remount as rw if needed).

Sorry, I forgot to mention that I also tried the ro parameter at the end of cmdline.txt without success.

EDIT : to be more precise, I can see (dmesg) that the rootfs is first mounted as readonly, then remounted as read-write.

and what does fstab say ?

you may use a rootfs overlay...
Your main rootfs will stay ro (and mount as /rom)...
You will have a modifiable system, crashless, and with original rootfs as rom (ReadOnly)...
May need some tweak to fit your needs, but personnally I get all my boards with this style of systems layers !

No more rootfs corruption, the worst situation get a auto repair and reboot...

1 Like

@frollic : /etc/fstab is empty by default.
So, when I added the ro flag in cmdline, I also tried fstab 2 times. First with :
/dev/mmcblk0p2 / ext4 ro,noatime 0 1
Then with
/dev/root / ext4 ro,noatime 0 1
because /proc/mounts show /dev/root :
/dev/root / ext4 rw,noatime 0 0

@erdoukki : rootfs overlay is new for me. Can you explain more what you did and how ?

Thank you both for answering such a specific request.

can you in dmesg see something like this, containing the added ro param

Bootloader command line (ignored): console=ttyHSL1,115200n8 root=mtd:rootfs rootfstype=squashfs

[ 0.000000] Kernel command line: coherent_pool=1M 8250.nr_uarts=1 snd_bcm2835.enable_compat_alsa=0 snd_bcm2835.enable_hdmi=1 bcm2708_fb.fbwidth=1824 bcm2708_fb.fbheight=984 bcm2708_fb.fbswap=1 vc_mem.mem_base=0x3ec00000 vc_mem.mem_size=0x40000000 console=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=squashfs,ext4 ro rootwait

And content of cmdline.txt :
console=serial0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=squashfs,ext4 ro rootwait

ok, so it's read, check ...

The wiki has recently changed, but it looks like here are some stuff : https://openwrt.org/docs/guide-user/additional-software/extroot_configuration

For me, I have a 4Gb eMMC, and I used firmware from OpenWrt which do not fill the eMMC...
So I use an extend (third) partition, to clone my rootfs on it...

here are from my notes some tweaks :

prepare the disk partitions :

opkg install fdisk

prepare the root partion :

fdisk /dev/mmcblk0

prepare the root file system :

mkfs.ext4 /dev/mmcblk0p3

clone the rootfs content to the new rootfs :

mkdir -p /tmp/cproot
mount --bind / /tmp/cproot
mkdir /tmp/mmcblk0p3
mount /dev/mmcblk0p3 /tmp/mmcblk0p3
tar -C /tmp/cproot -cvf - . | tar -C /tmp/mmcblk0p3 -xf -
umount /tmp/cproot
rmdir /tmp/cproot
umount /tmp/mmcblk0p3
rmdir /tmp/mmcblk0p3

install the block-mount (luci and uci)

opkg install block-mount
block detect
block info

add you're new partition for the rootfs

vi /etc/config/fstab
config mount
        option enabled '1'
        option enabled_fsck '1'
        option target '/'       
        option device '/dev/mmcblk0p3'

then reboot and you'll get a ReadOnly rootfs in /rom and a Read Write rootfs on /
The both will be auto repaired in cased of crash, hard reset or switchoff...

verify your filesystems status with


At Upgrade, you'll need to reinstall fdisk, kmod-fs-ext4, block-mount, if needed.
Then you'll have to clone again the new upgraded filesystems (/rom) to the third partition rootfs !
You may need to do this from recovery mode, or to disable /rootfs and clone it before re-enable it !

keep of configs while upgrading may confuse the system, and need some manual tweaks...

Hope this will help...

Thank you, this is a great option and I will give a try.

But as long as I don't need to modify the rootfs (custom build preconfigured), I will still hear from @frollic for a real readonly rootfs.

Hi there.

When I started this topic, I have updated my build with 21.02 r16278 (the ext4 failure happened with rc2).
Then I tested it with a powerplug which integrate a contactor with a "random" cycle.
It was working for more than 2 weeks without any problem and using ext4.

So : is there any chance I was facing an issue specific to rc2 ?

EDIT : Seems to happen if I cut the power during boot. I will do more tests.

Finally went for your solution, thank you for your help.

1 Like

advice on the updates of my recommendations here : Request for Best Practice for eMMC devices !

I am doing it a little bit different.
As my device is fully remote (no physical access), I need to keep it connected to a VPN server (because of CGNAT).
So I build my own image with vpn packages, block-mount and config files.

So, my extroot will always be mounted on /. Will it be possible to update it will in use ?

How do you format/prepare or reset you extroot ?
The firmware may only contain configs and needed package as kmod-fs-ext4 and block-mount, but how do you prepare the extroot partition ?

On the first boot, the 3rd partition does not exists. I create it, mount on temporary mount point then copy all files.

Okay, thanks...
So usual and default method.
Take care on the update method of opkg extras.
You need the news scripts that take care of the overlay status...
I do not tests them for now...
I will, I hope soon !
So I cannot answer YES for now !
Another possible issue;
If you upgrade your system, the partition map will (or may) change and the third partition may be broken and needing to be reset (re-prepare like first time)...
You also always need to sync (copy the real root content to your rootfs) after an upgrade !

Thank you

So, for the last 2 points :

  • The 3rd partition is far away from the second one (1GB). So, I hope to stay safe :slight_smile:
  • The sync is not clear for me. Can we sync a "running" extroot ?
1 Like