Upgrading firmware using opkg?

Installing and Using OpenWrt
1

I recall while back reading a post with a name of a package(s) that can be installed with opkg that can be used to track all changes and makes future firmware upgrades more compatible compared to using the standard save and restore procedure. I tried to search for the name but I am not finding it - the main page on upgrades ( link ), has a number of scripts and other things like extensions to opkg, but not a package by itself.

I am setting up a new access point with 19.07.x and want to make future upgrades as simple as possible. I think some work has gone into this area in 21.02, and will be easier to upgrade in the future. In case my memory is playing a trick on me and the above link is the best way to get ready for future firmware upgrade please let me know - thanks.

2

opkg cannot upgrade firmware. That is where the sysupgrade command comes into play. There are some scripts that can help determine the user-installed packages to simplify the reinstallation process since the firmware upgrade wipes out those packages. Is that what you are referring to?

Just in case, I'll also say the following:
Upgrading packages (via the CLI opkg upgrade command or the LuCI Upgrade... button) can result in major problems. It is generally highly discouraged, unless you know what you are doing or if there is specific instruction to do so.

2 Likes
3

Thanks - as I recall the idea of the package was to record all the changes one makes from a clean install, after that one would upgrade the firmware using sysupgrade and then run some other command to restore all changes - I don't recall if using the standard save and restore of settings from /etc/... was part of that procedure.

On the other had I am a bit surprised that opkg upgrade is not recommended way of upgrading packages in between minor firmware releases - from what I have seen opkg deals properly with config files and will rename new one and allow the user to do a diff to see if it needs to be updated by hand.

4

There are a few things to unpack... hopefully I'll be able to explain things well.

Relative to a fresh install with the default config files, the vast majority of the user configuration lives in /etc/config (with exceptions here and there). Those files are easily backed up and restored with the standard tools, and the actual configuration of the backup process accounts for basically all the typical config files. With a backup in hand, you can restore to to the same or newer minor revision of OpenWrt, or simply use the "keep files" option when you run the upgrade.

When upgrading between adjacent major versions (say 19 > 21), that is not guaranteed to work, but often does unless there are structural changes to the underlying configuration files and/or the platform itself (for example, ar71xx > ath79). Some files will still migrate without an issue, others may not, so the general recommendation is to not keep files across major versions (and certainly not across many versions like 15 > 19 where things may have changed significantly). Keeping files or restoring the backup after a flash may work, but should be done with caution. Often it is easier to recreate any config files that may have relevant architectural changes than to troubleshoot issues. Depends on your situation, skills, and patience, of course.

User installed packages are wiped out anytime you upgrade the firmware, unless you build your own firmware with baked-in packages (using the image builder). As I mentioned before, there are some scripts (maybe even a package or two) to compile a list of user installed packages and make it easy to reinstall. The config files for the packages, generally speaking, also are included with the backups described above (some packages may add the config file locations to the backup script paths, or this can be done by the user).

Finally, regarding opkg upgrade... the thing to remember is that just because a newer version of a package is available doesn't mean you should upgrade. In some cases it can break compatibility and a package can fail to work. Other times people end up soft-bricking their router because of deeper dependencies failing. the package manager doesn't have strict compatibility and dependency checks -- just the basic stuff required to get things installed. Often upgrading one or two packages isn't likely to be an issue (such as if there is a new feature or security patch), but blindly upgrading all packages can lead to issues. This is why we do not recommend ever using opkg upgrade unless there is a specific reason to do so. FWIW, even the regular contributors on this forum are a bit split about this topic -- some have never had issues, others have had issues or helped troubleshoot problems related to the process. Do whatever makes sense for you, but be aware of the potential risks and make sure you always have backups.

3 Likes
5

Thanks for taking time to provide the details. I do see your point on using the upgrade option. At work we run a large number of Linux servers both CentOS and Ubuntu and use containers just for this reason - a snapshot is taken before any updates are done, in addition to having full and inc. backups in case somethings goes bad.

One feature that I wish did exist ( maybe it does, and I just don't know about it ), is being able to apply a setting without making it permanent - having worked with Cisco Enterprise routers and switches I really like the idea of two config files - by default the changes are done to the running config but if something goes bad a reboot will revert. In the case of Cisco a single config file is parsed and contains all the non-default settings.

I guess it would be equivalent to dumping uci, but it looks to me since the default save just dumps the /etc/config/... files into a tar file, uci is not used for that purpose. Since I don't know the full history of OpenWrt I am not sure when things moved away from uci or maybe they have not and it was always just a database for the web interface stored in a different part of the flash, with the other part being accessed by the overlay fs.

For the longest time I have been using dd-wrt but found that I just could not tell when to apply updates and which version to use - OpenWrt is head and shoulder above that, so I went ahead and replace my home network equipment with devices well supported by OpenWrt !!! dd-wrt is a great project, but the area of updates is one of my major beefs with it.

1 Like
6

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 )

2 Likes
7

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.

8

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

9

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

1 Like
10

UCI customization with CLI is runtime until you invoke the commit command:
https://openwrt.org/docs/guide-user/base-system/uci#command-line_utility

1 Like
11

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.

12

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.

13

Can you please share an example.

14 
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
15

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.

16

You can see the pending changes before committing:

uci changes dhcp

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

17

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.

18
19

Hello,

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.

Regards,
Luiz Ramos
Sao Paulo - Brazil

20

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