Turris OS 3.10.1 released!

I made the symlink, no change after restart.

My dmesg seems to be somehow logrotated, so it only contains about last 100-1000 messages or so.

dmesg should contain just a kernel messages, not the system ones, so it should be shorter.

Two more things to try:

ln -s ../modules.d/usb-storage-uas /etc/modules-boot.d/21-usb-storage-uas
(or you can just rename the symlink you already have)

And other idea is to make sure you are able to boot without the drives and attach them after Omnia fully booted up.

Thanks, now I am at 3.10.1

1 Like

Still no change…

No, the dmesg is somehow truncated from the start, like this:

$ dmesg | head -n1
[ 1191.264002] turris-00000000: IN=pppoe-wan OUT= MAC= SRC=151.106.13.150 DST=82.142.96.238 LEN=445 TOS=0x00 PREC=0x00 TTL=53 ID=21949 DF PROTO=UDP SPT=5165 DPT=5060 LEN=425 MARK=0x2 

You see the newest message is actually quite old…

I’m now not physically at the router, so I’ll do the unplug-replug test later. Do you have any guidelines on how to do it when /srv is on this drive?

1 Like

Hi! after update on TO router I dont have any major issues only nikola interface dont running after /etc/init.d/ucollect restart its ok.

next thing when you create cloud backup in foris you cant keep them I get this error:

I had to stop ddns service as recommended by turris support and killed pkgupdate process. The run pkgupdate again and reboot. Now everything is working fine.

Well, why is it with the updates creating every time issues? :anguished:
I guess better rollback via schnapps and pray for the next update to be less (as in 0) messy

Updater selhal:

[string “transaction”]:317: [string “transaction”]:146: Collisions:

• /lib/modules/4.4.134-8f7f4132dc88fb7034ce9648e5961be5-0/nf_nat_masquerade_ipv4.ko: kmod-nft-nat (new-file), kmod-ipt-nat (new-file)

• /lib/modules/4.4.134-8f7f4132dc88fb7034ce9648e5961be5-0/nf_reject_ipv6.ko: kmod-ip6tables (new-file), kmod-nft-core (new-file)

• /lib/modules/4.4.134-8f7f4132dc88fb7034ce9648e5961be5-0/nf_reject_ipv4.ko: kmod-nft-core (new-file), kmod-ipt-core (new-file)

Come on don’t make me angry @anon50890781. Look back to original topic where I was answering you (Nf_nat_masquerade_ipv6 and kmod-nft-nat collision). This is not new problem and is caused by you trying to use both nft and iptables at the same time (something that OpenWRT wasn’t clearly designed nor tested to do). If you want to have it changed/fixed then please submit patches. Otherwise don’t proclaim that it’s new problem. It’s not.

1 Like

You tried to explain why things are not working and now even pointing the finger at the user for daring to use packages coming through the TO repo… Notwithstanding asking repeatedly the user to supply patches to a repo that is ill maintained.

Just to be clear - it is not my job to provide proper housekeeping of the repo and issue patches. I paid for the device and like for another such router I can expect the vendor to keep it running smoothly.

Since it is a known issue why it is not getting fixed, apparently you are aware of the underlying cause, like pointed out in the thread you cited. Argh, I forgot there are always other priorities (but seldom the users’)

ipt and nft are clearly designed to cohabit somewhat similar to ipv4 and ipv6, latter being promoted as to be embraced as the future. Same can be said about ipt and nft.

Whilst it may not be ideal it should not create an issue, and it is not on other boxes I am running with ipt and nft side by side.

You are still missing the point. You are the only user I know about trying to use nft on Turris. I have nothing against it. In fact power to you that is what Turris is all about and I was trying to help you in multiple topics already. But please see clear picture. Either I will invest time in fixing issue that affects one user (I know that would be awesome because that user is you) or I could fix issue that affects hundreds or thousands users. Please choose wisely. Me asking you for patches is nice way to tell you that I most probably won’t have time to fix it. But that doesn’t mean that you can’t fix it for your self. That is one of the best advantages of open source. If original author has no time to fix your specific problem then you can fix it your self and contribute. You are not doing work for us you are doing it for your self.

If we would be evil corporate then our support would told you: You are operating device outside of specifications. You can send it for repair but it won’t be covered by warranty.
No instead developer told you: We accept patches.

1 Like

Once I get the time I will finalize the nft fw and get rid of ipt and thus this particular issue.

There is certainly no complaint about you being helpful. And I have grasp of minority vs majority policies and the apparent constrains of the TO team. I am off to self-help then.

Foris -> WAN returns “An unexpected error has occurred”:

Remote Exception: Incorrect output. {'action': 'get_settings', 'kind': 'reply', 'data': {'wan6_settings': {'wan6_static': {'ip': 'fe80::2', 'network': 'REDACTED', 'gateway': 'fe80::1'}, 'wan6_type': 'static'}, 'wan_settings': {'wan_type': 'static', 'wan_static': {'ip': 'REDACTED', 'netmask': 'REDACTED', 'gateway': 'REDACTED'}}, 'mac_settings': {'custom_mac_enabled': False}}, 'module': 'wan'}

EDIT: Hmm, hard to say. (L)uci accept IPv6 address with or without prefix, but Foris get stroke when something unexpected appears.
OK, I’ll change it to fe80::2/64 but I’m sure Foris should have react more relaxed.
At least Foris should be able to survive any configuration issues (Foris may refuse to save it, but not die at load).

Hello,

As we have only your screenshot, which only says "Error: The backup was not found."
We think that this could be caused, when registration code doesn’t exist.
You can check it e.g. with this command, but don’t post here registration code:

sh -x /usr/share/server-uplink/registration_code.sh

or even it doesn’t say can you check if you have the password for Cloud Backups in /etc/config/ssbackups.

Turris OS 3.10.1 - netdata application does not work :(.

root@turris:~# netdata
2018-06-07 20:43:15: netdata FATAL: Cannot cd to directory ‘/var/cache/netdata’ # : Invalid argument

2018-06-07 20:43:15: netdata INFO : Cleaning up database [0 hosts(s)]…
2018-06-07 20:43:15: netdata INFO : netdata exiting. Bye bye…

3.10.1 so far running fine. Thanks.

I did not check the updater logs as I just triggered the update via web interface this time.

Thanks for reporting. We’ll look into it and try to fix it to 3.10.2.

So far everything went fine on my side - 2 connected omnias (one as a DHCP-server and router behind a VDSL2-modem, one as an accesspoint).
Nothing special installed (openvpn server, ddns, adblock), no special configuration (2 separate VLANs), no special hardware (compex WLE1216v5-20 instead of original 2,4GHz wificards).

Progress with the UAS driver - I succeeded rebooting the router without the drive and connecting it later. This is what I got in dmesg:

USB controller ... does not support streams, which are required by the UAS driver.

Following from https://bbs.archlinux.org/viewtopic.php?id=207621 it should be a problem on the motherboard and not the drive.

To be sure, I connected the drive via the same cable to a notebook wiht Ubuntu, and the UAS driver was used there. So the drive is ok and really does support UAS on Linux.

Is it possible that the USB controller on TO does not support UAS?

Error notifications

Updater failed:
[string “transaction”]:317: [string “transaction”]:146: Collisions:
• /usr/bin/updater-wipe.sh: updater-ng (existing-file), updater-ng-migration-helper (new-file)