Turris Build issueshttps://gitlab.nic.cz/turris/os/build/-/issues2022-11-16T17:17:05+01:00https://gitlab.nic.cz/turris/os/build/-/issues/372A3720 CPU random crashes2022-11-16T17:17:05+01:00Simon BorekA3720 CPU random crashesRandom reboots observed at some Mox devices.
This is output from Mox AGFED on Turris OS 6.0 crashing approximately once every 30 minutes after installing most of the available package lists (see the attached reForis Packages screen).
I...Random reboots observed at some Mox devices.
This is output from Mox AGFED on Turris OS 6.0 crashing approximately once every 30 minutes after installing most of the available package lists (see the attached reForis Packages screen).
Intentionally causing full CPU load or frequent switching of CPU multipliers (in between 200 or 500 and 1000 MHz) doesn't seem to trigger these reboots (as opposed to mentioned software operating normally without any other significant load).
```
root@turris:/# [ 1846.232423] Internal error: synchronous parity or ECC error: 96000018 [#1] SMP
[ 1846.239904] Modules linked in: xt_connlimit pppoe ppp_async nf_conncount iptable_nat ath9k xt_state xt_nat xt_helper xt_conntrack xt_connmark xt_connbytes xt_REDIRECT xt_MASQUERADE xt_FLOWOFFLOAD xt_CT pppox ppp_generic nf_natk
[ 1846.240214] ebt_limit ebt_among ebt_802_3 crc_ccitt btusb btmrvl_sdio btmrvl btintel br_netfilter bnep bluetooth ath9k_hw ath10k_pci ath10k_core ath crypto_safexcel sch_tbf sch_ingress sch_htb sch_hfsc em_u32 cls_u32 cls_tcinh
[ 1846.330235] raid456 async_raid6_recov async_pq async_xor async_memcpy async_tx raid10 raid1 raid0 linear md_mod nls_utf8 nls_koi8_r nls_cp1255 nls_iso8859_6 nls_iso8859_2 nls_iso8859_15 nls_iso8859_13 nls_iso8859_1 nls_cp932 r
[ 1846.481740] CPU: 1 PID: 12247 Comm: kworker/1:2 Not tainted 5.15.63 #0
[ 1846.488477] Hardware name: CZ.NIC Turris Mox Board (DT)
[ 1846.493873] Workqueue: 0x0 (events)
[ 1846.497570] pstate: a04000c5 (NzCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 1846.504752] pc : update_curr+0xd4/0x120
[ 1846.508713] lr : update_curr+0xcc/0x120
[ 1846.512668] sp : ffffffc00bd5ba40
[ 1846.516082] x29: ffffffc00bd5ba40 x28: 0000000000000001 x27: 0000000000000000
[ 1846.523449] x26: 0000000000000006 x25: 0000000000000009 x24: 0000000000000000
[ 1846.530815] x23: ffffff803fdbcac0 x22: ffffff8001bf0cc0 x21: 000000000004a380
[ 1846.538181] x20: ffffff803fdbcac0 x19: ffffff8001bf0d80 x18: 00000000506d864d
[ 1846.545548] x17: 000000000e5a0fd8 x16: 000000004f2566db x15: 00000000e625934d
[ 1846.552915] x14: 0000000000000000 x13: 0000000000000030 x12: 0000000000000000
[ 1846.560281] x11: ffffffc008b904b0 x10: ffffff803fdc8668 x9 : ffffff80000f5100
[ 1846.567648] x8 : 0000000000000001 x7 : 0000000000000000 x6 : ffffffc008c78b10
[ 1846.575015] x5 : 0000000000000000 x4 : ffffffc037159000 x3 : 000000154ffb2840
[ 1846.582382] x2 : ffffff80030c2a38 x1 : ffffffc037169000 x0 : ffffff80030c2940
[ 1846.589750] Call trace:
[ 1846.592269] update_curr+0xd4/0x120
[ 1846.595865] dequeue_entity+0x24/0x5c8
[ 1846.599731] dequeue_task_fair+0x8c/0x5f8
[ 1846.603867] deactivate_task+0x50/0x68
[ 1846.607736] load_balance+0x3c4/0x9e8
[ 1846.611513] newidle_balance.isra.156+0x1fc/0x368
[ 1846.616365] pick_next_task_fair+0x48/0x318
[ 1846.620679] __schedule+0x10c/0x660
[ 1846.624279] schedule+0x58/0xc0
[ 1846.627518] worker_thread+0xe4/0x4e0
[ 1846.631296] kthread+0x11c/0x128
[ 1846.634629] ret_from_fork+0x10/0x20
[ 1846.638322] Code: 9401aaf5 9400c840 f942ce60 9103e002 (b9415801)
[ 1846.644609] ---[ end trace 9929ad1c16fffc48 ]---
[ 1846.649369] Kernel panic - not syncing: synchronous parity or ECC error: Fatal exception
[ 1846.657713] SMP: stopping secondary CPUs
[ 1847.701754] SMP: failed to stop secondary CPUs 0-1
[ 1847.706695] Kernel Offset: disabled
[ 1847.710287] CPU features: 0x00000000,20000802
[ 1847.714779] Memory Limit: none
[ 1847.717926] Rebooting in 3 seconds..
[ 1850.721756] SMP: stopping secondary CPUs
[ 1851.765797] SMP: failed to stop secondary CPUs 0-1
```
Another crash output:
```
[ 1416.417978] Internal error: synchronous parity or ECC error: 86000018 [#1] SMP
[ 1416.425459] Modules linked in: xt_connlimit pppoe ppp_async nf_conncount iptable_nat ath9k xt_state xt_nat xt_helper xt_conntrack xt_connmark xt_connbytes xt_REDIRECT xt_MASQUERADE xt_FLOWOFFLOAD xt_CT pppox ppp_generic nf_natk
[ 1416.425778] ebt_limit ebt_among ebt_802_3 crc_ccitt btusb btmrvl_sdio btmrvl btintel br_netfilter bnep bluetooth ath9k_hw ath10k_pci ath10k_core ath crypto_safexcel sch_tbf sch_ingress sch_htb sch_hfsc em_u32 cls_u32 cls_tcin4
[ 1416.515802] dns_resolver multipath raid456 async_raid6_recov async_pq async_xor async_memcpy async_tx raid10 raid1 raid0 linear md_mod nls_utf8 nls_koi8_r nls_cp1255 nls_iso8859_6 nls_iso8859_2 nls_iso8859_15 nls_iso8859_13 nr
[ 1416.668843] CPU: 0 PID: 11 Comm: ksoftirqd/0 Not tainted 5.15.64 #0
[ 1416.675310] Hardware name: CZ.NIC Turris Mox Board (DT)
[ 1416.680698] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 1416.687880] pc : ath10k_htt_rx_pktlog_completion_handler+0x1048/0x2e88 [ath10k_core]
[ 1416.695897] lr : ath10k_htt_txrx_compl_task+0x68/0x1158 [ath10k_core]
[ 1416.702554] sp : ffffffc008e7ba80
[ 1416.705967] x29: ffffffc008e7ba80 x28: ffffff8004de27c0 x27: ffffffc008c86000
[ 1416.713335] x26: ffffffc008b91cb0 x25: 000000010001b40f x24: ffffffc037149000
[ 1416.720701] x23: ffffff8004de3cb8 x22: 0000000000000040 x21: 0000000000000040
[ 1416.728068] x20: 0000000000000000 x19: 0000000000000040 x18: 0000000000000000
[ 1416.735433] x17: 0000000000000000 x16: 0000000000000000 x15: fffa33d179b00cbf
[ 1416.742800] x14: 4000000000800001 x13: 01c72e2e2e0204c3 x12: 0000000000000000
[ 1416.750166] x11: ffffffc008b91cb0 x10: ffffff803fdb8668 x9 : ffffffc008f7de78
[ 1416.757533] x8 : 00000000000014f8 x7 : 0000000000000000 x6 : 0000000000000000
[ 1416.764898] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000
[ 1416.772263] x2 : 0000000000000040 x1 : 00000000000016c0 x0 : ffffff8004de3e80
[ 1416.779631] Call trace:
[ 1416.782149] ath10k_htt_rx_pktlog_completion_handler+0x1048/0x2e88 [ath10k_core]
[ 1416.789792] ath10k_htt_txrx_compl_task+0x68/0x1158 [ath10k_core]
[ 1416.796090] ath10k_pci_enable_legacy_irq+0xc8/0x280 [ath10k_pci]
[ 1416.802381] __napi_poll+0x34/0x1a8
[ 1416.805987] net_rx_action+0xf8/0x248
[ 1416.809764] _stext+0x11c/0x278
[ 1416.813003] run_ksoftirqd+0x4c/0x60
[ 1416.816693] smpboot_thread_fn+0x144/0x188
[ 1416.820923] kthread+0x11c/0x128
[ 1416.824256] ret_from_fork+0x10/0x20
[ 1416.827949] Code: 95cc4518 17ffffd6 a9425bf5 a94363f7 (2a1403e0)
[ 1416.834235] ---[ end trace 34c6ab41c8a37133 ]---
[ 1416.838996] Kernel panic - not syncing: synchronous parity or ECC error: Fatal exception in interrupt
[ 1416.848505] SMP: stopping secondary CPUs
[ 1417.892545] SMP: failed to stop secondary CPUs 0-1
[ 1417.897487] Kernel Offset: disabled
[ 1417.901079] CPU features: 0x00000000,20000802
[ 1417.905570] Memory Limit: none
[ 1417.908718] Rebooting in 3 seconds..
[ 1420.912549] SMP: stopping secondary CPUs
[ 1421.956589] SMP: failed to stop secondary CPUs 0-1
```
![Screenshot_2022-09-21_at_14-48-46_Packages_-_reForis_Turris](/uploads/2767b95ad726ed428fc5812e67acff4c/Screenshot_2022-09-21_at_14-48-46_Packages_-_reForis_Turris.png)Turris OS 6.0.3https://gitlab.nic.cz/turris/os/build/-/issues/371Turris 1.x boot extremely slow with linux 5.15 - prevents some services (ligh...2024-02-05T14:09:30+01:00Simon BorekTurris 1.x boot extremely slow with linux 5.15 - prevents some services (lighttpd, ...) from starting up automaticallyBased on several different observations after upgrade to linux 5.15 it may take Turris 1.x 5-10 or even 20+ minutes to reach the "Router Turris successfully started." moment from powered off state.
This leads to some services (lighttpd, ...Based on several different observations after upgrade to linux 5.15 it may take Turris 1.x 5-10 or even 20+ minutes to reach the "Router Turris successfully started." moment from powered off state.
This leads to some services (lighttpd, syslog-ng, foris-controller, ... ?) being unable to start automatically during boot.
From my observations, it seemed ssh access from local network becomes possible not very long after plugging the router in, but there is a huge time window succeeding in which interfaces reset slowly one after another and only then it becomes possible to access internet from the network (networking was OK afterwards, even without any manual intervention; this, unfortunately, didn't apply to reForis and others).
It would be useful to publish concrete outputs from Turris 1.x startup in this issue discussion.
CC @jschlehofer @mbehunTurris OS 7.0https://gitlab.nic.cz/turris/os/build/-/issues/370Missing Kernelmodules for ipvsadm2022-09-04T13:24:59+02:00Christian FelsingMissing Kernelmodules for ipvsadmipvsadm is a userful tool to resolve many load balancing problems. opkg offers ipvsadm, but there are missing kernel dependencies. Steps to reproduce:
```
root@turris:~# opkg install ipvsadm
Installing ipvsadm (1.29-1) to root...
Downloa...ipvsadm is a userful tool to resolve many load balancing problems. opkg offers ipvsadm, but there are missing kernel dependencies. Steps to reproduce:
```
root@turris:~# opkg install ipvsadm
Installing ipvsadm (1.29-1) to root...
Downloading https://repo.turris.cz/hbs/omnia/packages/packages/ipvsadm_1.29-1_arm_cortex-a9_vfpv3-d16.ipk
Upgrading kernel on root from 4.14.290-1-e7efbb661dce3f3c72ad7afb470f9103 to 4.14.291-1-e7efbb661dce3f3c72ad7afb470f9103...
Downloading https://repo.turris.cz/hbs/omnia/packages/core/kernel_4.14.291-1-e7efbb661dce3f3c72ad7afb470f9103_arm_cortex-a9_vfpv3-d16.ipk
Installing kmod-crypto-hash (4.14.291-1-e7efbb661dce3f3c72ad7afb470f9103) to root...
Downloading https://repo.turris.cz/hbs/omnia/packages/core/kmod-crypto-hash_4.14.291-1-e7efbb661dce3f3c72ad7afb470f9103_arm_cortex-a9_vfpv3-d16.ipk
Installing kmod-crypto-crc32c (4.14.291-1-e7efbb661dce3f3c72ad7afb470f9103) to root...
Downloading https://repo.turris.cz/hbs/omnia/packages/core/kmod-crypto-crc32c_4.14.291-1-e7efbb661dce3f3c72ad7afb470f9103_arm_cortex-a9_vfpv3-d16.ipk
Installing kmod-lib-crc32c (4.14.291-1-e7efbb661dce3f3c72ad7afb470f9103) to root...
Downloading https://repo.turris.cz/hbs/omnia/packages/core/kmod-lib-crc32c_4.14.291-1-e7efbb661dce3f3c72ad7afb470f9103_arm_cortex-a9_vfpv3-d16.ipk
Installing kmod-nf-ipvs (4.14.291-1-e7efbb661dce3f3c72ad7afb470f9103) to root...
Downloading https://repo.turris.cz/hbs/omnia/packages/core/kmod-nf-ipvs_4.14.291-1-e7efbb661dce3f3c72ad7afb470f9103_arm_cortex-a9_vfpv3-d16.ipk
Configuring kernel.
Configuring kmod-crypto-hash.
Configuring kmod-crypto-crc32c.
Configuring kmod-lib-crc32c.
Configuring kmod-nf-ipvs.
Configuring ipvsadm.
```
Expected behaviour: After issuing "ipvsadm --list" at least an empty list should appear.
What happens:
```
failed to find dependency nf_defrag_ipv6
failed to find dependency nf_conntrack
1 module could not be probed
- ip_vs
Can't initialize ipvs: Protocol not available
Are you sure that IP Virtual Server is built in the kernel or as module?
```
Product:
```
System
Hostname turris
Model Turris Omnia
Architecture ARMv7 Processor rev 1 (v7l)
Firmware Version TurrisOS 5.4.1 83b0e20711ee4a927634b3c2a018c93527e84a2b / LuCI branch git-22.115.68448-712bc8e
Kernel Version 4.14.291
Local Time 2022-09-04 10:42:46
Uptime 0h 11m 33s
Load Average 0.03, 0.08, 0.08
```Turris OS 6.0https://gitlab.nic.cz/turris/os/build/-/issues/368Unable to detect USB 3.0 SSD in MOX A USB port2022-09-04T20:07:42+02:00Jakub KákonaUnable to detect USB 3.0 SSD in MOX A USB portAs suggested in https://gitlab.nic.cz/turris/os/build/-/issues/366#note_260604 I upgraded the Turris OS HBL. But then I am unable to detect USB 3.0 connected to MOX A module. (In case of connection to MOX F SSD works corretly)
Before u...As suggested in https://gitlab.nic.cz/turris/os/build/-/issues/366#note_260604 I upgraded the Turris OS HBL. But then I am unable to detect USB 3.0 connected to MOX A module. (In case of connection to MOX F SSD works corretly)
Before upgrade:
```
BusyBox v1.33.2 (2022-02-07 08:09:38 UTC) built-in shell (ash)
______ _ ____ _____
/_ __/_ ____________(_)____ / __ \/ ___/
/ / / / / / ___/ ___/ / ___/ / / / /\__
/ / / /_/ / / / / / (__ ) / /_/ /___/ /
/_/ \__,_/_/ /_/ /_/____/ \____//____/
-----------------------------------------------------
TurrisOS 6.0, Turris Mox
-----------------------------------------------------
root@mox:~# lsusb
Bus 004 Device 006: ID 1546:01a8 u-blox AG - www.u-blox.com u-blox GNSS receiver
Bus 003 Device 002: ID 0781:558c SanDisk Extreme SSD
Bus 002 Device 001: ID 1d6b:0002 Linux 5.4.203 xhci-hcd xHCI Host Controller
Bus 001 Device 002: ID 0424:2422
Bus 004 Device 005: ID 0403:6001 FTDI FT232R USB UART
Bus 004 Device 007: ID 1546:01a8 u-blox AG - www.u-blox.com u-blox GNSS receiver
Bus 004 Device 008: ID 1546:01a8 u-blox AG - www.u-blox.com u-blox GNSS receiver
Bus 001 Device 001: ID 1d6b:0002 Linux 5.4.203 ehci_hcd EHCI Host Controller
Bus 005 Device 002: ID 0bda:0411 Generic 4-Port USB 3.0 Hub
Bus 003 Device 001: ID 1d6b:0003 Linux 5.4.203 xhci-hcd xHCI Host Controller
Bus 004 Device 003: ID fffe:0007 SDR-Widget Yoyodyne SDR-Widget
Bus 005 Device 001: ID 1d6b:0003 Linux 5.4.203 xhci-hcd xHCI Host Controller
Bus 004 Device 004: ID 0bda:5411 Generic 4-Port USB 2.0 Hub
Bus 004 Device 002: ID 2109:3431 USB2.0 Hub
Bus 004 Device 001: ID 1d6b:0002 Linux 5.4.203 xhci-hcd xHCI Host Controller
root@mox:~# dmesg | grep 0781:558c
root@mox:~# dmesg | grep sandisk
root@mox:~#
```
After upgrade:
```
BusyBox v1.33.2 (2022-02-07 08:09:38 UTC) built-in shell (ash)
______ _ ____ _____
/_ __/_ ____________(_)____ / __ \/ ___/
/ / / / / / ___/ ___/ / ___/ / / / /\__
/ / / /_/ / / / / / (__ ) / /_/ /___/ /
/_/ \__,_/_/ /_/ /_/____/ \____//____/
-----------------------------------------------------
TurrisOS 6.0-alpha2, Turris Mox
-----------------------------------------------------
root@mox:~# lsusb
Bus 004 Device 006: ID 1546:01a8 u-blox AG - www.u-blox.com u-blox GNSS receiver
Bus 002 Device 001: ID 1d6b:0002 Linux 5.15.63 xhci-hcd xHCI Host Controller
Bus 001 Device 002: ID 0424:2422
Bus 004 Device 005: ID 0403:6001 FTDI FT232R USB UART
Bus 004 Device 007: ID 1546:01a8 u-blox AG - www.u-blox.com u-blox GNSS receiver
Bus 004 Device 008: ID 1546:01a8 u-blox AG - www.u-blox.com u-blox GNSS receiver
Bus 001 Device 001: ID 1d6b:0002 Linux 5.15.63 ehci_hcd EHCI Host Controller
Bus 005 Device 002: ID 0bda:0411 Generic 4-Port USB 3.0 Hub
Bus 003 Device 001: ID 1d6b:0003 Linux 5.15.63 xhci-hcd xHCI Host Controller
Bus 004 Device 003: ID fffe:0007 SDR-Widget Yoyodyne SDR-Widget
Bus 005 Device 001: ID 1d6b:0003 Linux 5.15.63 xhci-hcd xHCI Host Controller
Bus 004 Device 004: ID 0bda:5411 Generic 4-Port USB 2.0 Hub
Bus 004 Device 002: ID 2109:3431 USB2.0 Hub
Bus 004 Device 001: ID 1d6b:0002 Linux 5.15.63 xhci-hcd xHCI Host Controller
root@mox:~# dmesg | grep 0781:558c
root@mox:~# dmesg | grep sandisk
root@mox:~#
```Marcela BlazkovaMarcela Blazkovahttps://gitlab.nic.cz/turris/os/build/-/issues/367TOS 5 -> 6 update might break guest network2023-08-16T10:55:02+02:00Simon BorekTOS 5 -> 6 update might break guest networkswitch-branch from HBS 5.x with guest Wi-Fi set up to HBK 6.0 might omit `guest_turris` fw zone rename to `tr_guest` leading to unapplicable `guest_turris` zone related firewall rules.
The rename should be arranged automatically by [fir...switch-branch from HBS 5.x with guest Wi-Fi set up to HBK 6.0 might omit `guest_turris` fw zone rename to `tr_guest` leading to unapplicable `guest_turris` zone related firewall rules.
The rename should be arranged automatically by [firewall-zone-limit script](https://gitlab.nic.cz/turris/os/packages/-/blob/3c4ffcbe96c6326d8ba1d4dd4560901506d9aecb/updater/fix/files/firewall-zone-limit) (related to https://gitlab.nic.cz/turris/foris-controller/foris-controller/-/merge_requests/97).
Happened on Omnia with several custom bridges and related zones FW rules set up through luci. Was possible to fix by running [firewall-zone-limit script](https://gitlab.nic.cz/turris/os/packages/-/blob/3c4ffcbe96c6326d8ba1d4dd4560901506d9aecb/updater/fix/files/firewall-zone-limit) manually.
I wasn't able to reproduce this on another Omnia with HBK and just basic configuration (the `guest_turris` zone was renamed properly to `tr_guest` during the update).
## How to reproduce
* setup guest WiFi through reforis in TOS 5
* check the guest firewall zone is named `guest_turris`
* upgrade (switch-branch) to TOS 6
* (optionally apply not yet merged network migration script from https://gitlab.nic.cz/turris/os/packages/-/merge_requests/956#diff-content-f71557e04826e3070b0d3b1543ee036c6a1b1cc5)
* unless `guest_turris` zone has been renamed to `tr_guest` the guest network now cannot access internet but can access the router web interface (should behave the other way around) and firewall outputs `Warning: Section 'guest_turris' must not have a name longer than 11 characters` on manual restart (`/etc/init.d/firewall restart`)
@jhoracek @mmatejek @jschlehoferTurris OS 6.0https://gitlab.nic.cz/turris/os/build/-/issues/366port 1(eth0) entered disabled state2023-08-16T10:59:42+02:00Jakub Kákonaport 1(eth0) entered disabled stateSometimes after startup the eth0 port on MOX A entered to disabled state. Therefore devices connected to this Ethernet port are inaccessible from MOX. Restarting the interface from LuCI cycles the situation. Like follows
```
root@mox:~...Sometimes after startup the eth0 port on MOX A entered to disabled state. Therefore devices connected to this Ethernet port are inaccessible from MOX. Restarting the interface from LuCI cycles the situation. Like follows
```
root@mox:~# dmesg | grep eth0
[ 0.994640] mvneta d0030000.ethernet eth0: Using device tree mac address d8:58:d7:00:be:52
[ 18.730223] mvneta d0030000.ethernet eth0: could not attach PHY: -19
[ 18.736874] mvneta d0030000.ethernet eth0: cannot probe MDIO bus
[ 18.751808] br-lan: port 1(eth0) entered blocking state
[ 18.757278] br-lan: port 1(eth0) entered disabled state
[ 18.762927] device eth0 entered promiscuous mode
[ 31.635970] eth0: renamed from vethMnEpW7
[ 31.668604] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[ 120.824714] device eth0 left promiscuous mode
[ 120.829356] br-lan: port 1(eth0) entered disabled state
[ 121.090721] mvneta d0030000.ethernet eth0: could not attach PHY: -19
[ 121.097449] mvneta d0030000.ethernet eth0: cannot probe MDIO bus
[ 121.112664] br-lan: port 1(eth0) entered blocking state
[ 121.118335] br-lan: port 1(eth0) entered disabled state
[ 121.124090] device eth0 entered promiscuous mode
[ 166.612228] device eth0 left promiscuous mode
[ 166.617040] br-lan: port 1(eth0) entered disabled state
[ 166.858386] mvneta d0030000.ethernet eth0: could not attach PHY: -19
[ 166.865209] mvneta d0030000.ethernet eth0: cannot probe MDIO bus
[ 166.888479] br-lan: port 1(eth0) entered blocking state
[ 166.894172] br-lan: port 1(eth0) entered disabled state
[ 166.900208] device eth0 entered promiscuous mode
[ 271.305570] mvneta d0030000.ethernet eth0: could not attach PHY: -19
[ 271.312229] mvneta d0030000.ethernet eth0: cannot probe MDIO bus
[ 274.952724] mvneta d0030000.ethernet eth0: could not attach PHY: -19
[ 274.959310] mvneta d0030000.ethernet eth0: cannot probe MDIO bus
[ 371.284440] device eth0 left promiscuous mode
[ 371.289088] br-lan: port 1(eth0) entered disabled state
[ 371.480782] mvneta d0030000.ethernet eth0: could not attach PHY: -19
[ 371.487445] mvneta d0030000.ethernet eth0: cannot probe MDIO bus
[ 371.500875] br-lan: port 1(eth0) entered blocking state
[ 371.506416] br-lan: port 1(eth0) entered disabled state
[ 371.512146] device eth0 entered promiscuous mode
```
```
root@mox:~# uname -a
Linux mox 5.4.203 #0 SMP Thu Jul 14 09:49:11 2022 aarch64 GNU/Linux
```
[Diagnostics from working state](/uploads/df320930151ec738f9027b4847db847a/2022-08-31-12-48-17_c6ec30b1.txt.gz)
[Diagnostics from broken situation](/uploads/2dc26b1edab136ef6f8966ec79bb6eb3/2022-08-31-13-48-02_3b7dac13.txt.gz)https://gitlab.nic.cz/turris/os/build/-/issues/362Turris SFP+ not working on kernel 5.152022-09-27T17:38:55+02:00Hristo VenevTurris SFP+ not working on kernel 5.15It appears that Turris SFP+ does not get set up correctly in HBL (Turris OS 6.0) on Turris Omnia:
```
[ 7.947564] sfp sfp: Host maximum power 3.0W
[ 8.277850] sfp sfp: module Turris RTSFP-10G rev A sn 210915023...It appears that Turris SFP+ does not get set up correctly in HBL (Turris OS 6.0) on Turris Omnia:
```
[ 7.947564] sfp sfp: Host maximum power 3.0W
[ 8.277850] sfp sfp: module Turris RTSFP-10G rev A sn 2109150236 dc 210915
[ 12.329759] mvneta f1034000.ethernet eth2: configuring for inband/sgmii link mode
[ 14.177653] sfp sfp: no PHY detected
[ 14.181290] mvneta f1034000.ethernet eth2: validation with support 0000000,00000000,000020c0 failed: -22
```
```
# uname -a
Linux omnia 5.15.59 #0 SMP Thu Aug 11 11:58:26 2022 armv7l GNU/Linux
```
```
# ethtool --module-info eth2
Identifier : 0x03 (SFP)
Extended identifier : 0x04 (GBIC/SFP defined by 2-wire interface ID)
Connector : 0x22 (RJ45)
Transceiver codes : 0x10 0x00 0x00 0x00 0x00 0x08 0x00 0x00 0x16
Transceiver type : 10G Ethernet: 10G Base-SR
Transceiver type : Active Cable
Transceiver type : Extended: 10Gbase-T with SFI electrical interface
Encoding : 0x06 (64B/66B)
BR, Nominal : 10300MBd
Rate identifier : 0x00 (unspecified)
Length (SMF,km) : 0km
Length (SMF) : 0m
Length (50um) : 80m
Length (62.5um) : 30m
Length (Copper) : 0m
Length (OM3) : 300m
Active Cu cmplnce. : 0x03 (unknown) [SFF-8472 rev10.4 only]
Vendor name : Turris
Vendor OUI : 00:90:65
Vendor PN : RTSFP-10G
Vendor rev : A
Option values : 0x00 0x1a
Option : RX_LOS implemented
Option : TX_FAULT implemented
Option : TX_DISABLE implemented
BR margin, max : 0%
BR margin, min : 0%
Vendor SN : 2109150236
Date code : 210915
Optical diagnostics support : Yes
...
```Turris OS 6.0Marek BehunMarek Behunhttps://gitlab.nic.cz/turris/os/build/-/issues/361Please fix UNICODE / wide character support in terminal2022-08-15T14:01:27+02:00Ghost UserPlease fix UNICODE / wide character support in terminalLocal terminal over UART and also remote terminal over SSH on all Turris routers stop working after sending some UTF-8 character. SSH shell is completely ignoring LC locale settings for UTF-8 support and treats every send byte separately...Local terminal over UART and also remote terminal over SSH on all Turris routers stop working after sending some UTF-8 character. SSH shell is completely ignoring LC locale settings for UTF-8 support and treats every send byte separately, ignoring UNICODE or wide character settings. This makes terminals unusable on modern systems.
Simple reproducer: Type `echo á` then press backspace and then press enter. It should not write anything on the terminal. But currently it prints back garbage `�`.Turris OS 5.4.1https://gitlab.nic.cz/turris/os/build/-/issues/360Current HBL branch misses sysfs path2023-08-16T10:59:47+02:00Filip HronCurrent HBL branch misses sysfs pathRouter unable to generate password (``/etc/sentinel/mailpass``) on version ``5.15.59`` due to error in ``mox-otp``
```
sentinel-certgen mailpass
sysfs API error: Could not find MOX sign file
crypto-wrapper: error: Failed to run command ...Router unable to generate password (``/etc/sentinel/mailpass``) on version ``5.15.59`` due to error in ``mox-otp``
```
sentinel-certgen mailpass
sysfs API error: Could not find MOX sign file
crypto-wrapper: error: Failed to run command 'mox-otp sign /tmp/crypto_wrapper_root/temp_fciNlC'
[2022-08-10 14:35:14] ERROR [certgen.process_auth:250] Auth error: Server responded with message: Bad signature format:
[2022-08-10 14:35:14] WARNING [certgen.start:335] Sleeping for 12 seconds before retry (try number 2)
sysfs API error: Could not find MOX sign file
crypto-wrapper: error: Failed to run command 'mox-otp sign /tmp/crypto_wrapper_root/temp_EekBHb'
[2022-08-10 14:35:27] ERROR [certgen.process_auth:250] Auth error: Server responded with message: Bad signature format:
[2022-08-10 14:35:27] WARNING [certgen.start:335] Sleeping for 12 seconds before retry (try number 3)
[2022-08-10 14:35:39] ERROR [certgen.process_get:204] Get fail: Server responded with message: You hit the rate limit
[2022-08-10 14:35:39] ERROR [certgen.start:330] Max tries (3) have been reached, exiting
```
However, the ``mox-otp`` is merely pointing to missing path in ``sysfs``
```
foot@turris:/ uname -a
Linux turris 5.15.59 #0 SMP Tue Aug 9 23:38:13 2022 aarch64 GNU/Linux
root@turris:/sys/firmware/turris-mox-rwtm# [ -f /sys/firmware/turris-mox-rwtm/mox_do_sign ] ; echo $?
1
```
Found by @jhoracek
cheersTurris OS 6.0https://gitlab.nic.cz/turris/os/build/-/issues/359MOX: no RTC on kernel 5.152022-08-08T13:45:15+02:00Ondřej CaletkaMOX: no RTC on kernel 5.15With current hbl kernel 5.15.59, there is no access to the Real Time Clock:
```
# ls /dev/rtc*
ls: /dev/rtc*: No such file or directory
# ls /sys/bus/i2c/devices/
#
```
**Possibly related:**
The time jump during boot probably triggers ...With current hbl kernel 5.15.59, there is no access to the Real Time Clock:
```
# ls /dev/rtc*
ls: /dev/rtc*: No such file or directory
# ls /sys/bus/i2c/devices/
#
```
**Possibly related:**
The time jump during boot probably triggers some bug in lighttpd, that break TLS capability. Restarting lighttpd works around this issue.
```
# cat /var/log/lighttpd/error.log
2022-08-04 18:27:45: (../src/server.c.1588) server started (lighttpd/1.4.65)
2022-08-04 18:27:54: (../src/server.c.267) warning: clock jumped 3570 secs
2022-08-04 18:27:54: (../src/server.c.275) attempting graceful restart in < ~5 seconds, else hard restart
2022-08-04 19:27:24: (../src/server.c.1019) [note] graceful shutdown started
2022-08-04 19:27:24: (../src/server.c.2097) server stopped by UID = 0 PID = 4432
2022-08-04 19:27:24: (../src/server.c.1588) server started (lighttpd/1.4.65)
2022-08-04 19:27:28: (../src/connections.c.716) unexpected TLS ClientHello on clear port (2001:db8::fe5)
```
From computer:
```
# curl https://turris.example/ -v
* Trying 2001:db8::1:443...
* Connected to … port 443 (#0)
* ALPN: offers h2
* ALPN: offers http/1.1
* CAfile: /etc/ssl/certs/ca-certificates.crt
* CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* error:1408F10B:SSL routines:ssl3_get_record:wrong version number
* Closing connection 0
curl: (35) error:1408F10B:SSL routines:ssl3_get_record:wrong version number
```Turris OS 6.0https://gitlab.nic.cz/turris/os/build/-/issues/358HBK: Confusing unavailable packages from stable OpenWRT2022-10-21T11:20:51+02:00Sviatoslav SydorenkoHBK: Confusing unavailable packages from stable OpenWRTHello, I'm running HBK and according to https://docs.turris.cz/geek/testing/#hbk-here-be-kittens it's supposed to be based on the stable OpenWRT version which seems to be [21.02 as of today](https://openwrt.org/releases/start).
With that...Hello, I'm running HBK and according to https://docs.turris.cz/geek/testing/#hbk-here-be-kittens it's supposed to be based on the stable OpenWRT version which seems to be [21.02 as of today](https://openwrt.org/releases/start).
With that in mind, I wanted to install the DAWN package available in that release — https://downloads.openwrt.org/releases/21.02.1/packages/arm_cortex-a9_vfpv3-d16/packages/dawn_2022-07-24-9e8060ea-1_arm_cortex-a9_vfpv3-d16.ipk. Yet, to my surprise, this failed because it's not available in the repositories that Turris has on board.
I even tried installing by pointing at this specific file and faced a number of missing dependency issues.
I've gone digging and saw that LUCI has the following in the footer
```console
Powered by LuCI branch (git-22.115.68448-712bc8e) / TurrisOS 5.3.11 83b0e20711ee4a927634b3c2a018c93527e84a2b r11431+99-83b0e20711
```
which sorta suggests that the version might be even 22 but it doesn't make sense to me.
I've been unable to see the exact OpenWRT version that the system is based on, on the file system. `cat /etc/os-release` and similar methods turned out to be useless as it seems like only Turis' own version is exposed there :(
Then, I've found this repository (along with neigboring ones) and figured — maybe I'd be able to contribute something to make it work? But I don't see the process for exposing packages documented.
I've finally noticed that https://gitlab.nic.cz/turris/os/build/-/blob/hbk/feeds.conf is pointing at `19.07` and then looked at https://gitlab.nic.cz/turris/os/build/-/blob/hbl/feeds.conf where I saw `21.02`.
My question is whether it's expected and if so, maybe the docs need to be updated to include the exact version of the compatible OpenWRT package repositories? Another suggestion would be somehow exposing what the underlying OpenWRT version is so that folks like me would be able to understand what to expect in terms of upstream package compatibility?
Do you have any recommendation for me of how to install DAWN? I'm not sure I'd want to switch to HBL just yet. I was considering rebuilding https://github.com/openwrt/packages/blob/master/net/dawn but I don't know how to properly target the OS I've got and not the upstream OpenWRT version — any pointers?https://gitlab.nic.cz/turris/os/build/-/issues/357/dev/stdin, stdout and stderr are missing on Turris OS2022-07-31T20:23:27+02:00Ghost User/dev/stdin, stdout and stderr are missing on Turris OS/dev/stdin, /dev/stdout and /dev/stderr are needed by more scripts and these scripts fail to run on Turris OS because these files are missing.
/dev/stdin should be symlink to /proc/self/fd/0, /dev/stdout to /proc/self/fd/1 and /dev/stde.../dev/stdin, /dev/stdout and /dev/stderr are needed by more scripts and these scripts fail to run on Turris OS because these files are missing.
/dev/stdin should be symlink to /proc/self/fd/0, /dev/stdout to /proc/self/fd/1 and /dev/stderr to /proc/self/fd/2
Please create these symlinks on Turris OS.https://gitlab.nic.cz/turris/os/build/-/issues/354HBL: kernel 5.15: LEDs on Turris Omnia not supported2022-08-30T07:13:36+02:00Ondřej CaletkaHBL: kernel 5.15: LEDs on Turris Omnia not supportedAfter upgrade of the kernel from version 5.4.203-1-da0ddeb89bb0e25d2a575f62263f6300 to version 5.15.50-1-bbde583666f0d21706f8da40fd4a8532, LEDs stopped working on Omnia. It seems that the driver is missing:
```
# ls /sys/class/leds/
ath...After upgrade of the kernel from version 5.4.203-1-da0ddeb89bb0e25d2a575f62263f6300 to version 5.15.50-1-bbde583666f0d21706f8da40fd4a8532, LEDs stopped working on Omnia. It seems that the driver is missing:
```
# ls /sys/class/leds/
ath10k-phy0 ath9k-phy1 mmc0::
# rainbow all enable
Failed to open file: No such file or directory
```
Reverting to previous kernel fixes the issue.Turris OS 6.0https://gitlab.nic.cz/turris/os/build/-/issues/352Mosh is not compiled due to protoc2022-06-27T12:24:45+02:00Josef SchlehoferMosh is not compiled due to protocHappens on all routers. Error log from Jenkins:
```
checking for arm-openwrt-linux-ranlib... arm-openwrt-linux-muslgnueabi-gcc-ranlib
checking for protoc... no
configure: error: cannot find protoc, the Protocol Buffers compiler
make[2]: ...Happens on all routers. Error log from Jenkins:
```
checking for arm-openwrt-linux-ranlib... arm-openwrt-linux-muslgnueabi-gcc-ranlib
checking for protoc... no
configure: error: cannot find protoc, the Protocol Buffers compiler
make[2]: *** [Makefile:119: /omnia/build/build_dir/target-arm_cortex-a9+vfpv3-d16_musl_eabi/mosh-1.3.2/.configured_68b329da9893e34099c7d8ad5cb9c940] Error 1
```
Reported by @oskar on InstallFest conferenceTurris OS 6.0https://gitlab.nic.cz/turris/os/build/-/issues/351Knot Resolver is missing dependency proto-c for dnstap2023-08-16T10:55:36+02:00Josef SchlehoferKnot Resolver is missing dependency proto-c for dnstapI prepared a clean build environment and I tried to compile Knot Resolver for Turris MOX in HBL branch and it fails with the following output:
```
Program protoc-c found: NO
../../../../build_dir/target-aarch64_cortex-a53_musl/knot-res...I prepared a clean build environment and I tried to compile Knot Resolver for Turris MOX in HBL branch and it fails with the following output:
```
Program protoc-c found: NO
../../../../build_dir/target-aarch64_cortex-a53_musl/knot-resolver-5.5.0/modules/dnstap/meson.build:15:2: ERROR: Program 'protoc-c' not found
```Turris OS 6.0https://gitlab.nic.cz/turris/os/build/-/issues/349WAN is configured on different port2023-08-16T10:55:10+02:00Josef SchlehoferWAN is configured on different portWith a new Device Tree on Turris 1.x routers, there was enabled additional Ethernet port to use multiDSA. Unfortunately, this breaks installation by using medkit.
Interface ``wan`` was configured on eth1, but I got working it on ``eth2`...With a new Device Tree on Turris 1.x routers, there was enabled additional Ethernet port to use multiDSA. Unfortunately, this breaks installation by using medkit.
Interface ``wan`` was configured on eth1, but I got working it on ``eth2``.
Please investigate this further and fix this.Turris OS 6.02022-08-16https://gitlab.nic.cz/turris/os/build/-/issues/348MOX: Enable earlyprintk for easier UART debugging2022-07-27T13:51:46+02:00Josef SchlehoferMOX: Enable earlyprintk for easier UART debuggingSimilar as for Turris Omnia (turris/os/build#347), we need similar stuff for Turris MOX:
```
CONFIG_CMDLINE="earlycon=ar3700_uart,0xd0012000 console=ttyMV0,115200"
CONFIG_CMDLINE_FROM_BOOTLOADER=y
CONFIG_SERIAL_EARLYCON=y
CONFIG_SERIAL_...Similar as for Turris Omnia (turris/os/build#347), we need similar stuff for Turris MOX:
```
CONFIG_CMDLINE="earlycon=ar3700_uart,0xd0012000 console=ttyMV0,115200"
CONFIG_CMDLINE_FROM_BOOTLOADER=y
CONFIG_SERIAL_EARLYCON=y
CONFIG_SERIAL_MVEBU_UART=y
CONFIG_SERIAL_MVEBU_CONSOLE=y
```Turris OS 6.0https://gitlab.nic.cz/turris/os/build/-/issues/347Omnia: Enable earlyprintk for easier UART debugging2023-08-16T10:55:24+02:00Josef SchlehoferOmnia: Enable earlyprintk for easier UART debuggingIt was requested and provided by @prohar to set these kernel options:
```
CONFIG_CMDLINE="earlyprintk console=ttyS0,115200"
CONFIG_CMDLINE_FROM_BOOTLOADER=y
CONFIG_DEBUG_LL=y
CONFIG_DEBUG_MVEBU_UART0_ALTERNATE=y
CONFIG_DEBUG_UNCOMPRESS=...It was requested and provided by @prohar to set these kernel options:
```
CONFIG_CMDLINE="earlyprintk console=ttyS0,115200"
CONFIG_CMDLINE_FROM_BOOTLOADER=y
CONFIG_DEBUG_LL=y
CONFIG_DEBUG_MVEBU_UART0_ALTERNATE=y
CONFIG_DEBUG_UNCOMPRESS=y
CONFIG_EARLY_PRINTK=y
```Turris OS 6.0https://gitlab.nic.cz/turris/os/build/-/issues/345Turris 1.x missing PHY drivers2022-08-04T16:59:40+02:00Josef SchlehoferTurris 1.x missing PHY drivers@prohar investigated and provided steps to reproduce it. We don't have enabled proper drivers for Turris 1.x's PHYs.
- WAN uses KSZ9031RNXCA chip (Driver: CONFIG_MICREL_PHY)
- SWITCH uses QCA8337N-AL3C chip (Driver: CONFIG_AT803X_PHY)...@prohar investigated and provided steps to reproduce it. We don't have enabled proper drivers for Turris 1.x's PHYs.
- WAN uses KSZ9031RNXCA chip (Driver: CONFIG_MICREL_PHY)
- SWITCH uses QCA8337N-AL3C chip (Driver: CONFIG_AT803X_PHY)
- [x] kernel 4.14 https://gitlab.nic.cz/turris/os/build/-/commit/05370f0686413eab7f404cbfac6c9660943bc67f
- [x] kernel 5.4 https://gitlab.nic.cz/turris/os/build/-/commit/60e7422b674e98cb728fee97659a3560460854d9
- [x] kernel 5.10 https://gitlab.nic.cz/turris/os/build/-/commit/c8c7cb5c3da79a5c913bf1e8c53d058ab50bfa9f
- [x] kernel 5.15
Steps to verify:
- WAN:
```
$ basename "`readlink -f /sys/class/net/eth2/phydev/driver`"
```
- Switch:
```
$ basename "`readlink -f /sys/class/net/lan1/device/mdio_bus/dsa-0.0/dsa-0.0:01/driver`"
```
It should not report ``Generic PHY``Turris OS 6.0https://gitlab.nic.cz/turris/os/build/-/issues/344Cannot load ath10k_pci in 5.3.92022-05-16T17:09:04+02:00tommyqCannot load ath10k_pci in 5.3.9Hi,
I found an issue with not working 5GHz Wi-Fi on Turris MOX in 5.3.9. It seems it cannot load the ath10k_pci module.
```
[ 11.998833] ath10k 4.19 driver, optimized for CT firmware, probing pci device: 0x3c.
[ 12.008291] ath10k_pc...Hi,
I found an issue with not working 5GHz Wi-Fi on Turris MOX in 5.3.9. It seems it cannot load the ath10k_pci module.
```
[ 11.998833] ath10k 4.19 driver, optimized for CT firmware, probing pci device: 0x3c.
[ 12.008291] ath10k_pci 0000:00:00.0: enabling device (0000 -> 0002)
[ 12.014923] ath10k_pci 0000:00:00.0: pci irq msi oper_irq_mode 2 irq_mode 0 reset_mode 0
[ 12.247935] ath10k_pci 0000:00:00.0: Direct firmware load for ath10k/fwcfg-pci-0000:00:00.0.txt failed with error -2
[ 12.258567] ath10k_pci 0000:00:00.0: Falling back to user helper
[ 13.098576] firmware ath10k!fwcfg-pci-0000:00:00.0.txt: firmware_loading_store: map pages failed
[ 13.107947] ath10k_pci 0000:00:00.0: Direct firmware load for ath10k/pre-cal-pci-0000:00:00.0.bin failed with error -2
[ 13.118935] ath10k_pci 0000:00:00.0: Falling back to user helper
[ 13.140448] firmware ath10k!pre-cal-pci-0000:00:00.0.bin: firmware_loading_store: map pages failed
[ 13.149881] ath10k_pci 0000:00:00.0: Direct firmware load for ath10k/cal-pci-0000:00:00.0.bin failed with error -2
[ 13.160400] ath10k_pci 0000:00:00.0: Falling back to user helper
[ 13.182203] firmware ath10k!cal-pci-0000:00:00.0.bin: firmware_loading_store: map pages failed
[ 13.191534] ath10k_pci 0000:00:00.0: Direct firmware load for ath10k/QCA988X/hw2.0/ct-firmware-5.bin failed with error -2
[ 13.202867] ath10k_pci 0000:00:00.0: Falling back to user helper
```
[turris.log](/uploads/c3fd019abee0d3dab5ab6129fbe4b2ea/turris.log)
Log attached.
BR/TTurris OS 5.3.9Marek BehunMarek Behun