Q: immutable system?

[lukasMega]

Dear DietPi creators,

Have you considered implementing an immutable system design?

Are there any recommended resources or official documentation describing how to achieve this with DietPi?

I am aware that the filesystem can be mounted as read-only. However, what is considered best practice when introducing a permanent change—for example, installing a new package or modifying /etc/hosts?

Would the correct operational procedure be:

1)Remount the filesystem as read-write
2) Apply the required changes
3) Remount the filesystem as read-only

Additionally, I plan to store all configuration related to DietPi/Debian in a self-hosted Git repository (hosted on a separate machine) and manage the entire DietPi server declaratively from that repository as a single source of truth.

---

What is immutable system:

• https://thenewstack.io/why-enterprise-businesses-should-adopt-immutable-linux-for-the-desktop/
• popular examples of pure immutable linux are: NixOS, VanillaOS, BlendOS, openSUSE MicroOS, Fedora Silverblue, Fedora Kinoite

[MichaIng]

In how far is this something we can implement? I mean every admin can remount the rootfs ro, or add that flag to /etc/fstab. Of course some applications and services might throw errors or fail trying to write to their /var/lib/<name> or similar. At least we do have RAM logging (/var/log as tmpfs) enabled by default already, but other software require setup adjustments.

One thing we can do is allowing /boot/dietpi/func/dietpi-obtain_hw_model to not fail if /boot/dietpi is R/O while /boot/dietpi/.hw_model exists. A DietPi update recreates /boot/dietpi/.hw_model, and it is done when running our distro upgrade scripts, so chances are low that people run into issues.

[lukasMega]

Dear DietPi Team,

Thank you for your clarification.

From my perspective, the goal is not to make DietPi strictly immutable in the same sense as systems like NixOS or Fedora Silverblue, but rather to operate it in a production-style configuration where:

• The root filesystem remains read-only during normal runtime.
• Persistent state is confined to explicitly defined partitions or mount points.
• All configuration is version-controlled externally (Git-based single source of truth for example).
• Changes are applied in a controlled maintenance window (temporary RW remount + reconciliation).

Your note about /boot/dietpi/.hw_model is helpful. That is exactly the type of edge case I am trying to identify early so the model can be predictable and robust.

Would you consider the following a safe operational assumption?

• RootFS read-only during runtime
• Explicit writable mounts for required paths
• RW remount only during dietpi-update / package upgrades
• Acceptance that some third-party software may require manual adjustment

If there are known components beyond RAM logging that inherently expect root write access during normal operation, I would appreciate guidance so I can design around them.

My aim is to build a highly reliable, reproducible DietPi deployment (Raspberry Pi / Odroid H4 + SSD data partition), and I would be happy to share findings or documentation if this approach proves viable.

Thank you again for your time and for the excellent work on DietPi.

[MichaIng]

EDIT: Ah sorry, I misread "not to make DietPi strictly immutable in the same sense as". So yeah, as mentioned from 2nd paragraph on, we can adjust our scripts/functions to consider that case. Though I would prefer to do this in case of an dietpi.txt setting. Otherwise, the scripts might remount the rootfs R/W automatically while the admin is not intending this. We better be explicit than implicit in such cases.

Uh, you mean this to be the default? Impossible, really, we support 200 software options with a lot of them requiring to write to disk to do their job. For most, we know (or actively limit) where they write to, but we cannot expect admins to setup a 2nd drive that is mounted to all those locations. And we do not thoroughly configure all software, a lot is just default Debian (or 3rd party repo) DEB package, which might or might not write to /var/lib/<name>, /var/log/<name>, /etc/<name>, or any other location, we might or might not know about, or which might change after a package upgrade.

On the script level, we do have the G_CHECK_ROOTFS_RW that is called by every script that requires write access (surely we missed some cases). That could, based on some dietpi.txt setting or so, remount the rootfs R/W, and the G_EXIT called in most (but all) scripts, could based on the same setting remount it R/O again.

Means: we can adjust some of our scripts and functions to consider the case, making it easier for admins to setup a R/O rootfs. But it will at least break most dietpi-software options without manual adjustments, and hence cannot be the default. Adjusting dietpi-software options to work with this is far beyond our scope, as this would easily double maintenance efforts (after the huge task to implement this at first).

That said, we do adjust many of the software options a way that they use /mnt/dietpi_userdata/<name> as config+data dir, and not usually write elsewhere. This is not the case for all of them, but I would not have any issues with applying this convention to more cases. Important for me is that it avoids breaking changes, like /var/lib/<name> and where needed even /etc/<name> as symlink, and carefully handle the migration to rule out that any data and config are ever lost. That way you would have that single point of writes applied to more cases, and with dietpi-drive_manager it possible and intended for production systems to move /mnt/dietpi_userdata entirely on an external drive, easing backups, potentially enhancing performance etc. It could help with the R/O rootfs aim, but again, it cannot be the default, as we cannot expect an external drive or that admins use dietpi-software at all. Generally, DietPi is intended to work as regular Debian, with all its flexibility, and our tools shall be entirely optional to make things easier and faster.

EDIT2:

If there are known components beyond RAM logging that inherently expect root write access during normal operation, I would appreciate guidance so I can design around them.

Searching the code for G_CHECK_ROOTFS_RW calls is a starting point to see which scripts require it. But some cases could be missing. Otherwise, DietPi is a light Debian, so if a default Debian server system is writing somewhere, DietPi might as well. Some things:

• /var/log is already a tmpfs by default in our case.
• We will switch from isc-dhcp-client to udhcpc with nex release, which does not write leases to /var/lib/dhcp anymore.
• fake-hwclock writes hourly to /etc/fake-hwclock.data. systemd-timesyncd does the same every 5 minutes with /var/lib/systemd/timesync/clock, if running as daemon. So this is some feature broken in that case, not sure how to solve it, or whether to just accept: it means that the system will boot with some old manufacturer or kernel timestamp, until a network time sync is done.

[lukasMega]

Uh, you mean this to be the default?

• No, of course not as default. I'm aware it would breaks many systems. Just as an option. I was interesting if you consider something like this.

we do adjust many of the software options a way that they use /mnt/dietpi_userdata/ as config+data dir, and not usually write elsewhere. This is not the case for all of them

• I like this idea to store all dietpi-software relevant data into /mnt/dietpi_userdata/

• I thought all dietpi managed software uses exclusively this path

  • but you wrote:

    • This is not the case for all of them

• I think it's ok if some app do some writes to disk.

My intention is mainly to be sure that if some unwanted program (malware, virus,...) tries to change / break / delete some system config - there is some mechanism to prevent this.
UPDATE:
or if some existing software after update will try to start doing something unwanted

I found there are related tools for it like:

• etckeeper - https://documentation.ubuntu.com/server/how-to/backups/install-etckeeper/
• AIDE - https://aide.github.io/

Thank you very much for detailed answer. I appreciate it.

[MichaIng]

I mean, UNIX permissions alone, for services the systemd sandboxing as 2nd layer, should prevent any malware/virus from manipulating system files. If it has root access (outside of systemd sandboxing or a container), it can by itself remount the rootfs R/W. So if it is about security, it makes much more sense to start consequently adding the hardening/sandboxing features of systemd to all services we create or install in dietpi-software. We started to implement those for all new software titles, but applying those retrospectively requires testing to rule out breakage, so this is done only very gradually at the moment. Debian itself (its official maintainers) are already implementing those more and more into their packages, and e.g. a native systemd unit is already mandatory since ... Trixie or Forky, need to check. Webservers still start as root, and drop privileges for worker processes, and this could be changed, maybe I find time to implement our end, and offer those changes to Debian maintainers if proven to work well. So this is what I would focus on for security related to potentially harmful rootfs writes.

Of course having the rootfs R/O is another layer, does not hurt, but comes which quite some additional efforts for admins. And the security impact, if processes are consequently launched with minimal permissions and maximal sandboxing, is minimal, would only apply for malware that does not even attempt a R/W remount. But I see this more as step to prevent mistakes, similar to how you would not login as root, but use sudo only explicitly. And it would be a step to have more monitoring and control over where/when/how often certain (otherwise trusted) software writes, potentially reducing disk writes. systemd sandboxing has the same effect, but not all software runs in a systemd unit, there are CLI applications that create ~/.local ~/.config ~/.cache etc, and it is certainly not a bad idea to be more aware of such, find our which writes are for what, gain control.