It’s clean… only for /srv i copied old LXCs, pakon, rrd content. But / is totally fresh, didn’t move a single config.
For LXC under Luci, before I updated containers configs, it failed to show any existing containers. Now after updating configs of containers that subview are showing up. Need to see if fixing this fixed the rpcd crashing issue.
Have no idea what is wrong with rpcd, but I’ll try to help with other problems.
Check Your luci config:
config core ‘main’
option mediaurlbase ‘/luci-static/bootstrap’
option resourcebase ‘/luci-static/resources’
option lang ‘pl’
config extern ‘flash_keep’
option uci ‘/etc/config/’
option dropbear ‘/etc/dropbear/’
option openvpn ‘/etc/openvpn/’
option passwd ‘/etc/passwd’
option opkg ‘/etc/opkg.conf’
option firewall ‘/etc/firewall.user’
option uploads ‘/lib/uci/upload/’
config internal ‘languages’
option en ‘English’
option pl ‘Polski (Polish)’
config internal ‘sauth’
option sessionpath ‘/tmp/luci-sessions’
option sessiontime ‘3600’
config internal ‘ccache’
option enable ‘1’
config internal ‘themes’
option Bootstrap ‘/luci-static/bootstrap’
config internal ‘apply’
option rollback ‘30’
option holdoff ‘4’
option timeout ‘5’
option display ‘1.5’
config internal ‘diag’
option dns ‘www.turris.cz’
option ping ‘www.turris.cz’
option route ‘www.turris.cz’
Also LXC config should be converted to new LXC version
Adjust bold sections to Your needs.
lxc.arch = armv7l
lxc.tty.max = 4
lxc.pty.max = 1024
lxc.include = /usr/share/lxc/config/common.conf
lxc.hook.start-host = /usr/share/lxc/hooks/systemd-workaround
lxc.rootfs.path = btrfs:/srv/lxc/Debian/rootfs
lxc.uts.name = Debian
lxc.net.0.type = veth
lxc.net.0.link = br-lan
lxc.net.0.flags = up
lxc.net.0.name = eth0
lxc.net.0.ipv4.address = 192.168.9.3/24
lxc.net.0.ipv4.gateway = 192.168.9.1
lxc.net.0.hwaddr = xx:xx:xx:xx:xx:xx
Also, take a look at this post:
Reboot from beta8 to beta9 was succeeded and following via “Maintenance” tab also. Test message did not received.
Still persisting (Omnia with 3.11.6 and MOX with 4.0beta9):
I installed TOS 4.0 beta 9 on my Omnia with NAS perk (using reflash method - 4 LEDs). My previous version was old 3.x, because my filesystem was corrupted and was not writable, so I did not install updates for some time.
I have ADSL O2 connection, my O2 router is acting as a bridge (PPPoE on Omnia).
doc for reflash states that supported filesystems are ext2/3/4, BtrFS, XFS and FAT. It did not work with FAT for me, I had to reformat flash to ext4. After that reflash worked well.
I have problem I have not solved yet:
Foris / WAN / Test connection : IPv4 connectivity and IPv4 gateway connectivity FAILED.
Foris / DNS / Test connection : DNS and DNSSEC FAILED.
But everything seem to work properly, I have functional internet connection. How to debug this?
I have / had several minor problems:
One of my two 2 TB HDDs was not detected at all (nothing in fdisk -l or blkid), I checked the HDDs in my PC (everything OK), than I had to reconnect my HDDs in Omnia several times until both of them were detected. It is OK until then. I had the same HDDs in TOS 3.x., detection was not a problem.
Luci / Services / HDD-Idle only sda was displayed/available, I had to add sdb to config file manually.
Luci / System / LED configuration - There are no sda / sdb / … options in Trigger, how to set one of the LEDs to a disk activity of one particular disk? There are only diskactivity and idedisk triggers (I do not know what is the difference between them, it looks they are doing the same)
Luci / AdBlock is disabled in System / Startup even though it is enabled in Services / AdBlock. I had to enable it manually in startup.
There is a warning in it’s LogFile:
turris updater[29053]: planner.lua:358 (pkg_plan): Requested package luci-i18n-adblock-cs that is missing, ignoring as requested.
How to verify that Adblock is actually doing something?
Is the ISP providing ipv4 only or also ipv6? And if both what are the connection protocols, e.g. dhcp | ds-lite?
From ssh cli what is the output of check_connection?
I asked a similar question today. I have The same problem. I think is a bug in the script. I do not connect via wan interface but via LTE. check_connection asks on the wrong side of the ppp bridge.
It is the same in Turris OS 3.11, i am too using my Omnia with LTE only and i cannot remember the checks working. It would be nice if Foris would be aware of and could setup LTE connections.
you can active the log? By the way, i see you need to install wget , that was missing here.
Yes, my ISP provides also IPv6 but I had it disabled because with IPv6 enabled I could not communicate with my router over OpenVPN. I could connect, but that’s it, even ping was not working. With IPv4 only everything was ok.
In Foris, with IPv4: PPPoE and IPv6: DHCPv6
IPv4 connectivity / gateway FAILED
IPv6 connectivity / gateway OK
DNS and DNSSEC OK
root@turris:~# check_connection
Pinging 10.49.50.254 ... FAILED
IPv4 Gateway: FAILED
IPv4: FAILED
Pinging fe80::a67b:2cff:fea0:3601%pppoe-wan ... OK
IPv6 Gateway: OK
Pinging 2001:1488:0:3::2 ... OK
Pinging 2001:500:3::42 ... OK
Pinging 2001:500:2d::d ... OK
Pinging 2606:2800:220:6d:26bf:1447:1097:aa7 ... OK
IPv6: OK
Resolving api.turris.cz ... OK
Resolving www.nic.cz ... OK
Resolving c.root-servers.net ... OK
DNS: OK
Resolving www.rhybar.cz ... OK
DNSSEC: OK
In Foris with IPv4: PPPoE and IPv6: disabled
IPv4 connectivity / gateway FAILED
DNS and DNSSEC FAILED
root@turris:~# check_connection
Pinging 10.49.50.254 ... FAILED
IPv4 Gateway: FAILED
IPv4: FAILED
IPv6 Gateway: FAILED
IPv6: FAILED
DNS: FAILED
DNSSEC: FAILED
I get a message "WAN port has no link or it hasn't been configured yet. Your internet connection probably won't work.” for a while, then it disappears and everything seems to work…
Suppose that is IP exposed by the LTE modem towards the router and since that ping fails for some reason Foris is showing the error for ipv4 connectivity.
Curiously ipv6 connectivity works however.
I have come across the same with ipv6 via dhcp and ipv4 via ds-lite
I do not have LTE modem, I have ADSL O2 connection, my O2 router is acting as a bridge, my WAN port on Omnia is connected to LAN1 port on O2 router, so I thing this is a standard setup, I did not set anything through Luci or cli.
My bad, got that mixed up with some later post 
The issue is still with the ping to 10.49.50.254 failing
Yesterday, there were only ...turris updater[29053]: planner.lua:358 (pkg_plan): Requested package luci-i18n-adblock-cs that is missing, ignoring as requested. messages in the log.
Today I see new lines
Aug 22 07:25:00 turris adblock-3.5.5-2[30579]: adblock instance started ::: action: start, priority: 0, pid: 30579
Aug 22 07:25:10 turris adblock-3.5.5-2[30579]: blocklist with overall 0 domains loaded successfully (Turris Omnia, TurrisOS 4.0-beta9 9d6cfa2/4.0)
Aug 22 07:25:11 turris adblock-3.5.5-2[31804]: adblock instance started ::: action: start, priority: 0, pid: 31804
Aug 22 07:25:24 turris adblock-3.5.5-2[31804]: blocklist with overall 7002 domains loaded successfully (Turris Omnia, TurrisOS 4.0-beta9 9d6cfa2/4.0)
So I think AdBlock started to work, but I did not change anything except I enabled IPv6 for a while.
I have wget in my system:
root@turris:~# opkg list-installed | grep wget
wget - 1.19.5-1.1
But I do not get why…
root@turris:~# ping 10.49.50.254
PING 10.49.50.254 (10.49.50.254) 56(84) bytes of data.
^C
--- 10.49.50.254 ping statistics ---
235 packets transmitted, 0 received, 100% packet loss, time 243364ms
Ping to other IPs/sites work:
root@turris:~# ping www.google.com
PING www.google.com (172.217.23.196) 56(84) bytes of data.
64 bytes from prg03s05-in-f196.1e100.net (172.217.23.196): icmp_req=1 ttl=56 time=21.5 ms
64 bytes from prg03s05-in-f196.1e100.net (172.217.23.196): icmp_req=2 ttl=56 time=19.2 ms
64 bytes from prg03s05-in-f196.1e100.net (172.217.23.196): icmp_req=3 ttl=56 time=19.2 ms
64 bytes from prg03s05-in-f196.1e100.net (172.217.23.196): icmp_req=4 ttl=56 time=19.7 ms
64 bytes from prg03s05-in-f196.1e100.net (172.217.23.196): icmp_req=5 ttl=56 time=19.9 ms
64 bytes from prg03s05-in-f196.1e100.net (172.217.23.196): icmp_req=6 ttl=56 time=20.3 ms
64 bytes from prg03s05-in-f196.1e100.net (172.217.23.196): icmp_req=7 ttl=56 time=19.6 ms
64 bytes from prg03s05-in-f196.1e100.net (172.217.23.196): icmp_req=8 ttl=56 time=19.4 ms
64 bytes from prg03s05-in-f196.1e100.net (172.217.23.196): icmp_req=9 ttl=56 time=20.7 ms
64 bytes from prg03s05-in-f196.1e100.net (172.217.23.196): icmp_req=10 ttl=56 time=19.0 ms
^C
--- www.google.com ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9013ms
rtt min/avg/max/mdev = 19.097/19.904/21.580/0.747 ms
Could a be firewall issue. To get to the bottom of it it would probably require a tcpdump on the TO and then packet inspection of that dump with a tool like wireshark.
Does the DSL modem (O2 smatbox?) provide a web UI that is accessible via 10.49.50.254?
No, my DSL router is an old Huawei 520i and it had IP 192.168.1.138 or something like this if I remember correctly. Maybe 10.0.0.138, because I set it to factory default before switching it to bridge mode.
But I do not get how it is possible that they are testing IPv4 connectivity on 10.x.x.x IP. IP address range 10.0.0.0 – 10.255.255.255 is private and should not be accesible through internet?!
This is a problem with O2 ISP, having a gateway at 10.x.x.x
Probably because it is in the routing table, what is the output of ip r | grep default?
That is a Link-Local IPv6 Unicast Addresses, sort of similar to an private ipv4 address range. That ping however apparently works
I see! I have the same IP address of my gateway as the IP check_connection is trying to ping.
I am switching to T-M anyway, because they have public IPv4 (O2 has not for new customers / when switching from ADSL to VDSL until you pay for static one), they provide /56 IPv6 (O2 /64).
root@turris:~# ip r | grep default
default via 10.49.50.254 dev pppoe-wan proto static