Vetting package updates

In trying to figure out a luci issue resulting from an upgrade, I ran across a forum thread advocating to only upgrading OpenWRT components that you absolutely need to upgrade, and to NOT install all available updates. What are your thoughts on this advice?

I'm not personally reviewing source code before making updates. But I trust an open source community more than other options. Is there a better vetting process I should be following than to just opkg upgrade {all}?

Well first of all, you should upgrade packages/software because they fix issues mostly, and also add new features (you can always see if their is a changelog available to ascertain what is new and what is fixed), but you should NOT upgrade system packages that get installed with firmware (on an embedded device with limited storage such as a router). Those packages can not be upgraded because they are in ROM (Read-Only Memory) area. The only way to upgrade those packages is to flash a new firmware with the upgraded packages. The system would say that those packages are upgraded but in fact they only get installed in overlay space, so it means they will be installed in two different places using more storage than necessary.

Moving on to user-installed packages, you should upgrade packages, as listed above, if you installed them after the flashing the router.

You dont really need to review any source code but you can just see the changelog if available.

For virtually all users, never run opkg upgrade of any ROM-installed package (unless clearly instructed to do so by a well-recognized, primary developer in a one-off, critical situation).

Periodic flashes of the maintenance upgrades or new major versions are the recommended approach.

4 Likes
1 Like

This is an excellent thread. Thank you.

Thank you for your response. Is there an easy way to determine which is a ROM installed package vs user installed? For instance when you see this, where to go to figure which to upgrade?

opkg list-upgradable
luci-app-adblock - git-19.034.35162-a0ae6c9-1 - git-19.046.40869-30d9bc0-1
luci-lib-ip - git-19.020.41695-6f6641d-1 - git-19.046.40869-30d9bc0-1
luci-theme-bootstrap - git-19.020.41695-6f6641d-1 - git-19.046.40869-30d9bc0-1
netifd - 2018-11-19-4b83102d-2 - 2019-01-31-a2aba5c7-2.1
luci-app-uhttpd - git-19.034.35162-a0ae6c9-1 - git-19.046.40869-30d9bc0-1
luci-ssl-openssl - git-19.034.35162-a0ae6c9-1 - git-19.046.40869-30d9bc0-1
luci-app-firewall - git-19.034.35162-a0ae6c9-1 - git-19.046.40869-30d9bc0-1
luci-proto-ppp - git-19.034.35162-a0ae6c9-1 - git-19.046.40869-30d9bc0-1
luci-mod-admin-full - git-19.034.35162-a0ae6c9-1 - git-19.046.40869-30d9bc0-1
luci-base - git-19.034.35162-a0ae6c9-1 - git-19.046.40869-30d9bc0-1
luci-proto-ipv6 - git-19.034.35162-a0ae6c9-1 - git-19.046.40869-30d9bc0-1
luci-lib-nixio - git-19.034.35162-a0ae6c9-1 - git-19.046.40869-30d9bc0-1
luci-lib-jsonc - git-19.034.35162-a0ae6c9-1 - git-19.046.40869-30d9bc0-1
luci - git-19.034.35162-a0ae6c9-1 - git-19.046.40869-30d9bc0-1

No one.
Because asking this question means you still do not understand the consequences.
And that means you shouldn't upgrade any packages.

2 Likes

You probably remember the few packages that you have manually installed by yourself. Those are the only ones that you should/could opkg upgrade blindly.

No. At least for self-built firmware images, also the packages installed at the image compilation stage are listed as "user installed" by "opkg status". (the same likely hold true for release builds, but I haven't used those for many years.)

But you can use the install time as a trick to identify the packages. All packages installed at the firmware creation time have the same installation time stamp. All packages installed by you manually (after flashing, in a live router) will have a later time stamp.

You can use "opkg status" and grep to get the relevant info.

Example: I have only installed "joe" later, and all other packages are in the image.

Using just "opkg status" would give a long list like the example below. It is hard to pick any differencies in the install time:

Package: wireless-regdb
Version: 2017-10-20-4343d359
Depends: libc
Status: install user installed
Architecture: arm_cortex-a15_neon-vfpv4
Installed-Time: 1550170221

Package: kmod-scsi-core
Version: 4.14.99-1
Depends: kernel (= 4.14.99-1-ab5b14eb9dbaf3e96fc13c6b47294149)
Status: install user installed
Architecture: arm_cortex-a15_neon-vfpv4
Installed-Time: 1550170221

Package: kmod-slhc
Version: 4.14.99-1
Depends: kernel (= 4.14.99-1-ab5b14eb9dbaf3e96fc13c6b47294149), kmod-lib-crc-ccitt
Status: install user installed
Architecture: arm_cortex-a15_neon-vfpv4
Installed-Time: 1550170221

But let's narrow the output. First do
opkg status | grep -E "Packa|Insta" | head

You will get output like:

Package: kmod-usb-storage
Installed-Time: 1550170221
Package: terminfo
Installed-Time: 1550170221
Package: luci-theme-material
Installed-Time: 1550170221
Package: iwinfo
Installed-Time: 1550170221
Package: luci-app-statistics
Installed-Time: 1550170221

So, 1550170221 is the common installation time, the firmware creation time. All packages installed at that time are in ROM image.

Let's utilise that to narrow the output further:

opkg status | grep -E "Packa|Insta" | grep -v "1550170221" | less

The only lines with "Installed-Time" left are those that you have installed, either directly or automatically as dependency. You can much easier find out the few installed packages (like "joe" for me).

Package: kmod-crypto-aead
Package: libiwinfo-lua
Package: joe
Installed-Time: 1550246712
Package: kmod-usb-dwc3
Package: swconfig
Package: kmod-crypto-md4
Package: kmod-crypto-md5

But in general, only use "opkg upgrade" to upgrade packages that you know that you have directly installed by yourself.

EDIT:

Still further narrowing the output by using grep with context:

opkg status | grep -E "Packa|Insta" | grep -E -v "Packa|1550170221" -C 1

This lists the packages installed by you and their installed time, plus one extra line after the Installed-Time line for each installed package:

Package: joe
Installed-Time: 1550246712
Package: kmod-usb-dwc3

Imaginative use of shell commands can do wonders :wink:

5 Likes

This is great! thank you !

First, the obvious, if you didn't install it, it's not "user installed".

With the advice of @vgaetera sage and to be followed, one answer to the specific question is from master and ./package/base-files/files/sbin/sysupgrade

                # Format: pkg-name<TAB>{rom,overlay,unkown}
                # rom is used for pkgs in /rom, even if updated later
                find /usr/lib/opkg/info -name "*.control" \( \
                        \( -exec test -f /rom/{} \; -exec echo {} rom \; \) -o \
                        \( -exec test -f /overlay/upper/{} \; -exec echo {} overlay \; \) -o \
                        \( -exec echo {} unknown \; \) \
                        \) | sed -e 's,.*/,,;s/\.control /\t/' > ${INSTALLED_PACKAGES}

Again, you shouldn't be upgrading packages in bulk, ever.

2 Likes

Thanks Jeff. I will definitely cease that practice.

Even that is not safe...for example, libmbedtls is not installed in the ROM on my R7800. So packages that depend upon it will install it for me.
BUT, this package has in the past been updated within the public repositories, with an ABI incompatibility. Because of incomplete dependency declarations, this has broken other packages that consume it.

So is it really only safe to install new packages and test them, then never update until the next new ROM image?

That is a reasonable approach.

Yes, I'll occasionally flash some "innocuous" utility, but almost never anything with more than a couple "simple" dependencies (TLS libraries aren't "simple", as I define them here).

Being able to generate a complete ROM on demand to add/remove packages, especially with only 16 MB of flash, is one of the reasons I first started to use the build system.

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