Turris Build issueshttps://gitlab.nic.cz/turris/os/build/-/issues2023-08-16T10:54:51+02:00https://gitlab.nic.cz/turris/os/build/-/issues/391USB 3 devices not recognized in MOX2023-08-16T10:54:51+02:00Stepan RechnerUSB 3 devices not recognized in MOXUSB 3 devices are not recognized by the operating system. They look like not connected at all: `lsusb` does not show them.
The issue has been reported by some users and successfully reproduced.USB 3 devices are not recognized by the operating system. They look like not connected at all: `lsusb` does not show them.
The issue has been reported by some users and successfully reproduced.Turris OS 6.2.2Michal HruseckyMichal Hruseckyhttps://gitlab.nic.cz/turris/os/build/-/issues/165[Omnia] kernel's bridge FDB not reconciling switch's ATU2023-08-16T10:58:09+02:00Ghost User[Omnia] kernel's bridge FDB not reconciling switch's ATUIssue observed by users and reported in forums:
- https://forum.turris.cz/t/to-lan-switch-or-bridge-blocks-dhcp-replies-intermittently/13242
- https://forum.turris.cz/t/lan-ports-arent-accessible-for-wifi-client-for-the-first-250-330-se...Issue observed by users and reported in forums:
- https://forum.turris.cz/t/to-lan-switch-or-bridge-blocks-dhcp-replies-intermittently/13242
- https://forum.turris.cz/t/lan-ports-arent-accessible-for-wifi-client-for-the-first-250-330-seconds-after-connection/12071
- https://forum.turris.cz/t/omnia-vlan-on-dsa-port-breaks-arp-responses-tos-4-0-5/12584
- https://forum.openwrt.org/t/access-point-configuration-problem/52938
---
With the Wlan cards and the switch utilising different buses there is no direct information exchange but only via CPU/kernel. That results in the switch's ATU being unaware of client MAC addresses connected to Wlan since the bridge/DSA driver does not reconcile its bridge FDB entries with the switch's ATU.
For that the node's clients roaming from one of its Lan ports to a Wlan port are not able to receive traffic from the Lan ports until the switch's ATU ageing register (default ~ 300 seconds) clears the roamed client's MAC, as it remains unaware that the client has moved to another port (Wlan) and therefore drops traffic for that client's MAC.
The issue started to manifest only with the introduction of DSA and subsequent removal of OpenWrt's *swconfig* which if enabled routed all Lan traffic through the CPU(s).
Whilst this may seem like an inherent design flaw of the kernel's DSA/bridge driver it may not be accepted upstream as such.Turris OS 6.0https://gitlab.nic.cz/turris/os/build/-/issues/432mwan3 and iptables2024-03-04T18:10:59+01:00Michal Hruseckymwan3 and iptablesMake sure mwan3 works in iptables mode.Make sure mwan3 works in iptables mode.Turris OS 7.0Michal HruseckyMichal Hruseckyhttps://gitlab.nic.cz/turris/os/build/-/issues/302reForis dos not work after migration because of a package not installed2021-10-05T11:28:14+02:00Stepan RechnerreForis dos not work after migration because of a package not installedSome users
[reported on our forum](https://forum.turris.cz/t/can-not-use-reforis-on-tos-5-controllermissing/13816/17),
that after migration to TOS 5.2.7, reForis did not work. For some reason, installing package `reforis-netboot-plugin...Some users
[reported on our forum](https://forum.turris.cz/t/can-not-use-reforis-on-tos-5-controllermissing/13816/17),
that after migration to TOS 5.2.7, reForis did not work. For some reason, installing package `reforis-netboot-plugin` helped them.
This issue was also reported on our support ([RT ticket](https://rt.nic.cz/Ticket/Display.html?id=1389667) #1389667) and the same solution was confirmed.
cc @mmatejekTurris OS 5.3.0https://gitlab.nic.cz/turris/os/build/-/issues/275btrfs instruction not supported on TurrisOS 5.2.12023-08-16T10:59:12+02:00Mikebtrfs instruction not supported on TurrisOS 5.2.1`➜ ~ btrfs sub show -ruh /srv
ERROR: uh is not a valid numeric value.
➜ ~ btrfs sub show -ru /srv
ERROR: u is not a valid numeric value.
➜ ~ btrfs sub show -uh /srv
ERROR: can't find uuid '6d650000-a875-5100-2000-000000000000' on ...`➜ ~ btrfs sub show -ruh /srv
ERROR: uh is not a valid numeric value.
➜ ~ btrfs sub show -ru /srv
ERROR: u is not a valid numeric value.
➜ ~ btrfs sub show -uh /srv
ERROR: can't find uuid '6d650000-a875-5100-2000-000000000000' on '/srv'
[1] 22243 illegal hardware instruction btrfs sub show -uh /srv
➜ ~ btrfs sub show -u /srv
btrfs subvolume show: exactly 1 argument expected, 0 given
`Michal HruseckyMichal Hruseckyhttps://gitlab.nic.cz/turris/os/build/-/issues/149Multiple SSID does not work on SDIO Wi-Fi card2023-08-16T11:01:26+02:00Josef SchlehoferMultiple SSID does not work on SDIO Wi-Fi cardChip Marvell 88W8997 used on Wi-Fi card has some issues with Multiple SSID, which prevents using mostly Guest network.
There is a forum thread about that: https://forum.turris.cz/t/enterprise-wi-fi-does-not-work-with-mox-sdio-wi-fi/1049...Chip Marvell 88W8997 used on Wi-Fi card has some issues with Multiple SSID, which prevents using mostly Guest network.
There is a forum thread about that: https://forum.turris.cz/t/enterprise-wi-fi-does-not-work-with-mox-sdio-wi-fi/10494/3?u=pepe
However, we prepared workaround for Guest network - https://forum.turris.cz/t/guest-network-sdio-wi-fi-issue-workaround/11899 , but it was tested by just one user and this does not help if it works or not. We need better feedback on it. I think we can try to send that firmware to HBL/HBD branches to see if it is better.Turris OS 5.0.4https://gitlab.nic.cz/turris/os/build/-/issues/105Turris 1.x: add fw_env.config for uboot-tools2020-12-02T14:11:53+01:00Karel KociTurris 1.x: add fw_env.config for uboot-toolsConfiguration for uboot tools is missing. We should either add it to uboot-tools package or we can just provide file `/etc/fw_env.config` with content
```
/dev/mtd5 0x20000 0x2000 0x20000
```Configuration for uboot tools is missing. We should either add it to uboot-tools package or we can just provide file `/etc/fw_env.config` with content
```
/dev/mtd5 0x20000 0x2000 0x20000
```Turris OS 5.2.0https://gitlab.nic.cz/turris/os/build/-/issues/103crashes in Foris (controller | client)2023-08-16T11:05:33+02:00Ghost Usercrashes in Foris (controller | client)>* {"kernel":"4.14.162","hostname":"to","system":"ARMv7 Processor rev 1 (v7l)","model":"Turris Omnia","board_name":"cznic,turris-omnia","release":{"distribution":TurrisOS","version":"5.0-dev","revision":"e7908af","target":"mvebu/cortexa9...>* {"kernel":"4.14.162","hostname":"to","system":"ARMv7 Processor rev 1 (v7l)","model":"Turris Omnia","board_name":"cznic,turris-omnia","release":{"distribution":TurrisOS","version":"5.0-dev","revision":"e7908af","target":"mvebu/cortexa9","description":"TurrisOS 5.0-dev eb156345419953a382cda233bffa4291f5cb78d8"}}
* also happens with a TOS Master instance
___
`/etc/init.d/foris-controller start` produces
>foris-controller: Traceback (most recent call last):
>foris-controller: File "/usr/bin/foris-controller", line 11, in <module>
>foris-controller: load_entry_point('foris-controller==1.0.8', 'console_scripts', 'foris-controller')()
>foris-controller: File "/__main__.py", line 184, in main
>foris-controller: File "/mqtt.py", line 417, in __init__
>foris-controller: File "/usr/lib/python3.7/site-packages/paho/mqtt/client.py", line 937, in connect
>foris-controller: return self.reconnect()
>foris-controller: File "/usr/lib/python3.7/site-packages/paho/mqtt/client.py", line 1071, in reconnect
>foris-controller: sock = self._create_socket_connection()
>foris-controller: File "/usr/lib/python3.7/site-packages/paho/mqtt/client.py", line 3522, in _create_socket_connection
>foris-controller: return socket.create_connection(addr, source_address=source, timeout=self._keepalive)
>foris-controller: File "/socket.py", line 728, in create_connection
>foris-controller: File "/socket.py", line 716, in create_connection
>foris-controller: ConnectionRefusedError: [Errno 111] Connection refused
finally terminating with
>procd: Instance foris-controller::instance1 s in a crash loop 6 crashes, 1 seconds since last crash
___
potential domino effect (or separate issue)
`ps | lighttpd -D -f /etc/lighttpd/lighttpd.conf`
>Traceback (most recent call last):
> File "/usr/bin/foris", line 11, in <module>
> load_entry_point('Foris==100.6', 'console_scripts', 'foris')()
> File "/__main__.py", line 124, in main
> File "/backend.py", line 62, in __init__
> File "/mqtt.py", line 184, in __init__
> File "/base.py", line 56, in __init__
>Exception in thread foris-client-reply-listener:
>Traceback (most recent call last):
> File "/threading.py", line 926, in _bootstrap_inner
> File "/mqtt.py", line 161, in run
> File "/usr/lib/python3.7/site-packages/paho/mqtt/client.py", line 937, in connect
> return self.reconnect()
> File "/usr/lib/python3.7/site-packages/paho/mqtt/client.py", line 1071, in reconnect
> sock = self._create_socket_connection()
> File "/usr/lib/python3.7/site-packages/paho/mqtt/client.py", line 3522, in _create_socket_connection
> return socket.create_connection(addr, source_address=source, timeout=self._keepalive)
> File "/socket.py", line 728, in create_connection
> File "/socket.py", line 716, in create_connection
>ConnectionRefusedError: [Errno 111] Connection refusedTurris OS 4.0.6https://gitlab.nic.cz/turris/os/build/-/issues/57Turris Omnia kernel 4.19 support2019-07-31T16:32:53+02:00Karel KociTurris Omnia kernel 4.19 supportUpdate patches for Turris Omnia for kernel 4.19
Upstream set kernel version in master to 4.19 for mvebu architecture. We should follow with that.
Currently we do not have correct device tree because we split it to two device trees. Thi...Update patches for Turris Omnia for kernel 4.19
Upstream set kernel version in master to 4.19 for mvebu architecture. We should follow with that.
Currently we do not have correct device tree because we split it to two device trees. This means that package `omnia-support` fails with following error in master build:
```
install: cannot stat '/home/beast/beast/workspace/turris-os-packages-master-omnia/build/build_dir/target-arm_cortex-a9+vfpv3_musl_eabi/linux-mvebu_cortexa9/linux-4.19.56/arch/arm/boot/dts/armada-385-turris-omnia-*.dtb': No such file or directory
```
Porting patches to 4.19 should fix this.https://gitlab.nic.cz/turris/os/build/-/issues/41Automatic package bumping should be package wide2020-06-15T22:17:11+02:00Karel KociAutomatic package bumping should be package wideCurrent work in progress implementation of automatic package bumper is using package name (real package to be build) to identify if it should be bumped. The problem is that in reality it is expected that packages from same Makefile have ...Current work in progress implementation of automatic package bumper is using package name (real package to be build) to identify if it should be bumped. The problem is that in reality it is expected that packages from same Makefile have same `PKG_VERSION` and `PKG_RELEASE`. This is because they are build from same source. Autobumber breaks that.
Solution is to just instead of looking if we should bump specific package, we should instead bump all packages in Makefile. This should be even easier to be done than current solution as we should modify `PKG_RELEASE` variable instead of hacking package creation process.
Simply put: when any package defined in Makefile is detected as different then we should change `PKG_RELEASE` and that way we bump all packages generated by that Makefile.
This should fix: https://gitlab.labs.nic.cz/turris/turris-os-packages/issues/417https://gitlab.nic.cz/turris/os/build/-/issues/28[lxc] unprivileged container not booting - rootfs fails mounting2021-05-18T16:51:57+02:00Ghost User[lxc] unprivileged container not booting - rootfs fails mounting> {"kernel":"4.14.123","hostname":"to","system":"ARMv7 Processor rev 1 (v7l)","model":"Turris Omnia","board_name":"armada-385-turris-omnia","release":{"distribution":"TurrisOS","version":"4.0-beta2","revision":"ab3fd04","target":"mvebu\/...> {"kernel":"4.14.123","hostname":"to","system":"ARMv7 Processor rev 1 (v7l)","model":"Turris Omnia","board_name":"armada-385-turris-omnia","release":{"distribution":"TurrisOS","version":"4.0-beta2","revision":"ab3fd04","target":"mvebu\/cortexa9","description":"TurrisOS 4.0-beta2 ab3fd04"}}
___
* installed are - lxc-unprivileged | shadow-newgidmap | shadow-newuidmap
* in absentia manually created /etc/subgid | /etc/subuid
* exec - `usermod --add-subuids 100000-165536 $USER && usermod --add-subgids 100000-165536 $USER`
* exec - `lxc-checkconfig` [lxc-checkconfig.txt](/uploads/690fb5525e27541df521a50f8b2b32fc/lxc-checkconfig.txt)
* container ubuntu disco created
* added `lxc.idmap = u 0 100000 65536` | `lxc.idmap = g 0 100000 65536` to [container.conf](/uploads/c388c071b44b10e8caf3c3c6e8befacb/container.conf)
___
* exec - `lxc-start test -F -o /logs/lxc/test -l debug` [log.txt](/uploads/7947c8e28842cda76d27b01d439202df/log.txt)
* `dmesg` not reporting anything related to the issue
* container boots with no issues if *privileged*
* `cat /proc/1/mounts` [mounts.text](/uploads/aa45adad744636327790e70862e4f39c/mounts.text)
* kernel conf [config](/uploads/7ff963b82770bf7f1e4270fc00823812/config)
* `stat /usr/lib/lxc/rootfs/`
> File: ‘/usr/lib/lxc/rootfs/’
> Size: 12 Blocks: 0 IO Block: 4096 directory
> Device: 10h/16d Inode: 31359 Links: 1
> Access: (0711/drwx--x--x) Uid: ( 0/ root) Gid: ( 0/ root)
* `cat /proc/self/cgroup`
> 11:debug:/
> 10:rdma:/
> 9:pids:/
> 8:net_cls:/
> 7:freezer:/
> 6:devices:/
> 5:memory:/
> 4:blkio:/
> 3:cpuacct:/
> 2:cpu:/
> 1:cpuset:/
* `ls -al /proc/sys/kernel/| grep unpriv`
> -rw-r--r-- 1 root root 0 Jun 5 12:58 unprivileged_bpf_disabled
https://gitlab.nic.cz/turris/os/build/-/issues/430LuCI LXC page not working2024-03-04T10:09:42+01:00Michal HruseckyLuCI LXC page not workingAs reported on forum, LXC page in LuCI might not be working
https://forum.turris.cz/t/turris-os-7-0-is-in-rc/19755/18As reported on forum, LXC page in LuCI might not be working
https://forum.turris.cz/t/turris-os-7-0-is-in-rc/19755/18Turris OS 7.0Tomas ZakTomas Zakhttps://gitlab.nic.cz/turris/os/build/-/issues/428Strongswan seems to misbehave2024-03-04T10:10:06+01:00Michal HruseckyStrongswan seems to misbehavehttps://forum.turris.cz/t/turris-os-7-0-is-in-rc/19755/20https://forum.turris.cz/t/turris-os-7-0-is-in-rc/19755/20Turris OS 7.0Richard MuzikRichard Muzikhttps://gitlab.nic.cz/turris/os/build/-/issues/385Wrong default governor in TOS 6.02022-11-16T17:17:10+01:00Michal HruseckyWrong default governor in TOS 6.0When updating to a newer kernel, default governor was changed from performance to ondemand without any issue or reasoning. Difference in power consumption between ondemand and performance governors is negligible (at least on our boards) ...When updating to a newer kernel, default governor was changed from performance to ondemand without any issue or reasoning. Difference in power consumption between ondemand and performance governors is negligible (at least on our boards) while ondemand has noticeable lag when starting transmissions. Apart from that we have seen some issues on Armada 3720 when switching between frequencies. So we should revert this change to make our products more responsive and potentially also more stable.
Fixed in turris/os/build!579Turris OS 6.0.3Michal HruseckyMichal Hruseckyhttps://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/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/338compile_pkgs unrecognized parameters2022-04-01T17:46:50+02:00Adam Konrádcompile_pkgs unrecognized parametersHello, I'd like to report an issue with the compile_pkgs script.
```
uname -srm
Linux 5.10.102-99.473.amzn2.aarch64 aarch64
```
This is a centos based distro.
I'm getting the following:
```
../build/compile_pkgs prepare_tools -t omni...Hello, I'd like to report an issue with the compile_pkgs script.
```
uname -srm
Linux 5.10.102-99.473.amzn2.aarch64 aarch64
```
This is a centos based distro.
I'm getting the following:
```
../build/compile_pkgs prepare_tools -t omnia
There is no such option or command: prepare_tools
```
```
../build/compile_pkgs -t omnia
...
Checking 'rsync'... ok.
make[1] diffconfig
Setting ccache paths
Compiling tools
../build/compile_pkgs: line 58: BUILD_ARGS[@]: unbound variable
```
I'm not sure if this is some tool version mismatch or a problem in the script.https://gitlab.nic.cz/turris/os/build/-/issues/329LEDs in sys are not found2022-02-20T14:51:51+01:00Josef SchlehoferLEDs in sys are not foundRescue does not work with this:
```
/init: line 35: can't create /sys/class/leds/omnia-led:all/color: nonexistent directory
/init: line 37: can't create /sys/class/leds/omnia-led*/trigger: nonexistent directory
/init: line 39: can't crea...Rescue does not work with this:
```
/init: line 35: can't create /sys/class/leds/omnia-led:all/color: nonexistent directory
/init: line 37: can't create /sys/class/leds/omnia-led*/trigger: nonexistent directory
/init: line 39: can't create /sys/class/leds/omnia-led:power/trigger: nonexistent directory
2s left
cat: can't open '/sys/class/leds/omnia-led:all/device/global_brightness': No such file or directory
sh: out of range
```
In running system:
```
Feb 8 14:50:01 turris crond[5966]: (root) CMD (/usr/bin/rainbow_button_sync.sh)
Feb 8 14:50:01 turris crond[5964]: (root) CMDOUT (Failed to open file: No such file or directory)
Feb 8 14:50:01 turris crond[5964]: (root) CMDEND (/usr/bin/rainbow_button_sync.sh)
```Turris OS 7.0https://gitlab.nic.cz/turris/os/build/-/issues/321Update libblkid to 2.372023-08-16T10:56:03+02:00Michal NazarewiczUpdate libblkid to 2.37Would it be possible to get libblkid to 2.37?
Specifically, I care about [a commit which makes Atari partition detection more robust](https://github.com/util-linux/util-linux/commit/282ceadc3a72fc07dd0388b8880fd751490bb87f).
My Omnia w...Would it be possible to get libblkid to 2.37?
Specifically, I care about [a commit which makes Atari partition detection more robust](https://github.com/util-linux/util-linux/commit/282ceadc3a72fc07dd0388b8880fd751490bb87f).
My Omnia with TurrisOS 5.3.3 started recognising one of my partitions as Atari partition:
[omnia]# blkid /dev/md0
/dev/md0: PTTYPE="atari"
This wouldn’t be a huge issue except that it’s a plain encrypted partition and cryptsetup refuses to open it without human confirmation:
WARNING: Device /dev/md0 already contains a 'atari' partition signature.
WARNING!
========
Detected device signature(s) on /dev/md0. Proceeding further may damage existing data.
Are you sure? (Type uppercase yes): YES
This still wouldn’t be a huge issue except my [router started rebooting randomly every couple of days](https://forum.turris.cz/t/turrisos-5-3-3-randomly-reboots/16498) so now every day or so I need to log into the router to mount the partition.