Turris OS 5.2 is released!

Dear Turris community,

After several weeks of intensive testing and 4 release candidates, we have just released long-expected Turris OS version 5.2!

Your router will update itself automatically from Turris OS 4.x or 5.x version. Do not forget to approve that update in reForis Updater tab if you use delayed or manual updates.

If you are running Turris OS 3.x, consider using optional migration, which was improved in this latest release.

We have been working on this feature release for some time, and I need to say this is one of our huge updates.

We prepared for you new features in reForis such as Overview, which provides you status about activated or disabled services such as Sentinel threat detection system, automatic updates, Dynamic firewall, connection test and speed test, etc. There is a new Storage plugin with RAID option, you can use an already prepared drive. You can fill Honeypot as a Service in its dedicated tab in reForis without using CLI. You can set your own hostname for the router in reForis and make a factory reset from it as well.

You might find interesting to install RIPE Atlas SW Probe and common passwords in Package management.

More and more devices lack an Ethernet port these days. To ease the first setup on such devices, we prepared initial Ethernetless configuration, but it requires updating the factory image version to Turris OS 5.2, which you can do by using a medkit.

The Dark side rises on the web and so our landing page called WebApps together with the documentation includes a dark theme as well! We hope that you will like it as we do!

Highlights in this release:

More details about this release can be found on our blog in both Czech and English variant.

Let me include a little insight to our development process. Along with working on previous Turris OS 5.1.x fixup releases, we started to work on this Turris OS 5.2 feature release on August already. There are more than 300 merged pull requests and 137 completed issues included in this release according to the milestone on our GitLab.

We would appreciate your voices regarding new features, which we prepared for you, and if you find any bugs, reach our technical support, and consult them there.


This post is reserved e.g. for known bugs, etc.

Well, would it be possible to update the router outside of business hours? I know I am not the first one to experience this.

Having calls interrupted, because an update is pushed is not great.

TIA for fixing this. I am counting on you @turris team

Error notifications

Updater failed:

runtime: [string “requests”]:430: [string “utils”]:422: Unable to finish URI (https://repo.turris.cz/hbs/omnia/lists/pkglists/datacollect.lua): Download failed

Hello @pete,

Thank you for your question.

You are right. We are aware that this feature was requested a few times here on the forum. There is created issue for it:

I agree with you that it is not good if your videoconference is interrupted and you don’t know why during the Covid-19 pandemic. During this update, there was an updated Knot Resolver and some related services to it, and it should reload the network, so there was a slight Internet outage (a few secs) during the update. Hardly noticeable for someone.

Usually, @Vojtech.Myslivec and I are working in the evening, especially around midnight. We like to release new updates (into branches HBT, HBT). But, in this case, it was not possible because this release was well organized with several team members.

Here are some data, which I can share with you as these are publicly available and can be found based on the thread or post creation. The date and time are time-based on the Czech Republic. Right now, GMT+2.

Others can say that they don’t want to have updates in the morning. :frowning:

This could be related to your Internet connection outage, but in reForis, you can go to Package Management → Updates and click on Check and install updates to see if it appears once more.

happened here too, apparently installation of wpad?

May 26 16:32:03 turris updater[16672]: src/lib/logging.c:201 (log_subproc_open): Running postinst of wpad
May 26 16:32:05 turris pppd[29440]: Terminating on signal 15
May 26 16:32:05 turris pppd[29440]: Connect time 1430.0 minutes.
May 26 16:32:05 turris pppd[29440]: Sent 266729584 bytes, received 2939973780 bytes.
May 26 16:32:05 turris netifd: Network device 'pppoe-wan' link is down
May 26 16:32:05 turris pppd[29440]: Connection terminated.
May 26 16:32:05 turris pppd[29440]: Sent PADT
May 26 16:32:05 turris pppd[29440]: Exit.

I guess not only reboot should be schedulable to night…


after upgrade to 5.2.0 luci web interface does not accept root password. I still can login to reforis and via ssh to the router.
Can anybody help?

1 Like

AH OK fix for this issue was to DELETE cookies for my router from browser restart browser and login back

1 Like

This approach can’t work that well anyway, I think. Turris users are commonly spread across a too wide range of timezones (US + Europe), and the updater check isn’t that frequent so it randomly adds a few more hours of spread. Therefore that open ticket is the way to go.


I upgraded with largely no problems.

I did lose wifi briefly after the update, but before reboot and similarly, the web interface went away for a few minutes, but came back with the 5.2.0 interface. I was expecting these to stay up until reboot. ssh over ethernet never went down.

Does anybody else have problems with DNS? Running own kresd and after upgrade entire dns func is gone :slight_smile:

Don’t understand why local resolve service is being served by python service (/usr/bin/python3 /usr/bin/foris-controller) on udp/5353. Should be kresd on udp/53, right?

EDIT: I had to disable kresd listening addresses so it listens only on localhost - can anybody tell me why? If else addresses are defined then kresd responds with: address in use can not bind. Another point is that root.hints file has been moved to /etc/knot-resolver/root.hints; it used to be /etc/kresd/root.hints. Did I miss something in kresd docs?

Thanks für the update and good work!

Anyway, i have to agree with pete and would prefer that the router does not update or reboot during working hours. The router (MOX here) supports regions and time zones and offers reboot times, even i do not know if this is in 12 or 24 hours format. So i guess an individuall update / reboot configuration should be possible.


UDP/5353 is mDNS which is not implemented in kresd. Overall I don’t get this paragraph you wrote.

Turris OS moved the etc directory now, years later than upstream Knot Resolver. But what’s the issue with the move?

You’ll probably have to look which service collided with kresd. By default it listens on all addresses of the lo and br-lan interfaces. Listening just on localhost can’t provide DNS to the LAN which is the main point of the daemon.

I am unable to update from 5.1.10
turris ~ # pkgupdate
INFO:Target Turris OS: 5.2.0
ERROR:inconsistent: Requested package dhparam that is not available.

1 Like

Package dhparam was removed. You probably explicitly installed it. It is for sure noted somewhere in /etc/updater/conf.d files. Just remove Install request from the file. Note that opkg remove dhparam might help you as well but there is a fix package fix-dhparam-to-cagen that uses it as the trigger for migration so OpenVPN configuration would not be migrated if you remove it before the update.

I have the same issue.

Can you be a bit more specific please, there are a lot of files in conf.d which are scripts.

I have found a reference to install(“dhparam”) in opkg-auto.lua but there is a note at the top of the file that says: “-- A file with auto-generated Install commands. Do not edit.”

Please confirm instructions to rectify the issue (I don’t recall installing this package myself?)

You probably did installed it by yourself as opkg-auto.lua notes packages installed using opkg install. It is all right to remove lines from that file but nothing should be added to it to not break opkg integration with updater. It is safe to remove that line from that file.

1 Like

Nit: the link for storage plugin in the bullet list in the announcement above goes to the HAAS page instead.

I have configured ‘reboot time’ in my Update Settings to be 03:30. Despite that, reboot happened at 09:27 today.

I also have automatic approvals after a delay at 12 hours - so that bit seems to be working fine; but the reboot time is not honoured.

1 Like