Table of Contents


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 form the very beginning, but you can also switch Turrisu 1.x to it by hand, or wait for the automatic migration.

The difference is that the new updater manages all packages and not only a predefined set of packages. What is to be updated and in what order is not predefined by the server and the settings possibilities are less restrained. The new updater takes over the management of all packages without exception.

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 - either the repository or a locally saved package.

Manually editing the configuration

This method offers the most control over what happens. It's possible to edit the configuration file /etc/updater/user.lua, which 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 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:


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", "", {
  subdirs = {"base", "turrispackages", "packages", "lucics", "routing", "management", "telphony", "printing"},
  ca = "file:///etc/ssl/updater.pem",
  crl = "file:///tmp/crl.pem",
  pubkey = {

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

The ''Package'' command

Edits or creates a package (you still have to install it, either through a dependency or via the command Install). The usual use is to create a package “from a file” instead of from a repository. Creating a repository because of one package might be a little redundant, but if you have more packages, this is the recommended method:

Package("Tinypackage", { content = "file:///root/tinypackage.ipk" })

Using opkg

The opkg command edits the file /etc/updater/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.


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/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 /etc/updater/user.lua:

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.

The updater ends with an error: /tmp/crl.pem: No such file or directory

This mistake is usually caused by a malfunctioning internet connection. In that case it is recommended to check it using the Foris interface.

If the connection seems to be ok, you can try to run get-api-crl from the command line using SSH. This script will check that the file /tmp/crl.pem exists and isn't outdated and if that is the case, it will try to download it.