Updater is removing local packages

If I remember correctly I think i read s.th. about your staff being guinea piged for new releases at home routers. So this is not true?

Well said. Yes it’s true. But I don’t have just one router :-). And just because of that I misinterpreted which router sent email and thought that it is already released, when it isn’t. Because I received notification about update, but not from router that is in final (public) branch.
Once again sorry to for early noitice.

1 Like

btw, there are some not translated entries in updater.sh which makes it difficult to read it in console :wink:

root@kukuzi:~# grep -n à /usr/bin/updater.sh
164:          ním rozhraní Foris." "The updater requests an autorisation of its planned actions. You can grant it in the Foris administrative interface." || echo "Create notification failed" | logger -t updater -p daemon.error
187:    timeout 120 create_notification -s update "$(sed -ne 's/^I \(.*\) \(.*\)/ ⢠Nainstalovaná verze \2 balíku \1/p;s/^R \(.*\)/ ⢠OdstranÄ balík \1/p' "$LOG_FILE")" "$(sed -ne 's/^I \(.*\) \(.*\)/ ⢠Installed version \2 of package \1/p;s/^R \(.*\)/ ⢠Removed package \1/p' "$LOG_FILE")" || echo "Create notification failed" | logger -t updater -p daemon.error

fyi it is not un-translated… it’s bilingual first part in CZ (+ spoiled code page), second in EN, the same info… but hard to read, as you say

1 Like

Does the new version of updater also stop it from reinstalling packages that have been manually removed, or provide a way to block certain packages from being automatically installed?

Yes new version will support way of uninstalling installed packages. But not yet by just using opkg remove. You will have to edit /etc/updater/user.lua as described here: Updater failing (conflicts?)

1 Like

Good to hear, thanks.

root@turris:/tmp# wget https://api.turris.cz/openwrt-repo/omnia-test/packages/turrispackages/updater-ng_47_mvebu.ipk
root@turris:/tmp# opkg install updater-ng_47_mvebu.ipk
Upgrading updater-ng on root from 31 to 47…
Configuring updater-ng.
grep: ./etc/services_wanted: No such file or directory
grep: ./usr/lib/opkg/info/base-files.list: No such file or directory
Collected errors:

  • resolve_conffiles: Existing conffile /etc/config/updater is different from the conffile in the new package. The new conffile will be placed at /etc/config/updater-opkg.
    Warning: Locally installed packages will be removed with the next automatic update!

:frowning:
updater.sh
INFO:Queue install of updater-ng/turris/31

Hello

At first. Installing anything from test is not supported and will never be. So better be patient and wait for release.

And now to your problem. You are installing new version of updater, but using old wrapper script. This means that, as you are warned, locally installed packages are not yet supported. So updater doesn’t know about this locally installed package and as first it updates you back to known version. That’s why I explicitly stated that you must reinstall locally installed packages after updater update. Which means for you install it twice.

To make sure that it isn’t seen as bug, let me explain here primary difference between Updater and standard package managers like opkg or apt and so on. Those are expected to be run by user and when they are not sure they ask him. Normally it means that they print error message and fail. User it self is required to fix it. This can happen even if you are not installing any new software, just during updates. This is specially prevalent for rolling release distributions. Because updater runs in background on device that is not probably often maintained and is expected to run years long without reinstall it has to be more hands off and robust than standard packages managers. This comes in cost of some limiting features that should ensure that updater will be able to update system even without user attention. Locally installed packages can break this and that is why their support is kind of limited and wasn’t implemented at first (although planned). And that is why repositories are preferred solution, because there is expectation that those will be updated, but local package can’t be updated and it might even freeze system components on some old version if you specify unfortunate dependencies.

1 Like

After todays update the problem is gone.

1 Like

Removals of the packages continue, editing user.lua doesn’t stop them from happening :worried:

What do you put in there? Is it something like?:

Package "xyz" { content = "file:///usr/share/updater/local-pkgs/xyz_0.0.1_mvebu.ipk" }
Install "xyz"
Uninstall "knot-libdnssec" {priority = 60}
Uninstall "knot-libzscanner" {priority = 60}
Uninstall "knot-libknot" {priority = 60}
Uninstall "knot-resolver" {priority = 60}
Uninstall "unbound" {priority = 60}
Uninstall "unbound-anchor" {priority = 60}
Uninstall "dnsmasq" {priority = 60}
Uninstall "tinyproxy" {priority = 60}

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

Oh, I see. Well, there are some packages that are considered critical by the updater and won’t let you mess too much with them, so it is a bit harder to destroy the system. I was confused about the label „removing local packages“, I thought you wanted to install something directly from .ipk file.

But yes, you’re right, it might make some sense to have just one resolver and be able to choose which one it is. I’ll hopefuly find some time to modify the server-provided configuration to allow this soon.

Alternatively, if you really wanted to mess with it, you can have a look at this file (https://gitlab.labs.nic.cz/turris/updater/blob/updater-ng/src/pkgupdate/configs/entry.lua) and create your own configuration from scratch. Then you can disable the updater in foris and run it yourself with the top-level configuration of your own. But then, there are of course no warranties about what will go wrong.

Hmm, why is it so complicated, and how can knot or unbound be considered critical software? This is something strictly optional, and I see no reason why the updater should be preventing these packages from being removed.

I don’t really want to create a new configuration from scratch, why would I? I just want to remove a few packages I never wanted to have to begin with.

Well I would say that DNS resolver is pretty critical.

There’s a DNS resolver built into libc which is enough for most tasks, given that knot-resolver can’t be critical piece of software.

A bit longer answer than one of my collegue.

It is so complicated, because it is a router and it needs to do attention-less upgrades. If you have a server and do apt-get upgrade, it can ask questions. We can’t. The updater needs to solve the problems it has with the rules and flags it has. Furthermore, we wanted to be on the safe side, so we forced the „critical“ flag onto everything that is the very base TurrisOS system.

The stub resolver in libc is not enough, for several reasons. For one, it is a router. It is supposed to provide real resolution to such stub resolvers on the devices on your LAN. Omnia uses knot, you can alternatively switch to unbound. We don’t really support anything else, because, you know, there’s only limited amount of manpower and we can’t just test everything.

As the router uses its own resolver as well, removing it would break the internet access both to other devices on your LAN and the router itself, further preventing it from downloading any packages in manual attempt to fix that.

Depending on your OS on computer, if you try to remove some important parts, like libc or kernel, you’ll be prevented from doing that or you’ll be at least given a very loud warning. We can’t opt for the warning, because the updater needs to work on its own if the repository changes. So it can’t really decide to get rid of some of these things because it collides with some other request.

Yes, I agree that, in some cases, we marked more than absolutely necessary as critical. We try to err on the safe side. As I said, I’ll have a look at making it more flexible and allowing some more freedom. But I still think it is quite reasonable to mandate that DNS resolution must work both on the router and on LAN.

2 Likes

I supported quite a few routers with DNS forwarding and local DNS resolution, and I’ve never had problems with the built-in resolver. In this configuration, I prefer dnsmasq for both DNS and DHCP as it’s an integrated solution which handles dynamic DNS updates, DHCP, RA+DHCPv6 and DNS forwarding without extra configuration. Apart from that, I already have dnsmasq configuration from a different device which just works until Omnia updater breaks it by removing dnsmasq-full and installing unbound and knot. Apart from that, there having a daemon which answers on port 53 really isn’t a requirement for a router, other machines on a local network can just use the router’s upstream DNS.