Introduction of a small, persistent "cfg" partition in openwrt's mtd partitioning

Feature Requests
1

Subject: Introduction of a small, persistent "cfg" partition in OpenWRT's MTD partitioning

Hello openwrt community,

I hope this message finds you all well. Recently, during my work on a project, I found the need for a small, persistent data partition alongside the rootfs_data when working with mtd partitions. This partition, which I named "cfg", has proven to be beneficial in several ways, especially when working with persistent data requirements, and I believe it might be a useful addition to the wrt ecosystem.

The "cfg" partition is particularly useful when there are essential parameters that need to be preserved even if we erase the entire overlay file system or when dealing with a ramfs rootfs. For instance, during an EasyMesh certification process, this partition was essential for preserving persistent data.

Creating this small partition is fairly simple, and involves just a bit of adjustment in the mtd partitioning structure. Here's how it can be done:

  1. Define the size of the "cfg" partition. For example, we can set it to 1MB. This size could be made configurable via a kernel configuration option or directly from optional kernel arguments.

  2. Subtract the size of the "cfg" partition from the rootfs_data partition, essentially carving out a small portion of it.

  3. Label this new partition as "cfg".

To enable this "cfg" partition, a new kernel configuration option needs to be added. The size of the partition could either be set using another configuration option, or directly from optional kernel arguments. Once enabled, the partition can be used by any applications or processes that require a small amount of persistent storage.

I believe that adding this feature to openwrt could be a significant enhancement, especially for those working with persistent data requirements.

If the community finds this idea beneficial, I am more than happy to share the work I have done so far, and contribute to making this a feature in openwrt. Please share your thoughts on this idea

2

You are reinventing nvram, something that was abolished with prejudice in the kamikaze release cycle 16 years ago. This concept simply doesn't work across targets, it accumulates cruft and behaves badly over upgrades.

6 Likes
3

I appreciate your response However, this approach is not reinventing nvram., keeping values like MAC addresses, radio calibration data has nothing to do with keeping userspace data in fact, some nvram like the one of bcm should not be overloaded by data that don't belong to bcm so all in all the proposal in question is not a direct parallel. Instead, it is an optional, designated space designed specifically for unique scenarios such as the persistence of certain TR-181 parameters required for EasyMesh certification or for some operators requirements, we are already using this approach in TARGET_ipq40xx for example.

Moreover, the feature can by default disabled unless if the developer enables it which means he know what he is doing.

4

It kind of is, while it might not be evaluated by the bootloader, you will end up with syntax issues over time (just think about swconfig --> dsa). The expected service life of an OpenWrt device may be around a decade (give or take), so 7-12 major releases. Very similar consideration apply, both in terms of long term config compatibility, 'cruft' collecting and support for very different targets and storage technologies (spi-nor, NAND (parallel/ serial), eMMC, HDD, SSD, USB sticks), different partition tables, etc.

5

Can you better explain why one would wish to have persistent data, or save it?

Also, does this example mean that if someone were to sell or give their device to another user, that the device would remain registered under the previous owner's account?

This would be too large for many devices.

I'm interested to understand others' need for this. Can you give some examples of "persistent data requirements"?

6

Hi

suppose you have some essential config in this CFG partition, and for some strange reason, this config is bad, unusable, etc and your device depending on this CFG
as you say, this partition will survive factory reset/overlay erase ... and your device will not boot because data is in bad shape :frowning:
hmmm ?

7

If you bought a high-end BCM router, for example, you'll find that there is a dedicated read-write (rw) mount-point that does not belong to the root (/) mount-point. This setup is achieved using a boot script that utilizes UBI tools to configure it. This cannot be done when using MTD because it requires the partition to be defined directly from the MTD driver in the source code, which is not the case. Since this feature is optional, it does not affect devices that cannot provide a small amount of storage. In fact, this feature is used in high-end Home Gateway or Set-Top Box devices that have at least 128MB of storage. this topic serves as an extension to the MTD base devices.

One of the specific needs for this setup is to store statistical data gathered by the device persistently, so it remains available if the operator needs it. Additionally, other data such as the last used Wi-Fi SSID and some other information need to be retained even if the device's services cannot gather the information for any reason (e.g., data corruption). In such cases, the services must rely on default values from the squashfs /rom instead.

8

no there is a rollback config mechanism that prevent this from happening and it's already used in ubi base partitions, persistent parameters is a part of the easymesh specs

9

This confused me:

  • what you stated is already possible
  • if the storage is corrupt, I'm not sure how using the same storage solves that issue
10

sorry I misexplained here, after a successful factory reset network services through an API will if check if there is any persistent data in /cfg storage kept for them and apply it, if not will apply the defaults config that came with the Image.

11
  • You can change the image defaults
  • Also, how does that solve a corrupt storage?
  • What API

Maybe I'm just confused because I assume a Factory Reset will be designed to do just that. It seems you want exceptions to be made to the Factory Reset - so it doesnt set everything to the default(s)? Is that a fair analysis?

Also:

I'm not sure this was clarified - in the case some sells or otherwise transfers ownership.

If so, how do you erase in this case?

12

I need to put you in the context first :

Firstly, let's understand that the proposed "cfg" partition isn't a replacement or alternative to image defaults or to the handling of corrupt storage, but a complement to them. It's intended for specific scenarios that need persistence beyond regular factory resets. Yes, you could say it's about making "exceptions" to the factory reset behaviour, but these exceptions are not arbitrary and are, in fact, driven by specific requirements, especially in proprietary openwrt contexts.

To elaborate further, proprietary openwrt services, including network services, often need to comply standards like TR-181 TR157 and so one.. This standard allows operators to remotely manage equipment, irrespective of the device, as long as the device supports TR-181.

Such services come with default values and store any modifications separately, usually in the overlayfs (e.g., /etc/data/). Various services interact with each other via inter-process communication buses like ubus pcb ism amx etc..

One such service handles persistent data and needs a specific, non-erasable storage space for its operation. This service also allows network services to mark certain parameters as factory reset persistent. For example, the parameter Device.WiFi.SSID.{i}.SSID, which, as per the WiFi Alliance, must persist even after a factory reset.

about the concern of device ownership transfer, I need to mention that this mechanism doesn't inherently link a device to a specific user's account. Any link to user data would be dependent on the specific implementation of the services using this partition, not the existence of the partition itself.

If you're interested in diving deeper into the topic, you may want to explore this open-source project, which you might find insightful: https://gitlab.com/prpl-foundation/prplos/prplos.

However, please note that, as of now, support for a "cfg" partition in mtd-based devices like those using UBI doesn't exist, maybe because mtd based are generally speaking low in storage ?

13

The README says:

This is the buildsystem for the OpenWrt Linux distribution.

It also says:

Your OpenWrt Community
http://www.openwrt.org

Since that information is false (and incorrect BTW), I'm not sure what you wanted me to understand via the link.

What operator?

What service?

Since I'm not aware of anything that would be "proprietary OpenWrt" - so I'm more confused.

It actually seems you're attempting to get the community to program something for commercial purposes. Nonetheless, thank you for attempting to explain. I'm sure other will discuss as well.

I hope the best for your request.

14

I'm working on a project where I configure the routers, hand over it to another persons, and support remotely. I was looking for a way for unique configuration data provisioning (hostnames, root passwords, Wi-Fi network name and PSK, OpenVPN configuration, etc), while maintaining a single non-unique firmware package.

Ended up making my own uci-defaults add-on which source's the additional files from the provision data archive. The provision data is stored in a tar.gz archive inside the device disk (it's x86 system), right after the firmware image, so it is never rewritten.
The provisioning system is essentially executes additional scripts upon firstboot or firmware update (with the difference between these two modes).
The files from tar.gz are extracted to /tmp only, and then uci-defaults scripts are getting included.

The provisioning configuration is done with an uci configuration file (/etc/config/provision), which allows to configure script's toggables, and also store the provision revision in case the firmware brings the updates incompatible with the older provision data/scripts. Since it's the firmware which checks for provision data and executes it, the firmware could check whether the data is compatible with the current version of FW.

Advantages are as follows:

  • Apply unique per-device configuration stored inside the device itself
  • Maintain single non-unique firmware for all of the devices, which applies unique configuration even on "factory reset" (firstboot)
  • Update firmware remotely with sysupgrade -n without any maintenance burden
  • Provisioning configuration of any complexity (it's just a bunch of scripts)

@slh made a valid point of cruft. The provisioning scripts may become outdated, for example in case of some daemon configuration file layout update. As I'm both the maintainer of provisioning data and the firmware, this is fairly easy to do, given that the provision has a revision. The data could be updated to the firmware changes and re-provisioned on the device, using some kind of updating scripts.

I won't declare my system as a very thoughtful, this is what I ended up writing in 2 days, and the data is stored without any partition, and gets read using a hard-coded offset, but hey, it works for me pretty good so far.

1 Like
15

Hey @ValdikSS,

Thanks for sharing your solution, it really sounds like you've got a neat setup that fits your needs perfectly!

The approach I'm discussing also revolves around maintaining a unique per-device configuration, but is slightly different in that it uses a designated mtd partition for storing essential information, which we call 'cfg'. This partition is meant to survive factory resets and even upgrades, making it an ideal place for storing device-specific settings or, say, TR-181 parameters required for remote management.

One more interesting use case for this approach, beyond just settings and configuration, could be error logging or crash report collection. Imagine if we had a kernel crash, or some critical user space failure. In such an instance, we could save the core dump to the 'cfg' partition and trigger a factory reset. This way, we would have the device back to operational status promptly while preserving valuable debug information.

This is actually being utilized in devices with UBI filesystems. The core dump stored in the cfg partition can be retrieved anytime during the CI/CD process, thus ensuring we stay alerted about any device malfunctions and have the data necessary for root cause analysis

16

It also says:

Your OpenWrt Community
http://www.openwrt.org

No it's a fork project with the main branch as prplos and uses dedicated feeds that have nothing to do with openwrt,
I'm actually already have something to provide about the topic I'm addressing I'm just taking notes

1 Like