Clarify Project Policy on Default Writes to NVRAM
Tom Li
tomli at tomli.me
Fri Aug 22 08:31:00 PDT 2025
Hi all,
For OpenWrt routers, writing to NVRAM by default can serve useful
purposes in several contexts:
1. Saving a /dev/urandom seed file after boot, to prevent early-
boot entropy starvation in the next boot. This was first discussed
in 2016 [0], and raised again in 2022. [1]
2. Saving the last-known system date and time to /etc/dnsmasq.time
for DNSSEC timestep validation, on every SIGTERM and reboot.
Discussed in [2].
3. Saving the current IPv6 prefix on the WAN port (obtained from
the ISP) to a file. If the router reboots due to power loss, and
the ISP changes the IPv6 prefix in the next boot, the old prefix
can be invalidated in a Router Advertisements to prevent IPv6
outages in the LAN due to stale addresses. This is known as "Flash
Renumbering Workaround Across Reboot", a recommended feature by
RFC 9096 to work around broken ISPs. This need is raised in a recent
odhcpd devolopment discussion [3], and is my motivation of sending
this mail.
An obvious objection to all of these behaviors is that, writing
to the filesystem by default can cause unwanted NVRAM wears.
As a result, any project discussion that involves writing to the
filesystem would quickly become an off-topic one about "whether
one should write to NVRAM by default" rather than its original
problem. Although the answer seems to be "No, we shouldn't", but
those discussions had an extremely limited audience - only a
few developers (perhaps 3) who happened to work on that specific
project were involved, their ideas and conclusions are not known
to others. The next time the same problem is raised in a different
context, the whole discussion repeats again. For example, in [1],
Etienne Champetier said that they "would love to have more devs
comment".
While I was writing this mail, I just found it was also discussed
on the context of https-dns-proxy [4] in 2024 - dnsmasq config was
changed on every https-dns-proxy service restart, which was reported
as a bug.
Therefore, I think it would be a good idea to define a clear OpenWrt
project policy on default writes to NVRAM in this mailing list, so
all future developers could refer to the policy.
We need to answer these questions:
1. In the current OpenWrt Stable Release or Development Build,
do we have anything that writes to the filesystem by default
(e.g. do we still have /etc/dnsmasq.time)? If yes, do we have
a full list of them?
2. When is it acceptable to write to NVRAM by default? Always
banned? Or is it conditionally allowed, with a rate limit (based
on the file's timestep and NTP time, via NTP hotplug)? My
impression is that rate-limited writes are allowed by the project,
but this needs clarification.
3. Should we set a filesystem default-write policy for all OpenWrt
packages?
4. In a previous discussion, an alternative solution was suggested
by John Crispin that "let's add a system.system.write_state_to_
flash_on_boot=0/1 UCI option, and lock this and the DNSSEC time
stuff with it, and default it to 0". Should we consider this idea?
Thanks,
Tom Li
[0] https://www.mail-archive.com/lede-dev@lists.infradead.org/msg01225.html
[1] http://lists.openwrt.org/pipermail/openwrt-devel/2022-March/038340.html
[2] https://www.mail-archive.com/lede-dev@lists.infradead.org/msg01265.html
[3] https://github.com/openwrt/odhcpd/issues/244
[4] https://github.com/openwrt/packages/issues/23469
More information about the openwrt-devel
mailing list