Turris Build issueshttps://gitlab.nic.cz/turris/os/build/-/issues2024-03-04T18:10:59+01:00https://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/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/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/42sysntpd working?2023-08-16T11:07:38+02:00Ghost Usersysntpd working?{"kernel":"4.14.113","hostname":"to","system":"ARMv7 Processor rev 1 (v7l)","model":"Turris Omnia","board_name":"armada-385-turris-omnia","release":{"distribution":"TurrisOS","version":"4.0-beta1","revision":"0663455801","target":"mvebu/...{"kernel":"4.14.113","hostname":"to","system":"ARMv7 Processor rev 1 (v7l)","model":"Turris Omnia","board_name":"armada-385-turris-omnia","release":{"distribution":"TurrisOS","version":"4.0-beta1","revision":"0663455801","target":"mvebu/cortexa9","description":"TurrisOS 4.0-beta1 0663455801"}}
- using `odhcpd` for ipv4 and ipv6
___
forum cross refrence https://forum.turris.cz/t/turris-os-4-0-beta1-is-released/10107/76
I am concerned that `sysntpd` is not working, both client and server.
With the client side, which is most important, there is no indication in the logs that the time is being synchronized with the specified upstream servers, e.g. via /foris/config/main/time/ > Update Time.
Is there any way via cli to run the client and see the output, could not find any pertaining documentation? Or any other way to know that client is working or when last sync happened?
___
With the server side up/running
`ss -tulpn | grep ntp`
> udp UNCONN 0 0 *:123 : users:((“ntpd”,pid=10918,fd=3))
`ntpq -p` is producing
> localhost: timed out, nothing received
> ***Request timed out
In addition the server should not be listening globally but on `dhcp_interface`, if `list interface` is omitted from /etc/config/system then on every interface or else on the specified interface. But apparently it does not.https://gitlab.nic.cz/turris/os/build/-/issues/29block: hotplug-call fails during update2023-08-16T11:07:36+02:00Ghost Userblock: hotplug-call fails during update> {"kernel":"4.14.121","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":"07918c2","target":"mvebu\/...> {"kernel":"4.14.121","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":"07918c2","target":"mvebu\/cortexa9","description":"TurrisOS 4.0-beta2 07918c2"}}
___
Appears to be a causal train:
In order to mitigate writes to the device's internal drive `unbound`'s log log is written to a `btrfs` partition on an internal ssd.
Updating from beta 1 to beta 2 (`switch-branch` hbk) `kmod-fs-btrfs` get updated and said `btrfs` partition unmounted and thus `unbound`'s log file location becomes unavailable, resulting in:
> + /usr/share/unbound/postinst
> + /etc/init.d/resolver restart
> /logs/unbound: No such file or directory
> [1559501610] unbound-checkconf[29119:0] fatal error: logfile directory does not exist
> + sleep 20
> + /etc/init.d/resolver restart
> /logs/unbound: No such file or directory
> [1559501632] unbound-checkconf[29464:0] fatal error: logfile directory does not exist
The next and subsequent casualty is
> curl: (6) Couldn't resolve host 'api.turris.cz'
and finally
> Updater execution exited with error. Please see previous output to know what went wrong.
___
I suppose that is something that won't fix, but at least for your info.https://gitlab.nic.cz/turris/os/build/-/issues/27[potential CVE-2019-11477] frequent unattended/uninitiated reboots2023-08-16T11:07:32+02:00Ghost User[potential CVE-2019-11477] frequent unattended/uninitiated reboots> {"kernel":"4.14.121","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":"d1f130a","target":"mvebu\/...> {"kernel":"4.14.121","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":"d1f130a","target":"mvebu\/cortexa9","description":"TurrisOS 4.0-beta2 d1f130a"}}
___
Since having switched to hbk (beta 2) at least 2 unattended/uninitiated reboots within a period of 12 hours been observed.
Whilst retaining a copy of the syslog past reboots there is no indication of what might have triggered such unattended/uninitiated reboots.
Beyond the syslog retention I do not know of how to provide additional information on the matter.
Such reboots were not observed with TOS versions prior to beta 2https://gitlab.nic.cz/turris/os/build/-/issues/31[lxc] configuring kernel parameters container fails2023-08-16T11:07:31+02:00Ghost User[lxc] configuring kernel parameters container fails> {"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":"e403e59","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":"e403e59","target":"mvebu\/cortexa9","description":"TurrisOS 4.0-beta2 e403e59"}}
___
It would be expected that `lxc.sysctl.[kernel parameters name]` (https://linuxcontainers.org/lxc/manpages/man5/lxc.container.conf.5.html) to work.
For instance add `lxc.sysctl.net.ipv4.tcp_window_scaling = 1` to the container config and booting a privileged container (in this instance ubuntu disco) and fails
> lxc-start test 20190606080720.800 ERROR conf - conf.c:setup_sysctl_parameters:2638 - Failed to setup sysctl parameters net.ipv4.tcp_window_scaling to 1
> lxc-start test 20190606080720.800 ERROR conf - conf.c:lxc_setup:3670 - Failed to setup sysctl parameters
> lxc-start test 20190606080720.801 ERROR start - start.c:do_start:1263 - Failed to setup container "test"
> lxc-start test 20190606080720.801 ERROR sync - sync.c:__sync_wait:62 - An error occurred in another process (expected sequence number 5)https://gitlab.nic.cz/turris/os/build/-/issues/60Turris OS 4.0 beta5 : fiber optic sfp module not working2023-08-16T11:07:29+02:00Claude NobsTurris OS 4.0 beta5 : fiber optic sfp module not workingkernel message regarding eth2 with sfp module connected:
```
[ 4.404199] mvneta f1034000.ethernet eth2: Using hardware mac address d8:58:d7:00:30:2e
...
[ 59.122698] mvneta f1034000.ethernet eth2: PHY [f1072004.mdio-mii:01] driver [...kernel message regarding eth2 with sfp module connected:
```
[ 4.404199] mvneta f1034000.ethernet eth2: Using hardware mac address d8:58:d7:00:30:2e
...
[ 59.122698] mvneta f1034000.ethernet eth2: PHY [f1072004.mdio-mii:01] driver [Marvell 88E1510]
[ 59.131476] mvneta f1034000.ethernet eth2: configuring for phy/sgmii link mode
[ 59.139119] IPv6: ADDRCONF(NETDEV_UP): eth2: link is not ready
```
connected to a tp-link mc220l sfp to gbase-t converter and then to the omnia's gbase-t wan port it's workinghttps://gitlab.nic.cz/turris/os/build/-/issues/65Turris 4.0b5 - storage foris plugin broken2023-08-16T11:07:27+02:00Claude NobsTurris 4.0b5 - storage foris plugin brokenstorage plugin does not seem to work properly.
after selecting disk, pressing format & set as well as rebooting i got the following state :
![image](/uploads/ab5f8ec7ee013392378b411f82766b65/image.png)
- `ssh omnia mount` not showing /...storage plugin does not seem to work properly.
after selecting disk, pressing format & set as well as rebooting i got the following state :
![image](/uploads/ab5f8ec7ee013392378b411f82766b65/image.png)
- `ssh omnia mount` not showing /dev/sda as mounted
- `/dev/sda` being reformatted & subvolume `@` created
- `/etc/config/storage` having the following entry :
```
config srv 'srv'
option old_uuid '14b35544-0fc8-4e09-881d-e63bce1fd6c6'
option uuid 'b7aa0ae4-506b-4b51-9926-21ed96c47818'
```
AFAIK the script called from foris works, but `/etc/config/storage` never gets read/acted upon
my current workaround is adding the disk to /etc/config/fstab :
```
config 'mount'
option target '/srv'
option uuid 'b7aa0ae4-506b-4b51-9926-21ed96c47818'
option options 'defaults,subvol=@'
```
after that it shows correctly in foris :
![image](/uploads/354eb8a650ddc7f3c26a6a5b9147fa31/image.png)Michal HruseckyMichal Hruseckyhttps://gitlab.nic.cz/turris/os/build/-/issues/73USB booting (kmodloader) fails discovery of /lib/modules/$(uname -r)2023-08-16T11:07:25+02:00Ghost UserUSB booting (kmodloader) fails discovery of /lib/modules/$(uname -r)> {"kernel":"4.14.138","hostname":"turris","system":"ARMv7 Processor rev 1 (v7l)","model":"Turris Omnia","board_name":"armada-385-turris-omnia","release":{"distribution":"TurrisOS","version":"4.0-beta9","revision":"**9d6cfa2**","target":...> {"kernel":"4.14.138","hostname":"turris","system":"ARMv7 Processor rev 1 (v7l)","model":"Turris Omnia","board_name":"armada-385-turris-omnia","release":{"distribution":"TurrisOS","version":"4.0-beta9","revision":"**9d6cfa2**","target":"mvebu\/cortexa9","description":"TurrisOS 4.0-beta9 9d6cfa2"}}
____
reproduced on repeated attempts to setup from maiden medkit with PPPoE -> see log [log](/uploads/7a833d7ac4f1a41c05dea689c374a5c7/log)https://gitlab.nic.cz/turris/os/build/-/issues/89Connection problem on Omnia SFP-WAN2023-08-16T11:07:23+02:00Giuseppe PiscitelliConnection problem on Omnia SFP-WANHaving updated my Omnia to the 4.0.1 version of Turris OS I can no longer set up a working connection using the operator's SFP module in the router cage. In fact, by setting eth2 as eth2.835 (number requested by the ISP), PPPoE authentic...Having updated my Omnia to the 4.0.1 version of Turris OS I can no longer set up a working connection using the operator's SFP module in the router cage. In fact, by setting eth2 as eth2.835 (number requested by the ISP), PPPoE authentication fails. There are a few hypotheses:
1) the problem is related to the switch / vlan limited on OS 4.x and Omnia;
2) incompatibility of the SFP with the new version of the operating system (although it is recognized by dmesg).
Below are the diagnostic links on 4.x configured and not working and 3.11.8 configured and working. I hope you can understand more than me. For any further information do not hesitate to ask.
[4.0.1.gz](/uploads/9ea1fa647fc3c42439b9301ad40880bc/4.0.1.gz)
[3.11.8.gz](/uploads/f8dd61251c38ac4772c3d2cbeb52b3e7/3.11.8.gz)https://gitlab.nic.cz/turris/os/build/-/issues/116Installation of pkglist hardening results in router softblock2023-08-16T11:07:21+02:00Karel KociInstallation of pkglist hardening results in router softblockInstalling hardening I managed to get system to state where most of the processes were failing to run correctly. Router was clearly running but processes such as lighttpd or dnsmasq were taking together full system load and router was ac...Installing hardening I managed to get system to state where most of the processes were failing to run correctly. Router was clearly running but processes such as lighttpd or dnsmasq were taking together full system load and router was accessible only trough console. It is possible that processes as SSH were affected by that as well and something prevented them to run correctly. I had to do forced reboot (`/proc/sysrq-trigger`). After that reboot issue was gone.
I suspect that problem is with initial installation of hardening components to running system and application of them on first boot.Turris OS 5.0.1Jan PavlinecJan Pavlinechttps://gitlab.nic.cz/turris/os/build/-/issues/71It is not possible to switch to non-ct drivers on Mox2023-08-16T11:06:43+02:00Karel KociIt is not possible to switch to non-ct drivers on MoxWe marked ct drivers as critical in updater base-min list. This makes it impossible to switch to non-ct drivers as they do not provide them.
Fix should be that we have non-ct drivers requested criticaly and on Mox we would have addition...We marked ct drivers as critical in updater base-min list. This makes it impossible to switch to non-ct drivers as they do not provide them.
Fix should be that we have non-ct drivers requested criticaly and on Mox we would have additional regular request for ct drivers.
Reported: https://forum.turris.cz/t/forcing-packages-to-not-install-in-4-0/10796https://gitlab.nic.cz/turris/os/build/-/issues/92OPKG fails to update feeds when `wget-nossl` is installed2023-08-16T11:06:39+02:00Karel KociOPKG fails to update feeds when `wget-nossl` is installedThis is common problem from all version os OpenWrt but for some reason developers of OPKG decided that when wget is installed then they stop using their own `uclient-fetch` and instead use wget. Before `uclient-fetch` there was a warning...This is common problem from all version os OpenWrt but for some reason developers of OPKG decided that when wget is installed then they stop using their own `uclient-fetch` and instead use wget. Before `uclient-fetch` there was a warning that `wget` does not support SSL and graceful failure but now there is just error and no info.
Just forcing `wget-nossl` to not ever be installed should be enough to fix this.https://gitlab.nic.cz/turris/os/build/-/issues/100Omnia gets stuck during boot in case of broken atsha chip2023-08-16T11:06:37+02:00Jan PavlinecOmnia gets stuck during boot in case of broken atsha chipI'm not sure how valid is this issue. But in case of broken atsha chip, Omnia gets stucks during boot because it waits for entropy for **Lighttpd cert generation**.
Script responsible for this is in /etc/default-uci, so maybe a solutio...I'm not sure how valid is this issue. But in case of broken atsha chip, Omnia gets stucks during boot because it waits for entropy for **Lighttpd cert generation**.
Script responsible for this is in /etc/default-uci, so maybe a solution could be to ensure that haveged is running before running scripts from there...Turris OS 5.0https://gitlab.nic.cz/turris/os/build/-/issues/130Turris 1.x has only 752M RAM2023-08-16T11:06:31+02:00Josef SchlehoferTurris 1.x has only 752M RAM![image](/uploads/3571c6c392d7ca160aff97e3d4b75daa/image.png)![image](/uploads/3571c6c392d7ca160aff97e3d4b75daa/image.png)Turris OS 5.0https://gitlab.nic.cz/turris/os/build/-/issues/143SSLError when using pip3 install2023-08-16T11:06:27+02:00Josef SchlehoferSSLError when using pip3 installSimilar to issue turris-os-packages#569 I am not able to use pip3 install multidict as it fails due to SSLError.
```
root@turris:~# pip3 install multidict
Collecting multidict
WARNING: Retrying (Retry(total=4, connect=None, read=None,...Similar to issue turris-os-packages#569 I am not able to use pip3 install multidict as it fails due to SSLError.
```
root@turris:~# pip3 install multidict
Collecting multidict
WARNING: Retrying (Retry(total=4, connect=None, read=None, redirect=None, status=None)) after connection broken by 'SSLError(SSLError(1, '[SSL: DECRYPTION_FAILED_OR_BAD_RECORD_MAC] decryption failed or bad record mac (_ssl.c:1076)'))': /simple/multidict/
WARNING: Retrying (Retry(total=3, connect=None, read=None, redirect=None, status=None)) after connection broken by 'SSLError(SSLError(1, '[SSL: DECRYPTION_FAILED_OR_BAD_RECORD_MAC] decryption failed or bad record mac (_ssl.c:1076)'))': /simple/multidict/
WARNING: Retrying (Retry(total=2, connect=None, read=None, redirect=None, status=None)) after connection broken by 'SSLError(SSLError(1, '[SSL: DECRYPTION_FAILED_OR_BAD_RECORD_MAC] decryption failed or bad record mac (_ssl.c:1076)'))': /simple/multidict/
WARNING: Retrying (Retry(total=1, connect=None, read=None, redirect=None, status=None)) after connection broken by 'SSLError(SSLError(1, '[SSL: DECRYPTION_FAILED_OR_BAD_RECORD_MAC] decryption failed or bad record mac (_ssl.c:1076)'))': /simple/multidict/
WARNING: Retrying (Retry(total=0, connect=None, read=None, redirect=None, status=None)) after connection broken by 'SSLError(SSLError(1, '[SSL: DECRYPTION_FAILED_OR_BAD_RECORD_MAC] decryption failed or bad record mac (_ssl.c:1076)'))': /simple/multidict/
Could not fetch URL https://pypi.org/simple/multidict/: There was a problem confirming the ssl certificate: HTTPSConnectionPool(host='pypi.org', port=443): Max retries exceeded with url: /simple/multidict/ (Caused by SSLError(SSLError(1, '[SSL: DECRYPTION_FAILED_OR_BAD_RECORD_MAC] decryption failed or bad record mac (_ssl.c:1076)'))) - skipping
```
This happens just on Turris 1.x. It works OOTB on Turris Omnia.Turris OS 5.0.2https://gitlab.nic.cz/turris/os/build/-/issues/38Guest network isolation is broken in 3.11.4 and 4b22023-08-16T11:05:43+02:00Ghost UserGuest network isolation is broken in 3.11.4 and 4b2More info:
https://forum.turris.cz/t/guest-network-wi-fi-1-wi-fi-2-isolation-issue/10343/
https://forum.openwrt.org/t/client-isolation/13914/27
A workaround for v3.11.4 and 4.x (the latest one need kmod-br-netfilter to be installed)
...More info:
https://forum.turris.cz/t/guest-network-wi-fi-1-wi-fi-2-isolation-issue/10343/
https://forum.openwrt.org/t/client-isolation/13914/27
A workaround for v3.11.4 and 4.x (the latest one need kmod-br-netfilter to be installed)
```
echo 1 > /sys/class/net/br-guest_turris/bridge/nf_call_iptables
echo 1 > /sys/class/net/br-guest_turris/bridge/nf_call_ip6tables
```Štěpán HenekŠtěpán Henekhttps://gitlab.nic.cz/turris/os/build/-/issues/58Turris MOX kernel 5.4 support2023-08-16T11:05:39+02:00Karel KociTurris MOX kernel 5.4 supportPort patches (or rather create new patch set) for Turris Mox kernel 5.4.
Upstream switched kernel version for mvebu in master to version 5.4. We still have patches for 4.14 so we should go trough them and port patches we need to 5.4Port patches (or rather create new patch set) for Turris Mox kernel 5.4.
Upstream switched kernel version for mvebu in master to version 5.4. We still have patches for 4.14 so we should go trough them and port patches we need to 5.4Marek BehunMarek Behun