Turris Build issueshttps://gitlab.nic.cz/turris/os/build/-/issues2024-03-04T10:10:06+01:00https://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/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/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/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/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/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/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/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.https://gitlab.nic.cz/turris/os/build/-/issues/320LXC do not work after installation until reboot is performed2023-08-16T10:55:39+02:00Karel KociLXC do not work after installation until reboot is performedThe `lxc-start` service has reboot job that has to be performed to allow LXC to work. The clean install of LXC does not trigger that and reboot has to be performed or `/etc/init.d/lxc-start boot`. We should use condition `[ "$PKG_UPGRADE...The `lxc-start` service has reboot job that has to be performed to allow LXC to work. The clean install of LXC does not trigger that and reboot has to be performed or `/etc/init.d/lxc-start boot`. We should use condition `[ "$PKG_UPGRADE" = 0 ]` to trigger `/etc/init.d/lxc-start boot` in postinst script.Turris OS 5.3.10https://gitlab.nic.cz/turris/os/build/-/issues/319TOS 6.0 Multiple bridged, non-VLAN networks do not work with DSA2022-11-24T17:47:53+01:00Martin MatějekTOS 6.0 Multiple bridged, non-VLAN networks do not work with DSA## Description
We use separate bridges for `lan` and `guest` network, without explicit VLANs set.
Both bridges works fine on TOS based on OpenWrt 19.07, but on TOS 6 based on OpenWrt 21.02 only first (in alphabetical order) bridge is a...## Description
We use separate bridges for `lan` and `guest` network, without explicit VLANs set.
Both bridges works fine on TOS based on OpenWrt 19.07, but on TOS 6 based on OpenWrt 21.02 only first (in alphabetical order) bridge is actually brought up.
So basically only `br-guest-turris` is working, while `br-lan` is not.
On OpenWrt 19.07, there is a warning in logs, but it works fine regardless.
/var/log/messages
```
IPv6: ADDRCONF(NETDEV_UP): br-guest_turris: link is not ready
mvneta f1030000.ethernet eth1: configuring for fixed/rgmii link mode
IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
mvneta f1030000.ethernet eth1: Link is Up - 1Gbps/Full - flow control off
IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
mv88e6085 f1072004.mdio-mii:10 lan0: configuring for phy/gmii link mode
br-guest_turris: port 1(lan0) entered blocking state
br-guest_turris: port 1(lan0) entered disabled state
device lan0 entered promiscuous mode
device eth1 entered promiscuous mode
IPv6: ADDRCONF(NETDEV_UP): br-lan: link is not ready
mv88e6085 f1072004.mdio-mii:10 lan1: configuring for phy/gmii link mode
br-lan: port 1(lan1) entered blocking state
br-lan: port 1(lan1) entered disabled state
device lan1 entered promiscuous mode
mv88e6085 f1072004.mdio-mii:10: p1: hw VLAN 1 already used by br-guest_turris
mv88e6085 f1072004.mdio-mii:10 lan2: configuring for phy/gmii link mode
```
Also if some interfaces are already assigned to guest bridge on TOS 5 and user switches to TOS 6 based branches (HBL, HBD), then `br-lan` won't be active after reboot, thus making router inaccessible from LAN.
## Expected behavior
Both bridges are up and have their ports assigned based on `/etc/config/network`.
```
$ brctl show
bridge name bridge id STP enabled interfaces
br-guest_turris 7fff.d858d70055b6 no lan0
br-lan 7fff.d858d70055b6 no lan4
lan2
lan3
lan1
```
## Actual behavior
Only `br-guest-turris` is up and has its ports active.
```
$ brctl show
bridge name bridge id STP enabled interfaces
br-lan 7fff.000000000000 no
br-guest_turris 7fff.d858d70055b6 no lan0
```
/var/log/messages
```
8021q: adding VLAN 0 to HW filter on device lan0
br-guest_turris: port 1(lan0) entered blocking state
br-guest_turris: port 1(lan0) entered disabled state
device lan0 entered promiscuous mode
device eth1 entered promiscuous mode
mv88e6085 f1072004.mdio-mii:10: p5: already a member of VLAN 1
mv88e6085 f1072004.mdio-mii:10 lan1: configuring for phy/gmii link mode
8021q: adding VLAN 0 to HW filter on device lan1
br-lan: port 1(lan1) entered blocking state
br-lan: port 1(lan1) entered disabled state
mv88e6085 f1072004.mdio-mii:10: p1: hw VLAN 1 already used by port 0 in br-guest_turris
mv88e6085 f1072004.mdio-mii:10 lan1: failed to initialize vlan filtering on this port
[and so on for lan2..lan4]
```
## How to reproduce
Either on TOS 6.x:
1. Assign at least one interface (e.g. lan0) to guest bridge.
1. Then reboot or restart the network in cli.
Or on TOS 5.3.x
1. Assign at least one interface (e.g. lan0) to guest bridge.
1. Switch TOS to HBL/HBD
1. Reboot
## References
* https://bugs.openwrt.org/index.php?do=details&task_id=4171&opened=3712&status%5B0%5D=&order=id&sort=asc
* https://forum.openwrt.org/t/solved-dsa-multiple-networks-on-21-02-not-bridging-to-lan-ports/108963https://gitlab.nic.cz/turris/os/build/-/issues/318MOX Could not find PHY for device 'radio0'2022-01-17T18:53:54+01:00tommyqMOX Could not find PHY for device 'radio0'Hi,
after upgrade of my MOX (USN 56639902077) to 5.3.4 with kernel 4.14.261 my radio0 (QXA9880) stopped working. Tried to rollback and upgrade again, tried to switch from ct to orig driver, but the without any change. As a temporary bac...Hi,
after upgrade of my MOX (USN 56639902077) to 5.3.4 with kernel 4.14.261 my radio0 (QXA9880) stopped working. Tried to rollback and upgrade again, tried to switch from ct to orig driver, but the without any change. As a temporary backup solution I started to use 88W8997 without any problem.
```
Jan 13 09:30:26 turris netifd: radio0 (8978): Could not find PHY for device 'radio0'
Jan 13 10:30:26 turris kernel: [ 476.948268] device wlan0 left promiscuous mode
Jan 13 10:30:26 turris kernel: [ 476.952987] br-lan: port 5(wlan0) entered disabled state
Jan 13 09:30:26 turris netifd: radio0 (8993): WARNING: Variable 'data' does not exist or is not an array/object
Jan 13 09:30:26 turris netifd: Network device 'wlan0' link is down
Jan 13 10:30:27 turris kernel: [ 477.316263] mwifiex_sdio mmc0:0001:1: CMD_RESP: cmd 0x20 error, result=0x1
Jan 13 09:30:27 turris mac80211: Failed command: iw phy phy0 set antenna 0xffffffff 0xffffffff
Jan 13 09:30:27 turris netifd: radio1 (9018): command failed: Not supported (-95)
Jan 13 09:30:27 turris mac80211: Failed command: iw phy phy0 set antenna_gain 0
```
Logs attached
BR
Tomas
[2022-01-13-10-33-06_74c63089.txt.gz](/uploads/b912175aa2bf3b806bf2092d7b11f9a4/2022-01-13-10-33-06_74c63089.txt.gz)Turris OS 5.3.4Marek BehunMarek Behunhttps://gitlab.nic.cz/turris/os/build/-/issues/314/dev mounted twice2022-01-03T15:06:18+01:00Ghost User/dev mounted twiceThis is only a minor annoyance, but /dev is mounted twice:
```
# mount | grep " on /dev "
devtmpfs on /dev type devtmpfs (rw,relatime,size=1033476k,nr_inodes=189059,mode=755)
tmpfs on /dev type tmpfs (rw,nosuid,relatime,size=512k,mode=7...This is only a minor annoyance, but /dev is mounted twice:
```
# mount | grep " on /dev "
devtmpfs on /dev type devtmpfs (rw,relatime,size=1033476k,nr_inodes=189059,mode=755)
tmpfs on /dev type tmpfs (rw,nosuid,relatime,size=512k,mode=755)
```
I believe the first (type devtmpfs) mount is coming from the kernel config option CONFIG_KERNEL_DEVTMPFS_MOUNT=y, while the second (type tmpfs) mount is coming from patches/openwrt/to-upstream/0022-procd-New-style-of-cgroups.patch:
```
+++ b/package/system/procd/patches/new-style-of-cgroup-hiearchy.patch
++++ b/initd/early.c
+ mount("tmpfs", "/dev", "tmpfs", MS_NOATIME | MS_NOSUID, "mode=0755,size=512K");
```
I believe that second mount (type tmpfs in early_mounts() from that patch) is redundant & should be removed (or made conditional on a check if /dev is already mounted, if we can't rely on CONFIG_KERNEL_DEVTMPFS_MOUNT=y always being set).
Thanks,
Conway S. SmithTurris OS 6.0https://gitlab.nic.cz/turris/os/build/-/issues/313Not all switch ports configured2023-08-16T10:55:18+02:00Hristo VenevNot all switch ports configuredOn my router (Omnia, HBL, 6.0) support for multiple bridges seems to be broken (I haven't tried to set up VLAN tagging yet). One of the bridges does not get its ports attached:
```
config device
option type 'bridge'
option name 'br-la...On my router (Omnia, HBL, 6.0) support for multiple bridges seems to be broken (I haven't tried to set up VLAN tagging yet). One of the bridges does not get its ports attached:
```
config device
option type 'bridge'
option name 'br-lan'
option macaddr '00:AA:BB:CC:DD:FF'
option vlan_filtering '0'
list ports 'lan0'
list ports 'lan1'
list ports 'lan2'
list ports 'lan3'
config device
option type 'bridge'
option name 'br-guest'
option macaddr '00:AA:BB:CC:DD:FF'
option vlan_filtering '0'
list ports 'lan4'
```
```
[ 12.796012] mv88e6085 f1072004.mdio-mii:10: p0: hw VLAN 1 already used by port 4 in br-guest
[ 12.842322] mv88e6085 f1072004.mdio-mii:10 lan0: failed to initialize vlan filtering on this port
```
```
root@omnia:~# ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST> mtu 1508 qdisc mq state DOWN mode DEFAULT group default qlen 1024
link/ether 00:AA:BB:CC:DD:EE brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1508 qdisc mq state UP mode DEFAULT group default qlen 1024
link/ether 00:AA:BB:CC:DD:FF brd ff:ff:ff:ff:ff:ff
...
5: lan0@eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default qlen 1000
link/ether 00:AA:BB:CC:DD:FF brd ff:ff:ff:ff:ff:ff
6: lan1@eth0: <BROADCAST,MULTICAST,M-DOWN> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default qlen 1000
link/ether 00:AA:BB:CC:DD:EE brd ff:ff:ff:ff:ff:ff
7: lan2@eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default qlen 1000
link/ether 00:AA:BB:CC:DD:FF brd ff:ff:ff:ff:ff:ff
8: lan3@eth0: <BROADCAST,MULTICAST,M-DOWN> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default qlen 1000
link/ether 00:AA:BB:CC:DD:EE brd ff:ff:ff:ff:ff:ff
9: lan4@eth1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master br-guest state LOWERLAYERDOWN mode DEFAULT group default qlen 1000
link/ether 00:AA:BB:CC:DD:FF brd ff:ff:ff:ff:ff:ff
...
19: br-guest: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
link/ether 00:AA:BB:CC:DD:FF brd ff:ff:ff:ff:ff:ff
20: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
link/ether 00:AA:BB:CC:DD:FF brd ff:ff:ff:ff:ff:ff
21: wlan1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-lan state UP mode DEFAULT group default qlen 1000
link/ether 04:23:45:67:89:AB brd ff:ff:ff:ff:ff:ff
22: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-lan state UP mode DEFAULT group default qlen 1000
link/ether 04:23:45:67:89:AC brd ff:ff:ff:ff:ff:ff
...
24: wlan1-1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-guest state UP mode DEFAULT group default qlen 1000
link/ether 06:23:45:67:89:AD brd ff:ff:ff:ff:ff:ff
25: wlan0-1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-guest state UP mode DEFAULT group default qlen 1000
link/ether 06:23:45:67:89:AE brd ff:ff:ff:ff:ff:ff
root@omnia:~# ip link set dev lan0 master br-lan
RTNETLINK answers: Resource busy
root@omnia:~# bridge vlan
port vlan-id
lan4 1 PVID Egress Untagged
br-guest 1 PVID Egress Untagged
br-lan 1 PVID Egress Untagged
wlan1 1 PVID Egress Untagged
wlan0 1 PVID Egress Untagged
wlan1-1 1 PVID Egress Untagged
wlan0-1 1 PVID Egress Untagged
```
```
root@omnia:~# cat /etc/os-release
NAME="TurrisOS"
VERSION="6.0"
ID="turrisos"
ID_LIKE="lede openwrt"
PRETTY_NAME="TurrisOS 6.0"
VERSION_ID="6.0"
HOME_URL="https://www.turris.cz/"
BUG_URL="https://gitlab.nic.cz/groups/turris/-/issues/"
SUPPORT_URL="https://www.turris.cz/support/"
BUILD_ID="r16401+67-14940aee45"
OPENWRT_BOARD="mvebu/cortexa9"
OPENWRT_ARCH="arm_cortex-a9_vfpv3-d16"
OPENWRT_TAINTS="busybox"
OPENWRT_DEVICE_MANUFACTURER="CZ.NIC"
OPENWRT_DEVICE_MANUFACTURER_URL="https://www.turris.cz/"
OPENWRT_DEVICE_PRODUCT="Turris Omnia"
OPENWRT_DEVICE_REVISION="v0"
OPENWRT_RELEASE="TurrisOS 6.0 14940aee4566cff33fff9e068fb9559a1925cf44"
```Turris OS 6.0Hristo VenevHristo Venevhttps://gitlab.nic.cz/turris/os/build/-/issues/311Wrong order of ethernet ports on Turris 1.x on TOS 5.3.22021-12-09T17:54:07+01:00Stepan RechnerWrong order of ethernet ports on Turris 1.x on TOS 5.3.2On a freshly installed TOS 5.3.2 from medkit on Turris 1.1 the order of ports is inverse in the `Interfaces` tab in reForis to the labels on the physical box.
cc: @mhruseckyOn a freshly installed TOS 5.3.2 from medkit on Turris 1.1 the order of ports is inverse in the `Interfaces` tab in reForis to the labels on the physical box.
cc: @mhruseckyhttps://gitlab.nic.cz/turris/os/build/-/issues/303LXC containers fail to start2021-11-23T17:31:36+01:00Karel KociLXC containers fail to start```
lxc-start arch 20211015124315.754 DEBUG conf - conf.c:run_buffer:313 - Script exec /usr/share/lxc/hooks/systemd-workaround arch lxc start-host produced output: sh: exec: line 1:
lxc-start arch 20211015124315.754 DEBUG conf - co...```
lxc-start arch 20211015124315.754 DEBUG conf - conf.c:run_buffer:313 - Script exec /usr/share/lxc/hooks/systemd-workaround arch lxc start-host produced output: sh: exec: line 1:
lxc-start arch 20211015124315.754 DEBUG conf - conf.c:run_buffer:313 - Script exec /usr/share/lxc/hooks/systemd-workaround arch lxc start-host produced output: /usr/share/lxc/hooks/systemd-workaround: not found
```
most probably related to turris/os/build#297 (reintroduced).Turris OS 6.0https://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/300Active DHCPv6 Leases2021-09-29T11:15:23+02:00Giuseppe PiscitelliActive DHCPv6 LeasesSwitching from HBS to HBD with switch-branch the active DHCPv6 Leases does not return any value on either reForis or LuCI. The problem occurs for several months. Although there is IPv6 connectivity for the WAN and hosts connected to Turr...Switching from HBS to HBD with switch-branch the active DHCPv6 Leases does not return any value on either reForis or LuCI. The problem occurs for several months. Although there is IPv6 connectivity for the WAN and hosts connected to Turris Omnia. Let's say a "cosmetic" bug.![Schermata_del_2021-09-22_21-02-43](/uploads/9de24aafd371ffe6cd81ae28df246687/Schermata_del_2021-09-22_21-02-43.png)