will do the majority of this functionality... the sticking point is service state... IOS has dynamic service handlers... linux/openwrt does not operate in the same way... so custom management of keeping the service state metadata before and then knowing when-to, then restoring from that metadata is the challenge...
there are at least two good scripts on the forum that do this task in addition to @stangri s useful commit that can also assist in doing the majority of this task...
( and for minor stuff there is also 'uci set' + 'uci revert' for quasi running-config-only operation )
Thanks - for the info. I realize that in most cases short of running sysupgrade most commands will not brick the device - the worst that happens one looses either wifi and/or ssh connection, so frequent saves combined with hard reset should work in most cases, but having built in functionality of being able to have an equivalent of 'running' and 'startup' config could save people time, especially when starting new config.
I suspect most people here don't have to deal with devices located in remote locations, but I am sure there are some, and the tips like the one shown by wulfy23 are nice to know.
I have been thinking of setting up a software watchdog timer ( as opposed to the build in hardware WDT which looks for a hard lockup ) that monitors outside connections and does a reboot as required. I suspect/hope there is a package for that so I don't have to roll something of my own.
I have been playing with Linux since 0.9 before a full Linux distribution even existed and I still get amazed how far it has come. We used to use the Linux kernel compilation as a system benchmark - make -j xx and then make -j xx+y allowed to test parallel compile and speedup factor. Gcc does a lot of disk I/O and needs CPU/Ram - fun time.
Thanks - I did a quick test and it does work as described in that link, so when doing something that may lock one out it is possible to make a change and schedule a timer to reboot if something goes bad.
Based on my reading of the UCI pages the data path is:
/etc/config/abc -> init script for abc converts to uci -> final config placed in /tmp or /var/run -> abc started
In order to recreate /etc/config/abc after making uci changes one needs to run uci commit abc
Also, it is clear that making changes using LuCI will remove any comments in /etc/config files, as uci commit command will be run.
I tried the following test:
uci set uhttpd.main.comment='# test comment'
uci commit uhttpd
Looked for errors with logread - not sure if all packages would accept a comment option or any other option they don't understand, but uhttpd started fine. Even on my home equipment I like to comment all changes with dates and description.
Problem is that OpenWrt is designed having commercial routers in mind (a system with R/O firmware+RAM), and not for Linux PCs plenty of rewritable, nonvolatile space. So it's more natural to make sysupgrades from time to time rather than doing apt-something or like daily.
Then I wonder about the existence of opkg upgrade. It's a marvelous tool, but it doesn't fit very well in this world.
I suppose your case is about routers (that is, you're trying to do incremental firmware updates). If so, please do not try my recipe; it much likely won't work. However if you have a system with R/W nonvolatile memory and use ext2/3/4 it may work.
Anyway, like before, I would welcome a good solution for a way to do incremental updates. Mainly because for the security point of view, responses to threats should ideally be deployed as sooner as possible.
not sure about a pi1 but on the pi4 (and technically x64 etc.) if your going through the trouble of mounting rom's to get kernels... it's not to much of a stretch to implement 'multiboot' ( dualOS on one disk )...
the most difficult part is the prep... ( extra rootfs partition and boot entry )... once that is done... 'upgrading' ( writing and toggling to the other install ) is fairly simplistic... ( and can be done 'live' from the full current install )
I've definitely thought that for something like the RPi4 which is hugely popular, a two-partition system similar to what you have on the WRT3200 and such would be a great idea. How do you do the setup? Is there a wiki article?
on ext4 root=data x 2 then "boot"/grub partition can contain alternate kernels and boot entries which you can sed the 'default' on to automate... ( x64 is much easier as the required components can be directly downloaded from the download servers... and extraction from an existing image is not necessary )
you may also wish to check the current 'dual' PR for this target on github... it is much more extensive... and there are at least 3 threads here on the forum describing how different people have approached and solved similar requirements...
alot comes down to how automated you wish it to be and whether or not you wish to also support flashing the 'current' OS...