Read-only filesystem - Considerations and Loss of Functionality

Question

I'm creating an embedded system using Buildroot. Currently, my Buildroot configuration ensures the rootfs is remounted as read/write during startup. However I would like to remove this feature and keep my rootfs as read-only.

I have a few questions regarding this:

---

How do I change a user's password? This would require changing /etc/passwd & /etc/shadow.

How do I change the timezone? This would require changing /etc/localtime.

How do I create ssh keys for sshd? ssh-keygen creates the keys in /etc/ssh/

According to the Filesystem Hierarchy Standard, a Linux system is required to function with a read-only /etc/ directory, but it seems I'm finding a distinct loss of functionality as described above.

---

Secondly, after specifying that the rootfs is to remain read-only in my Buildroot configuration, it elects to mount /var/ as a tmpfs (in RAM, so it is writable)

But, this is volatile, how can I ensure runtime files (which I need to save) aren't lost on reboot or unexpected power-loss?

I'm using UBIFS, in my embedded system. Am I required to create a read/write UBI volume which I use as persistent storage? Is this the standard in embedded systems?

---

And finally, should I re-evaluate my idea to use a read-only rootfs at all? Given I am using UBI, and as wear-levelling is implemented across all the UBI volumes (the exist on the same device, of course), will I receive any benefit in making my rootfs read-only?

Answer 1

Keeping the filesystem mounted as readonly esures, that nothing is modified in an unexpected manner.

To allow certain operation it is required to work with specific file system partitions: - System partition: readonly - User partition: writable

Losing the user patition may only revert the embedded device to default state, but may not result in a permanent inacessible device.

To allow certain operations i. E. changing passwords, it is required to symlink specific files to the user partition. - /etc/passwd -> /mnt/user/passwd - /etc/ssh -> /mnt/user/ssh - /etc/localtime -> /mnt/user/localtime

To make the password access more robust, it may be a good idea to redirect passwd to tmpfs instead and then fetch the password from the user partition during startup.

The aproach may lead to issues regarding the timezone. It may be required to patch tzdata to directly use /mnt/user/localtime if double linking results in an error: /etc/localtime -> /mnt/user/localtime -> /usr/share/zoneinfo ...