Updater control over (forced) system packages

Went through the updater man/faq and read some of the related forum posts but did not find a coherent conclusion of how to deal with packages forced by the system.

In order to prevent any mishaps the updater been set to approval and now showing to want to force these packages

• Install knot-resolver 1.5.1-3
• Install mjpg-streamer r182-9
• Install luci-app-mjpg-streamer git-17.212.243...
• Install transmission-daemon-openssl 2.92-3
• Install luci-app-transmission git-17.212.2432...
• Install luci-i18n-transmission-en git-17.212....

Anything transmission can hardly be system relevant and neither is the mjpg-streamer. Which begs the question why being forced by the sytem!? :confused:

For knot I got the understanding that a resolver is essential to connect to the i-net but same can be achieved entirely by beither dnsmasq-full or unbound. Latter happens to be the case on this user’s system.
Particulalry with unbound installed and running I would not want knot start messing with the
setup.

I will also want to remove the tiny-proxy installation and fear that it will be re-forced by the updater.

The updater man/faq is stating

In some cases an absence of a package can be enforced via the following command in updater’s configuration (i.e. file in /etc/updater/conf.d)

There is no elaboration of what ‘some cases’ are actually pertain :confused:
And which is the file in question in the /etc/updater/conf.directory that should doctered with

Uninstall(“Unwanted_package”, { priority = 60 })

base.lua / localrepo.lua / opkg.lua 
This file is part of updater-ng. Don't edit it.

opkg-auto.lua
This is automatically generated file managed by opkg wrapper script. Please don’t edit!

That leaves example.lua which promotes itself

This is example configuration file. You can use it as quick reference for your own
configurations.

Am I supposed to edit the file and save it back as example.lua? :exploding_head:
Or does it have to be another specific name in order to be processed by the updater?

And would say

Uninstall("knot-resolver", {priority = 60})

actually satisfy the cited ‘some cases’ scenario?

It should be in /etc/updated/user.lua. This is what mine looks like:

Uninstall "knot-resolver" {priority = 60}
Uninstall "unbound" {priority = 60}
Uninstall "unbound-anchor" {priority = 60}
Uninstall "tinyproxy" {priority = 60}
Uninstall "luci-app-ddns" {priority = 60}

Install "dnsmasq-full"
Install "ntpd" {priority = 60}

Some of these might not be necessary anymore.
Also, if you’re seeing a bunch of packages getting pulled in that shouldn’t be (like mjpg-streamer) check in the “package lists” in Foris - it’s possible you have one of the collections selected.

2 Likes

@mattventura much obliged for the respose :+1:

Just few notes.

This is old and now invalid path. This file is automatically migrated to /etc/updater/conf.d/user.lua on updater-ng update and overrides any existing file. It can give you some nasty surprise if you try to use both paths.

In Unix it’s common convention that directories int /etc named as *.d are loaded as configuration. That means that all files in such directory are loaded. In reality root configuration is and always was /etc/updater/entry.lua. That configuration then includes all files from /etc/updater/conf.d in alphabetical order.

This is obsoleted syntax. It was removed from documentation and works for just backward compatibility at the moment. But there is plan to drop it in future as it’s flawed. Correct syntax is:

Uninstall("knot-resolver", {priority = 60})

Also since Turris OS 3.9 there should be no need for {priority = 60} as all packages pulled in by system list (base and all user lists) have priority set to 40 (for example see: https://repo.turris.cz/omnia/lists/nas.lua). And default priority for all commands is 50. So just writing Uninstall("knot-resolver") should be enough. But there is no harm in setting higher priority.

1 Like

@cynerd appreciate the feedback. perhaps worth to update the man/faq of updater, would make it easier for users to find their way around

Seems that is not true for all packages.

Uninstall("knot-resolver", "mjpg-streamer", "transmission-daemon-openssl", "tinyproxy", "collectd-mod-vmem", "luci-app-statistics")

And the output from updater.sh

invalid-request: Requested both Install and Uninstall with same priority for package collectd-mod-vem

That happens with any/all of the collectd-mod-* packages

Also the collectd package wants to be reinstalled without {priority = 60}

Check your updater’s configuration. Most probably you have some collectd Install requests in opkg-auto.lua (because you installed those packages using opkg). In our lists there is only meta package ucollect and that one has priority set to 40 (https://repo.turris.cz/omnia/lists/i_agree_datacollect.lua).

That is curious, despite been uninstalled/removed there are still those entries in the opkg-auto.lua

Install(“collectd-mod-iptables”)
Install(“collectd-mod-ntpd”)
Install(“collectd-mod-rrdtool”)
Install(“collectd-mod-wireless”)
Install(“collectd-mod-vmem”)
Install(“collectd-mod-network”)
Install(“collectd-mod-cpu”)
Install(“collectd-mod-uptime”)
Install(“collectd-mod-thermal”)
Install(“collectd-mod-tail”)
Install(“collectd-mod-syslog”)
Install(“collectd-mod-protocols”)
Install(“collectd-mod-df”)
Install(“collectd-mod-memory”)
Install(“collectd-mod-dns”)

Those should not be there anymore, shouldn’t they? That seems sort of a bug.
Suppose I can remove them manually now?

What happened was the typical struggle (like mentioned in various forum posts) to get collectd working and in the process those packages been removed and re-installed afresh.
But now those are gone for good and thus should not show anymore in opkg-auto.lua

I also got something similar and wrote it here Updater failed: inconsistent: Requested package libustream-cyassl that is not available but noone seems to care so I deleted it manually

I am writing responds for you but debugging something takes time.

It can be bug but I have to check and you are not the only thing I am solving at the moment. Be patient.

Great thanks. I’m sorry for being impatient (but if you wrote that you’re looking on to it there, would be enough for me not to care any further). Without it I don’t know whats going on and I linked it here also because it seems related and it “lives” here :slight_smile:

You can remove those lines. And please see following answer: Updater failed: inconsistent: Requested package libustream-cyassl that is not available

So if you want to help me to debug it then it would be good if you could recall what exactly was sequence you did to end up with this state.

@cynerd sure, don’t mind giving a hand with the debugging

Not certain whether I can recall the steps exactly. I was trying to get collectd to work without having done anything to it after the intial installation.
Did read in the forums about creating the folders, installing luci-app-statistics, enabling/starting collectd and luci-app-statistics.

That did not work out satisfactory and thus unistalled collectd, anything collectd-* andluci-app-statistics and re-installed the bunch after having manually deleted some residue files which seemed to hold previous options for collectd.

In the end decided to let go of collectd and again uninstalled the bunch and ran updater.sh to see if the packages would pop up again and sure they did and the updater was escaped without installing those packages again.

At some point in between installed alsonetdata

Then modified the user.lua accordingly but without {priority = 60} and ran into issue as decribed in the earlier post. Ran the updater.sh again after having added {priority = 60} to user.lua and that was fine then, if not mistaken some residue libraries were removed during the process.

Then you told to look into opkg-auto.lua where those entires were still present.

That is roughly it. Suppose there is no difference between opkg from the cli or through LuCi Software because I did some here and some there.