Table of Contents

Updater

The updater is a part of the firmware, which installs and maintains packages. It has a few advantages over the usual package managers, mainly a new system of package management and new settings possibilities. Let us first have a look at the general differences between package managers.

This manual page is exclusively about the new updater (updater-ng). This updater is being used by Omnia from the very beginning and Turris 1.x was migrated to it with Turris OS 3.7.

Standard package managers

Standard package managers, which are used for personal computers and servers, are programs, which know how to install packages. They act when commanded by the user. As a result, they function interactively - if there is a problem, they offer the user a solution and let him make the decision. What is more, they function at the level of individual packages. If the functionality of one package gets split between more packages, they don't try to automatically look for a solution.

opkg also falls into this category of packages and it doesn't carry out an update of the whole system - in order to keep implementation as economical as possible. It is maybe able to attempt a whole system update, but this brings the system to an unusable state in most cases.

Functions of the updater

The new updater combines some functions of standard managers (e.g. the ability to manage any package) and adds functions, which are specific to the router - mainly the ability to work completely autonomously. While running, the updater only informs the user and never actively asks.

In order to be able to carry out all these functions, the requirements and preferences must first be described in the configuration of the updater. The basic configuration usually only contains a list of repositories and a list of required packages, but it's also possible to describe preferences for solving problems or give a list of possible package candidates.

How the updater works

These are the basic slightly simplified steps, which the updater takes:

This has a couple of important consequences. First of all, the software that has been installed without the “awareness” of the updater will be removed during the next update. Second of all, every piece of installed software has to have a source (repository).

Manually editing the configuration

This method offers the most control over what happens. It's possible to edit the configuration files in /etc/updater/conf.d. They are in the programming language Lua and specific commands for the updater are described here (some parts are still not fully supported). The below mentioned commands are enough to set the basics.

After changes in the configuration, run the command updater.sh for the changes to apply straight away (and possible errors to be reported).

The ''Install'' command

This command is followed by one or more package names - a request to install those packages:

Install("vim-full")
Install("strace")

It's also possible to add further parameters specifying the installation, these are described in the above mentioned documentation.

The ''Repository'' command

Adds a new repository. For example:

Repository("turris", "https://repo.turris.cz/omnia/packages/turrispackages", {
  ocsp = false,
  pubkey = "file:///etc/updater/keys/release.pub"
})

You don't need to add this specific repository, because it is already set in the default settings, but you can add your own.

Using opkg

The opkg command edits the file /etc/updater/conf.d/opkg-auto.lua, when a package is installed or deleted. It has the same syntax as the below mentioned user.lua, with the difference that it is edited automatically and so it is not recommended to manually interfere with it.

This method is simpler and it can also work through LuCI, on the other hand it is an imperfect abstraction, because the functions of opkg and the updater are principally dissimilar. This means that if you make bigger changes, unexpected things can happen.

Using "userlists"

Userlists or also lists of packages can be turned on in Foris. They usually activate a number packages with a similar functionality. They work similarly to the old updater and the solution is very user-friendly. Packages from these lists are also maintained better than the rest and are tested together.

FAQ

I deleted a package, but it came back.

Deleting a package using opkg causes the package to be deleted from the system plus it also deletes that package from /etc/updater/conf.d/opkg-auto.lua, if it was there. If the updater concludes that the package is needed for another reason, it brings it back.

These reasons can be any of the following:

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):

Uninstall("Unwanted_package", { priority = 60 })

Similarly to the command Install, which requires the package to be installed, the command Uninstall requires the package not to be installed. There is a conflict of demands, but because a higher priority is set (default is 50), one demand is overweighed. Be warned, this can lead to the removing of other packages, for example if they depend on that package.

I installed a package, but it was removed.

This problem is commonly because of Uninstall command added most likely as a solution for previous problem. In such case removed package depends on package requested as to be absent and so it's removed. If you can accept to have package you requested to be absent on your system then just remove its Uninstall command from updater's configuration. If you insist on that package being absent then the only solution is to not to have all packages depending on it installed.