Upgrading firmware using opkg?

mount -o bind xyz /etc/config && at ... reboot

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.

can we make router itself use imagebuilder to make it's own sysupgrade image?
it should have config file/ opkg updated package list ect...

No, the imagebuilder is only built for x86_64 and expects a rather complete host OS.

1 Like

UCI customization with CLI is runtime until you invoke the commit command:

1 Like

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
/etc/init.d/uhttpd restart
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.

Init script converts runtime UCI to runtime service config.

No, it's typically stored in /tmp.

It's a bad idea to store comments in UCI configs.
You should use named sections, or custom options for descriptions.

Can you please share an example.

uci rename dhcp.@dnsmasq[0]="lan_dns"
uci set dhcp.lan_dns.comment="Main dnsmasq DNS instance serving the LAN"
uci commit dhcp
uci diff dhcp

Looks like you must have a newer version of uci that includes a diff command - I assume diff would show the changes made, but I am surprised it would be run after the commit.

You can see the pending changes before committing:

uci changes dhcp

And diff after, assuming you have preserved the default config nearby.

Thanks - looks like I need to read up on ash.

On a related one, I see the ash history command works but I can't do !5 or !uc to run a command from the history.


folks probably will hate me by remembering that, but I did a rather smooth update some time ago in a Raspberry Pi (1) with ext2/3/4 filesystem.

By upgrade understand going from 19.0.x to 19.0.x+1 and not from 19 to 21 or similar.

Here you may find a draft recipe: Upgrade from 19.07.0 to 19.07.1: does it require sysupgrade? - #4 by lramos.

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.

Luiz Ramos
Sao Paulo - Brazil

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 )

1 Like


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?

1 Like

replied via PM as possibly getting OT... but happy to assist anyone interested...

Was asked to merge the detailed wiki article on the rpi4 I was making/made into that shared page with all the other rpi models... which didn't seem clean or appropriate so just deleted it...

I also want to know how to have root and data partition for Virtual X86 setups.

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...


Just attach another block device storage to the VM and use it as extroot.