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.
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
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?
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?
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.
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.
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)