18.06.2 - Upgrading packages

The problem appears to be that updates to packages are put in a repository which is used by the released software which includes the tools for updating packages just like on almost every similar platform, creating a POLA violation.

This is made worse by the fact that most packages can be safely updated. I've been updating packages for years and only recently found one to be problematic (netifd).

Even worserer is that the idea of not updating packages only occurred to me when I came here and -after jumping all the hoops to find the forums, sign up, navigate to the right place, browse, find the relevant thread, find the relevant posts, try to check the authority of the poster, etc. - read a thread or two on the subject.

The best solution is not obvious, but as currently released and documented, it should be expected that all good admins will find out how to update and do so (and probably fix any problems they encounter while doing so). Some relevant discussion in Okpg upgrade safeguards?


This note is a little late in the game if you've already upgraded, but...

OpenWrtScripts github repo has an opkgscript.sh script that will:

  • write out your current set of installed packages before flashing (making a list of packages that aren't part of the original firmware image), then
  • (after flashing the new image) read that package list, and reinstall them.

I'm trying (really hard) to make sense of what is written in this thread and might need some help from those of you more knowledgeable.
I have a D-Link DIR-860L-B1 that is currently running 18.06.1 and was about to upgrade it to 18.06.2, but I do have a few extra packages installed:
(during the initial installation I added)

opkg install kmod-usb-serial
opkg install kmod-usb-serial-option
opkg install usb-modeswitch
opkg install comgt
opkg install luci-proto-3g
opkg install usbutils
opkg install kmod-usb-storage
opkg install kmod-usb-storage-extras
opkg install kmod-fs-vfat
opkg install kmod-nls-utf8
opkg install kmod-nls-cp437
opkg install kmod-nls-iso8859-1
opkg install kmod-fs-ext4
opkg install kmod-fs-msdos
opkg install kmod-fs-ntfs
opkg install luci-lib-px5g
opkg install px5g-standalone
opkg install libustream-openssl
opkg install kmod-ledtrig-netdev

By looking at the short release note:
I learned that the kernel was upgraded:

both 4.9.x and 4.14.x being LTS branches I do not understand the discussions about API/ABI breakage.

Then, about the installed packages upgrades, process that I might need to run myself, by reading the official OpenWRT docs:

I learned that opkg is able to automatically resolve dependencies, thus, I'm not able to follow some of the posts here in this thread.

Bottom line - how should I proceed now?
Upgrade the flash by using LuCI and flash:
The configuration will be preserved but I'm not sure about the extra packages I installed.
If those extra packages will remain (will they still run?) and opkg will inform me that some are upgrade-able, how should I proceed? Upgrade them with opkg?

Or, should I backup my actual config, flash the new 18.06.2 by removing everything, then install all the packages again, as new, and put the configuration back? I hope this won't be the case, it'll be overkill and I'll need to bring down the network, get the router, prepare it and install it back (it's not in my possession ATM)

Any clarifications/hints appreciated! Thanks!

Assuming that the packages are "well behaved" (and your list appears to be), the configuration (if any) will be preserved by sysupgrade. You can check what is preserved with sysupgrade -l and add to it, if needed, by editing /etc/sysupgrade.conf

During a ROM upgrade, any packages you previously installed after flashing are wiped out when the overlay is reset. While the saved config is restored, the "binary" packages are not.

After you upgrade, you can install new versions of the packages you added using okpg, if they are not already present in the ROM you flashed. If there's already a version in the ROM, it is not recommended to upgrade it.

As with any upgrade, preserving your config in a safe place (off the router) is highly recommended.


Wow! That was fast! Thanks for the clarifications!

Which means, I'll have to go for the last option, bring the network down ,get the router, reinstall packages and ... smile... :slight_smile:

Or custom assemble or build your own ROM with the packages you need. (I'm guessing you have only have 3G connectivity to the router, so without those packages, no Internet access to the device.)

I'll get the the router and prepare it, I just need to understand first (need to go through the detailed changelog) what are the exact vulnerabilities (if any) I'll close with 18.06.2 and if it's worth/urgent enough.
No, the 3G is just configured for failover, no modem inserted in the USB socket for now. Accessing it it's actually worse, I only can get to it through openvpn, which obviously runs on it :smile:

I am guilty of upgrading packages. I now want clean 18.06.2 install.

I checked my config files for 18.06.1. I need following files. My plan is do sysupgrade with clean config then copy over my old pertinent files that I need manually (not to restore entire backup config) OR hand edit the files to incorporate previous changes. What will happen to my opkg upgraded packages? Will this work or do I need factory install?

/etc/config files

Files for openvpn
	option ca '/etc/easy-rsa/keys/ca.crt'
	option cert '/etc/easy-rsa/keys/myrouter.crt'
	option key '/etc/easy-rsa/keys/myrouter.key'
	option dh '/etc/easy-rsa/keys/dh2048.pem'

Your backup files look fine. Most of them will be backed up by default (no need to specify files in /etc/config).

You don’t need to re-flash the router if you’re already on 18.06.2. You can simply run firstboot on the command line. This will erase all files and restore the configuration to that of the original image in ROM. Then restore your backup and you should be good to go. You’ll need to use opkg install to add any packages that are not part of your original image (such as OpenVPN, unless you have a custom image that includes that and other packages of interest). Just don’t use the opkg upgrade for anything and you’ll be golden.


So when installing packages, how is one supposed to ensure that one gets a compatible version, rather than the latest package in the repo?

  • Installing is OK
  • Upgrading is where the issues arise

Let me point out the opkgscript.sh at OpenWrtScripts (github)

This script writes out the set of installed packages (to /etc/config/opkg.installed), then a different option can read that list back in after upgrading your firmware to restore your previous packages.

Not necessarily.

Assume that I install 18.06.2 and run it for a while. A couple of months later I decide that I really do need to be using TLS encryption with luci, so I install the luci-ssl package, but that package almost certainly won't match the version of the other luci packages that were included in the original installation. As pointed out upthread, it's a crapshoot whether such a version mismatch will cause problems or not.

I was stating a matter of fact.

In this case:

  • Reset to defaults
  • Restore config
  • Re-install all additional packages

Works for me on versions 17 and 18.

Consider a brand new install of 18.06.2 (openwrt-18.06.2-x86-64-combined-ext4.img running in a VM).

root@OpenWrt:~# opkg list-installed | grep luci
liblucihttp - 2018-05-18-cb119ded-1
liblucihttp-lua - 2018-05-18-cb119ded-1
luci - git-19.020.41695-6f6641d-1
luci-app-firewall - git-19.020.41695-6f6641d-1
luci-base - git-19.020.41695-6f6641d-1
luci-lib-ip - git-19.020.41695-6f6641d-1
luci-lib-jsonc - git-19.020.41695-6f6641d-1
luci-lib-nixio - git-19.020.41695-6f6641d-1
luci-mod-admin-full - git-19.020.41695-6f6641d-1
luci-proto-ipv6 - git-19.020.41695-6f6641d-1
luci-proto-ppp - git-19.020.41695-6f6641d-1
luci-theme-bootstrap - git-19.020.41695-6f6641d-1

You can see that the installed luci packages are version 19.020.41695.

What version of luci-ssl is available in the repo?

root@OpenWrt:~# opkg update

root@OpenWrt:~# opkg list luci-ssl
luci-ssl - git-19.046.40869-30d9bc0-1 - LuCI with HTTPS support (mbedTLS as SSL backend)

If I install luci-ssl, I will get version 19.046.40869, which is a later version than the rest of the luci packages.

Generally, this will not be a problem within the same release.

Your concerns are being addressed in master with ABI revisioning.

1 Like

Indeed. I just wanted to point out that simply telling people not to update packages doesn't completely eliminate the issue.

I've updated the packages many timeswithout issues. Maybe I'm lucky and don't have any problematic package?
Is there a list of packages known to break stuff if they get updated?

EDIT: I'm running 18.06.2 right now but I've updated stuff on older releases too (always on releases, not on snapshot builds)

@fgimenezm - it seems that you have been lucky to date.

I cannot stress enough that opkg upgrade is a bad idea for all the reasons that have been discussed in this and other threads.

To my knowledge, there is no known list of 'safe' packages. There are no automatic compatibility checks, it would be purely manual. And there is nobody (to my knowledge) who is attempting to create a list like this (automated or manual). If one were to manually review the code changes for each package that might be upgraded, it may be possible to figure out if there are changes in the dependencies (and if so, those must also be reviewed) and/or kernel version to then guess at the compatibility. But that would be a lot of work and is incumbent on the person doing the upgrade to do themselves.

By now, you should know from reading these threads that there is a risk of seriously messing up your OpenWrt setup in unpredictable ways, some subtle, some major.

Although this cannot be guaranteed, the good news is that presumably failsafe should still work most of the time -- from there you can always 'firstboot' which will restore your router back to the ROM contents (i.e. the image most recently flashed onto the router).

Unless there is a very specific reason that you want/need to upgrade a given package, it would just seem like a lot of work to audit the code and/or unwise to blindly try the upgrade given the warnings here, unless you don't mind the risk (at which point, it is really a gamble). To each their own, of course. Good luck!


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