18.06.2 - Upgrading packages

Until detection of ABI changes is automated (first steps of capturing ABI information underway on master), knowing just what dependencies need to be updated would be a purely manual task. There's the possibility of ripple-through more than just one package deep, as well. The "sledgehammer" approach of "everything that could possibly depend on this, and everything that depends on those, and ..." works with an unconstrained file system, but between capacity and flash wear, isn't really appropriate for all-in-one routers.

  • libmbedtls -- 143 kB right there
  • 21 packages -- 2,102 kB (by hand, without enough coffee)

With users still clinging to 4 MB flash devices, and even 8 MB ones, another 2 MB for someone impacted by all of them can easily put them over the top. Of those, the apparently popular transmission packages are around 1 MB right there.

2 Likes

Even with those new ABI checks in place, you need to be aware that this won't ever become as thorough as for the large desktop distributions, which spend a lot of time and effort on doing this properly (including symbol versioning). That is a limitation of the available system ressources, opkg's abilities in general and most of all developer ressources - yes, these new changes will help, but they won't make it 'perfect' either.

2 Likes

So the conclusion is...

  • Do not upgrade packages, use supported releases and snapshots, or compile from the source and be happy.
  • Otherwise don't complain on the forum and be ready to deal with consequences yourself, such as manual dependency resolution and additional free space consumption, potentially leading to ABI-conflicts and soft-bricking.
5 Likes

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?

2 Likes

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

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:
https://downloads.openwrt.org/releases/18.06.2/targets/ramips/mt7621/openwrt-18.06.2-ramips-mt7621-dir-860l-b1-squashfs-sysupgrade.bin
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.

2 Likes

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
dropbear
openvpn          
firewall 
wireless
ddns
dhcp             
network          
system

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.

2 Likes

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.