Turris OS 3.6 out now

Cron problem… See above in discussion. Simply
mkdir /etc/crontabs/
/etc/init.d/cron restart

2 Likes

Howdy guys,

so excited to hear about OpenVPN integration. Could we expect such an amazing settings like https://www.youtube.com/watch?v=xiy52Hn5bTc ?? :blush:

Once again dnsmasq has had it’s port reset to 0, disabling the dns part. leaving those of us running it without a usable router.

1 Like

I think there should be created a group of beta testers of experienced candidates from this forum (it’s not me), in order to avoid such unnecessary errors dropped from among the public, which no wants to deal with openWRT code reusability. (that’s me).

My final decision is to Roll back to snapshot before 3.6 and disable updates for 10 days.
I did rollback already once, and as soon router grabbed 3.6, the same set of various problems.

  • lighthttp stops responding
  • Majordomo not working
  • stats data not sent to turris
  • high CPU for hours 5+ (openssld even OpenVPN not selected yet)
  • cron does not work

I have to stress, I do have only standard setup, no custom modules, manual changes, etc…

My router was affected by the same issue, I had to set the dnsmasq port again.

Given that the dnsmasq port is part of the user’s configuration, why did the update change it?

Could we have a statement from the Turris devs on this please?

Is setting dhcp.@dnsmasq[0].port=‘53’ not the correct way to prefer dnsmasq over knotdns?

The update broke IPv4 on one of my two routers (the other works fine). The broken router can route IPv6 internet traffic (not local), but doesn’t work at all on IPv4 (Foris, Luci, general HTTP/S, SAMBA).

How do I debug this thing without having a serial console? I save logfiles to an external harddrive, but there are no logs from starts with the updated system (only after a rollback).

I tried running opkg update and updater.sh from commandline, the same result. I saw these (probably problematic?) warnings (though I’m sure I haven’t manually edited most of the mentioned files):

WARN:Script revision-specific not found, but ignoring its absence as requested
WARN:Script serial-specific not found, but ignoring its absence as requested
WARN:Config file /etc/updater/auto.lua modified by the user. Backing up the new one into /etc/
WARN:Script revision-specific not found, but ignoring its absence as requested
WARN:Script serial-specific not found, but ignoring its absence as requested
WARN:Config file /etc/config/updater modified by the user. Backing up the new one into /etc/co
WARN:Config file /etc/config/user_notify modified by the user. Backing up the new one into /et
WARN:Config file /etc/config/resolver modified by the user. Backing up the new one into /etc/c
WARN:Config file /etc/config/foris modified by the user. Backing up the new one into /etc/conf
WARN:Config file /etc/passwd modified by the user. Backing up the new one into /etc/passwd-opk
WARN:Config file /etc/config/system modified by the user. Backing up the new one into /etc/con
WARN:Config file /etc/shadow modified by the user. Backing up the new one into /etc/shadow-opk
WARN:Config file /etc/profile modified by the user. Backing up the new one into /etc/profile-o
WARN:Config file /etc/inittab modified by the user. Backing up the new one into /etc/inittab-o
WARN:Config file /etc/shells modified by the user. Backing up the new one into /etc/shells-opk
WARN:Config file /etc/rc.local modified by the user. Backing up the new one into /etc/rc.local
WARN:Config file /etc/group modified by the user. Backing up the new one into /etc/group-opkg
WARN:Config file /etc/config/ucollect modified by the user. Backing up the new one into /etc/c

When can we expect a fix for the awful wifi stability? Both the 2.4Ghz and 5Ghz are unusable. Devices drop off all the time complaining about no internet or connection quality. I tried everything I could find on the forum, channels, country settings, power settings, placement, antennas. Nothing makes a change.

I bought 4 Omnias and I’m close to returning them to Amazon this week. Non provides stable wifi, even tried in different houses in different cities running stable and nightly builds.

It’s a pity as the 80 EUR VR200v routers the Omnias where meant to replace just work ever since I got them without a single hickup.

I don’t mean to sound too harsh, I love this project, but what is it worth without working wifi and currently I have close 1400 EUR of hardware lying around which I can’t use.

By me wifi 2,4 and 5 all time withouth problem.

Same here, WiFi on both bands is rock solid.Only time I had problems was with the ath10k-CT firmware on the 5 GHz band.
I suspect some people got some dodgy hardware.

I’ve repaired cron after upgrading to 3.6 manually, Luci installs don’t work (I can live with that), data collection stopped.

I’ve turned upgrades off, thinking about reverting to 3.5.

Taking into account that my Omnia configuration is very close to “out-of-the-box” one, more specifically, I have only

  • network and wifi configured
  • added two fw rules for ssh access from outside
  • added two collectd-mod- packages
  • and a single cron job (changing LED intensity :)),
    I’d expect the upgrades to be butter-smooth. I’d expect this to be a plug-and-forget device, just much more secure than my previous router that hasn’t been updated for years.

My disappointment is extreme. I love the idea of the project, but I like having a working device much more, especially for the price.

Well I am surprised to see 3.6 coming out because my Turris is still sat on TurrisOS 3.2.1 !
After reading the contents here I have turned my updater off, though it looks like that won’t trouble the router anyway if it hasn’t been updating! LOL

Is there a change log and a way of getting to 3.5 without going to 3.6 ?

Wait for 3.6.1. It should fix all the problems which 3.6 brought.
It will be released soon!

5 Likes

Does 3.6.1 also fix the problem of wifi cards not coming up anymore since the update? Wifi was rock solid before that. After update wifi is gone (both LEDs dark) no matter how often I restart. when I revert it works perfectly

EDIT: I schnapps I saw that since the non-working wifi version there were 2 more updates. So I reboted again and wifi came up just fine. So it seems wifi is (hopefully once and for all) fixed.

Looks like it’s solvable Turris OS 3.6 made ucollect/firewall log unstable

Last update again rewrote the path to data storage for graphs in Statistics section:

                 /mnt/sda1/rrd ... /tmp/rrd

There are known bugs in opkg for which I provided patches upstream. The patches have been accepted into LEDE, and I mentioned them to Turris support, but I don’t believe they have been integrated into Turris yet. https://github.com/openwrt/packages/issues/1922

As a workaround on Turris, please edit /etc/lighttpd/conf.d/luci.conf and change “setenv.set-environment” to be “setenv.add-environment”. Then, restart lighttpd and you will be able to install packages from within LuCI. (setenv.set-environment is a new directive in the not-yet-released lighttpd 1.4.46)

I apply youre recomendation

# lighttpd include file for LuCI

## Set CGI paths
cgi.assign += (
        "/cgi-bin/luci" => ""
)

## Set aliases to LuCI install directory
alias.url += (
        "/cgi-bin/" => "/www/cgi-bin/",
        "/luci-static/" => "/www/luci-static/"
)

$HTTP["url"] =~ "^/cgi-bin/luci" {
        # Add 'X-Frame-Options' header, making sure it the website is not embedded in a frame or iframe.
        # This avoids clickjacking, and might be helpfull for HTTPS websites
        # As frames are not used nowadays, this should be safe to enable at least SAMEORIGIN
        # Other option might be DENY or ALLOW-FROM. DENY is not used as frame is used in some old LuCI modules
        setenv.add-response-header  += ( "X-Frame-Options" => "SAMEORIGIN")
        # setenv.set-environment = ( "PATH" => "/usr/bin:/usr/sbin:/bin:/sbin" )
        setenv.add-environment = ( "PATH" => "/usr/bin:/usr/sbin:/bin:/sbin" )
} 

===================================================================
And resume is good … thanks … what simply. !!! For me it fixed also Segmentation Fault !!!

It would be nice to have a detailed changelog of the changes linked from the announcement. At least if the banner would link to this thread, it would make it easier for people to discuss the changes! :slight_smile: I had to dig around the forums and happened to find this thread by chance…

For me, running updater.sh worked well. I had queued the removal of majordomo because of this issue so there was some noise about this, but otherwise I think everything is fine:

root@octavia:/tmp# updater.sh 
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  1076  100  1076    0     0   2062      0 --:--:-- --:--:-- --:--:--  2069
WARN:Script revision-specific not found, but ignoring its absence as requested
WARN:Script serial-specific not found, but ignoring its absence as requested
INFO:Queue install of vixie-cron/turris/7-2
INFO:Queue install of dhparam/turris/2.1
INFO:Queue install of turris-version/turris/3.6.1
INFO:Queue install of luci-app-statistics/turris/git-17.009.29435-7d19852-2
INFO:Queue install of luci-i18n-statistics-cs/turris/git-17.009.29435-7d19852-2
INFO:Queue install of luci-i18n-statistics-en/turris/git-17.009.29435-7d19852-2
INFO:Queue removal of luci-app-majordomo
INFO:Queue removal of lcollect-majordomo
INFO:Queue removal of ouidb
INFO:Queue removal of coreutils-timeout
INFO:Queue removal of lcollect
INFO:Queue removal of ucollect-lib
INFO:Queue removal of gdb
INFO:Executing preupdate hooks...
INFO:Subprogram output: /etc/updater/hook_preupdate/05_schnapps.sh:
Snapshot number 38 created

INFO:End of subprogram output
Output from lcollect-majordomo.postrm:
/usr/lib/opkg/info//lcollect-majordomo.postrm: line 2: /etc/init.d/lcollect: not found
ERROR:Failed operations:
lcollect-majordomo/postrm: /usr/lib/opkg/info//lcollect-majordomo.postrm: line 2: /etc/init.d/lcollect: not found


INFO:Executing postupdate hooks...

This gave me the following banner on the next login:


Update from 2017/03/25 10:05:44
• Installed version 7-2 of package vixie-cron
• Installed version 2.1 of package dhparam
• Installed version 3.6.1 of package turris-version
• Installed version git-17.009.29435-7d19852-2 of package luci-app-statistics
• Installed version git-17.009.29435-7d19852-2 of package luci-i18n-statistics-cs
• Installed version git-17.009.29435-7d19852-2 of package luci-i18n-statistics-en
• Removed package luci-app-majordomo
• Removed package lcollect-majordomo
• Removed package ouidb
• Removed package coreutils-timeout
• Removed package lcollect
• Removed package ucollect-lib
• Removed package gdb

News from 2017/03/25 10:05:42
 • dhparams: fix symlink creation to fix OpenVPN plugin
 • util-linux: fix building of some parts and dependent packages
 • luci-app-statistics: mark configuration files as such to prevent overwriting
 • vixie-cron: included empty currently needed directories 

I’d love to hear more about those DNS resolvers changes… Where can we find more detailed changelogs of releases?

Thanks for your hard work!

so far… so good.

went to my backup router, took some backups of data and configuration fines on the Omnia and did a complete factory reset (it was running 3.2.1 after that). did a full upgrade to 3.6.1, then went about restoring my configuration. everything is good so far.