Is it possible to "save" the "last known good" configuration?

There's probably no single answer to this question that fits all targets, so let me outline a device-specific situation and explain further what I mean by "configuration"...

Let's say we have a Linksys EA3500, which is a kirkwood device with dual firmware layout. The device is running very well with the following changes from the "factory" configuration:

  • Set root password
  • Added packages (in case it's important which packages those are, let's say they are luci-theme-openwrt-2020 and luci-app-advanced-reboot)
  • Changed system settings (hostname, time zone, NTP servers)
  • Changed network settings (IP address, DNS servers)
  • Changed wireless settings (basically, the entire wireless configuration defined from scratch)
  • Changed DHCP settings (set new values for dhcp.lan.start and dhcp.lan.limit)

Now, is it possible to somehow change the backup partition so that in the event of a reset, the device would restore to this "last known good" configuration rather than to the "factory" configuration?

Right now, I'm thinking that I could:

  1. Write a shell script that makes all the changes mentioned above (actually, I already wrote it; it includes password piped to passwd, a couple of opkg commands, a ton of uci set commands, and a nice fat uci commit at the end).
  2. Boot into the alternative partition using luci-app-advanced-reboot.
  3. Once the device is up, log in over SSH on a wired connection, upload the script mentioned in point 1, run it, and reboot.
  4. Once I verify that the changes have taken place, boot back to the original working partition using luci-app-advanced-reboot if necessary. Or perhaps just stay on his "new" partition as working, keeping the other partition as a backup...

Is there any reason I shouldn't try this? Are there any obvious pitfalls I am overlooking? Is there a better way of achieving the desired outcome? (Say, is there a way to write a copy of the entire working partition over the backup partition?) All ideas are welcome, tales of experience, doubly so... :smile:

You could build an image with said configs included. Not sure if you're concerned about the default config; or particularly seeking some way for the Openwrt to determine it was "last good".

Check sysupgrade -h for the details of backing up/ restoring your configuration, be aware that this only covers configuration, not runtime-installed packages (that is not possible to back up in a meaningful way, but e.g. imagebuilder exists).

Thank you for the suggestion! Building an image will definitely solve the problem, but it seems a bit too labor-intensive for what I have in mind. Let me explain why I am asking and what I am trying to achieve.

I am trying to come up with an implementation of OpenWrt that is (a) low-cost, (b) beginner-friendly, yet fully functional, and (c) easily replicable. Here's the use case. Someone says to me, "I want to try OpenWrt, but I am deathly afraid of bricking my router" (or some other excuse). In response, I hand them a serviceable router I got off eBay for $20 and say, "Try this; it has sensible defaults out of the box, and if you break something, you can always reset it to those defaults". And once they walk off, I want to be able to get another router off eBay and configure it to the same defaults without spending a lot of time.

Said another way, I want my imaginary beginner friend to spend no more time and effort on initial setup than they would on setting up a router with stock firmware. This, in my opinion, is a critical hurdle. Supplying a router that has beginner-friendly defaults and can be reset to those defaults provides a good starting point for independent incremental learning.

In the DD-WRT community, addresses the same hurdle. but in a completely different user segment: they offer high-end devices with pre-flashed open-source firmware. In business terms, they are targeting enthusiasts with disposable income. I, on the other hand, want to target would-be enthusiasts without disposable income, offering "OpenWrt -on-cheap-hardware" as an inexpensive learning platform.

Custom image would be one way to achieve this, but it requires skills and hardware that I currently don't have. Also, I am thinking about having a "library" or several "approved" router models (meaning, inexpensive and known to work well with OpenWrt) and bringing in newer models as they become less expensive in the secondary market. Maintaining a library of configuration scripts in this situation is a bit easier than maintaining a library of images, right? Also, a configuration script would in most cases survive a new OpenWrt release unchanged, while a custom image would have to be updated.

Am I making any sense at all? :smile:

Thank you, I am aware of that; this is why I took the time to spell out explicitly that I am trying to retain those packages. This is also why I began thinking about configuration scripts in the first place.

Like I said in my response to @lleachii above, this is a bit outside my skillset. Also, I want to be able to do this with several models and expand the "menu" as "known-good" hardware becomes progressively less expensive in the secondary market. Also also, I want to be able to survive new releases without extensive redos.

Anyway, I've got a couple of EA3500s (average cost: $17, including AC adapters) coming in this week. Will try my idea out and report back.