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.

Here's what I ended up doing.

0. Set up the reference device

I installed and configured everything I thought should be on the device to be replicated.

1. Generate a complete list of installed packages

There's more than one way to do it. Here's what I did:

opkg list-installed | awk '{ printf "%s ",$1 }' && echo

This outputs a list of all packages installed on the device. I copied the list off the terminal screen and saved it into a text file,

2. Build firmware for replicant devices

If the replicant device already has OpenWrt on it, you can simply feed the list of packages to opkg. If not, there's an unbelievably easy way to customize firmware. It's called OpenWrt Firmware Selector:

Find your target system in the list (for example, if you need firmware for an x86 system, start typing x86 into the selection line and see what falls out). When you found your system, click on its name. In the window that opens, click on Customize installed packages. This will open a textbox with a list of packages in it. Replace that list with the one you generated in step 1, click on Request Build, wait for the firmware to be compiled, and when it’s ready, download it and install it on your target system.

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.