Turris OS 3.11 is out!



I had to restart router few times to get rid of that error:

usb_serial_generic_write_bulk_callback - nonzero urb status: -71

It is about z-wave usb controller (generic usb-serial driver).
Everything else went smooth.


After the update, when calling the schnappi.sh I get

Warning, could not drop caches
Warning, could not drop caches
Warning, could not drop caches

Everything seems to work. Shall I be worried about the warning? What can I do to make it go away?

I use Turris 1.1 upgraded, BTRFS, 32 GB SD card with lots of free space

root@turris:~# df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/mmcblk0p2           29.8G    867.7M     28.6G   3% /
tmpfs                  1011.5M     11.2M   1000.3M   1% /tmp
tmpfs                   512.0K         0    512.0K   0% /dev

| ID |      Size | Type   | Date             | Comment                        |
| 60 |  34.19MiB | pre    | 2018-09-20 16:31 | Automatic pre-update snapshot  |
| 61 |  10.02MiB | post   | 2018-09-20 16:37 | Automatic post-update snapshot |
| 63 |   9.98MiB | pre    | 2018-09-26 17:39 | Automatic pre-update snapshot  |
| 64 |  10.08MiB | post   | 2018-09-26 17:40 | Automatic post-update snapshot |
| 68 |  11.12MiB | pre    | 2018-10-15 21:51 | Automatic pre-update snapshot  |
| 69 |  11.23MiB | post   | 2018-10-15 21:54 | Automatic post-update snapshot |
|  6 | 183.21MiB | single | 2018-03-06 22:54 | User created snapshot          |
| 73 |  10.34MiB | time   | 2018-11-11 01:05 | Snapshot created by cron       |
| 74 |  10.16MiB | time   | 2018-11-18 01:05 | Snapshot created by cron       |
| 75 |  10.09MiB | time   | 2018-11-25 01:05 | Snapshot created by cron       |
| 76 |  10.09MiB | time   | 2018-12-02 01:05 | Snapshot created by cron       |
| 77 |  10.08MiB | pre    | 2018-12-03 17:16 | Automatic pre-update snapshot  |
| 78 |  10.08MiB | post   | 2018-12-03 17:18 | Automatic post-update snapshot |
| 79 |  10.09MiB | time   | 2018-12-09 01:05 | Snapshot created by cron       |
| 80 |   6.64MiB | pre    | 2018-12-10 16:43 | Automatic pre-update snapshot  |
| 81 |   1.39MiB | post   | 2018-12-10 16:52 | Automatic post-update snapshot |


I have the same issue on both of my Turris 1.1 boxes. They were without errors before upgrade to 3.11. Now, when I do “schnapps list”, it starts with

Warning, could not drop caches
Warning, could not drop caches
parent transid verify failed on 194887680 wanted 8597 found 8546
parent transid verify failed on 194887680 wanted 8597 found 8546
Ignoring transid failure
Warning, could not drop caches

followed by correct list of snapshosts.
I believe I have enough free space on SD card. One is

Filesystem                Size      Used Available Use% Mounted on
/dev/mmcblk0p2            7.1G    750.7M      6.1G  11% /

And second is very similar

Filesystem                Size      Used Available Use% Mounted on
/dev/mmcblk0p2            7.3G    705.9M      6.6G  10% /

Any idea? Should I worry? Or plan to export snapshot, factory reset, migrate to BTRFS again, import snapshot? It emerged on two boxes at the same time. If that is corrupted BTRFS, then it was corrupted by upgrade to 3.11. Please, investigate it, because if upgrade to 3.11 corrupts BTRFS, then there is the risk it will corrupt it again after recovery process and my effort would have been unnecessary.


Just filed two more bugs:

Can’t reliably get to Luci from turris webapps page
Turris OS 3.11: miniupnpd no longer starts at router boot

@Pepe please check these out.

@sammy_cda I suspect my bug above is the true reason UPnP is not working out of the box on 3.11. When I fixed that issue, I didn’t have to have any other package installed but miniupnpd for UPnP to work. minidlna is only needed if you’re using the router as a media server, and miniupnpc is the UPnP client, it doesn’t need to be on the router.


I expect that Turris kernel is still missing CONFIG_ADVISE_SYSCALLS and consequently we’re hitting https://patchwork.kernel.org/patch/9603285/ Some people here used to miss madvise, too.

EDIT: I believe the warning from btrfs is harmless, given the semantics of POSIX_FADV_DONTNEED. (No guarantees though.)


Another crappy release breaking things which worked before.

  1. Removed youtube-dl package prevented upgrade:
##### Error notifications #####
Updater selhal: 

inconsistent: Requested package youtube-dl that is not available.
  1. mpd package is broken:
# /usr/bin/mpd 
Error loading shared library libavformat.so.57: No such file or directory (needed by /usr/bin/mpd)
Error loading shared library libavcodec.so.57: No such file or directory (needed by /usr/bin/mpd)
Error loading shared library libavutil.so.55: No such file or directory (needed by /usr/bin/mpd)


You’re the first, who reported issues with those two packages. Thank you for reporting them as nobody reports it even this release was for a month in RC version.

  1. Unfortunately, I don’t know right now, why youtube-dl wasn’t compiled.

  2. We know, what’s went wrong with mpd.
    This will be fixed in Turris OS 3.11.1 as we’d like to release to RC very soon. What should work for you is to force reinstall the package, which you can do with the following command.

opkg update && opkg install mpd-full --force-reinstall


Not sure how many of TO user are familiar with the schnapps concept, which though requires ssh access and that might be the first stumbling block. Access to schnapps via Foris might improve the situation.

The issue with schnapps is however that it creates 2 snaps and the second one is from after the update and if the update botches the router, as in not accessible, the hardware rollback would revert to the snaps from after the update and thus create a loop. Hence one would have to be aware and delete the second snap prior rebooting. Perhaps this should be thought over in order to provide a failsafe since access with the UART console is even more challenging.

Configuration backup does covers just bare bone (etc\config\ | \etc\updater\ | firewall user) and thus restoring from there in worst case will leave the user still with some work. Perhaps it could be more comprehensive like medkit.

Long story short - if switching between stable and rc is easy and recovery would more convenient for the less advanced user TO might gain a broader user spectrum willing to participate in RC testing. In the end a good stable release would benefit each user.


I think doing a 2 LED Reset twice should bring to back to the snapshot before the update.

Maybe split this topic? I totally agree with what you wrote…


Thanks, the mpd reinstallation did indeed help.

As for RC testing, you can’t expect everybody to run RC. For me it’s enough to get breakages which appear in the releases, I don’t want to see more of that…

Some basic sanity tests could be done automatically - AFAIK missing packages did happen in the past and that should be easy to detect automatically. Missing libraries (if that’s really the problem cause) would be also easy to spot automatically.


The mpd thing is also a missing package, I believe. I expect you were left with the old version when it disappeared, and by accident the sonames of ffmpeg libraries got bumped at the same time…


I had mpd-full already, there is Install("mpd-full") in /etc/updater/conf.d/opkg-auto.lua.


Vzhledem k tomu, co jsem si přečetl výše jsem využil možnosti oddálení aktualizace o 72 hodin, kterou mám dlouhodobě nastavenou a ve Forisu dále jsem vybral volbu “Odmítnout”. Již v tento moment mě překvapilo, že datum aktualizace nebylo za tři dny, ale tři měsíce (únor 2019).

O to více jsem překvapen, že mi dnes (po čtyřech a ne třech dnech) přišla zpráva s tím, že k instalaci právě došlo společně s přehledem dalších balíčků, co čekají na schválení. Za dalších tři a více dnů tak zřejmě mohu čekat nezávisle na nastavení Turris OS 3.11 a rozbitý router.

• Nainstalovaná verze 20180409-2 balíku ca-bundle
• Nainstalovaná verze 7.62.0-2 balíku libcurl
• Nainstalovaná verze 60.4.6-3.6-2 balíku updater-ng


Hi Sammy_cda,

I saw your post and followed your advice. Alltough it had no effect at first, it now seems to work.


But Luci is still as slow as it gets. Every page takes some 6 sec… to open.


See my bug here https://gitlab.labs.nic.cz/turris/turris-os-packages/issues/268 I think that’s the real reason UPnP didn’t work. I didn’t have to install miniupnpc or minidlna once I fixed that (I have no need for the functions of those packages)

inconsistent: Requested package youtube-dl that is not available.

Should be fixed in Turris OS 3.11.1., we’ll release the RC version, really soon.
We have updated it to version 2018.12.09 and also we sent the PR to OpenWRT as well.


This does not look good. For me, it might seem like a corrupted file system, right now, you just have 2 transactions, if they appear more, then it’s for sure something bad and I do not even want to tell you that you should ignore them, because, in the end, it’s your data. Not mine and you would have to know if you have any backups, and if not, it’s a good time to have some backups.

Anyway, let’s take a look at those 2 transactions. According to BTRFS kernel documentation:

Under normal circumstances the generation numbers must match.

Would you please try the following command and send me the output from it? It will show you if they are any I/O errors.

btrfs dev stat /dev/mmcblk0p2

Then, I would start with command btrfs scrub, which would verify the block checksums for data and metadata blocks. If it somehow succeeds, I’d suggest you change the microSD card for a new one or try to format the current microSD card and after you do it, you can try to use something like H2testw to check your microSD card.

And finally, the last interesting question, did you have a power outage?


We have enabled it for Turris 1.x in Turris OS 3.11.1.

INFO:Running post-install and post-rm scripts
Output from resolver-conf.postinst:
chown: unknown user/group kresd:kresd
uci: Entry not found

Should be fixed in Turris OS 3.11.1 by this commit from @paja


I seem to be unable to find any news from @paja on this, hence this reply.
After the upgrade to 3.11 my TO does not resolve anymore, despite that kresd was up and running (seemingly). After killing kresd, I tried restarting it, which still gives the already reported error:

root@jib-router:~# ps | grep kres
1974 root 104m S /usr/bin/kresd -c /tmp/kresd.config -f 1 /tmp/kresd -a 53 -a 53 -a 53 -a
25436 root 1108 S grep kres
root@jib-router:~# kill 1974
root@jib-router:~# /etc/init.d/kresd start
chown: unknown user/group kresd:kresd