Turris OS packages issueshttps://gitlab.nic.cz/turris/os/packages/-/issues2020-07-23T14:00:45+02:00https://gitlab.nic.cz/turris/os/packages/-/issues/413kresd: Crashes after updating Turris OS 3.11.5 RC2020-07-23T14:00:45+02:00Lukas Jelinekkresd: Crashes after updating Turris OS 3.11.5 RCAfter a clean installation of Turris OS 3.11.5 RC onto Omnia everything around DNS resolving works fine. But after the first update and reboot the DNS resolver (kresd) crashes on start with the following message:
`Error relocating /usr/...After a clean installation of Turris OS 3.11.5 RC onto Omnia everything around DNS resolving works fine. But after the first update and reboot the DNS resolver (kresd) crashes on start with the following message:
`Error relocating /usr/lib/libdnssec.so.6: gnutls_privkey_sign_data2: symbol not found`
It means that DNS resolving does not work at all. Doesn't matter whether DNSSEC is enabled or disable, the same applies for DNS over TLS.
Steps to reproduce:
1. Install 3.11.5 RC onto Omnia.
2. Pass through the guided setup. Enable automatic updates at the appropriate screen.
3. Wait until the update process finishes.
4. Reboot the router.Michal HruseckyMichal Hruseckyhttps://gitlab.nic.cz/turris/os/packages/-/issues/405[syslog-ng] stop | restart not working2019-06-10T13:17:06+02:00Ghost User[syslog-ng] stop | restart not working"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":"a6dba1a","target":"mvebu\/cortexa9","d..."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":"a6dba1a","target":"mvebu\/cortexa9","description":"TurrisOS 4.0-beta2 a6dba1a"}}
___
`/etc/init.d/syslog-ng stop` does not kill the process and instead it remains running. Also its `upd` socket remains alive.
Looking at with `htop` is seems that one `syslog-ng` child instance of its parent `supervising syslog-ng` gets terminated whilst a secondary child instance stays alive and the parent also does not terminate.
similar `/etc/init.d/syslog-ng restart`, the PID remains the same after the command been executed and it can be tested also by adding another destination in the syslog-ng conf. After the command been executed there is no file at the added destination. However, killing and starting the process manually the new log file is appearing at the added destination.
As a causality train post-installation scripts that restart `syslog-ng` do not report a fail of the restart whilst an actual restart did not happen. Same for logrotate with
```
postrotate
/etc/init.d/syslog-ng restart
```
Enclosed the `strace` logs for both events. [restart](/uploads/51e771530f577a017689333155122913/restart) [stop](/uploads/263831a45cf003dc26fd5bb346ac666a/stop)https://gitlab.nic.cz/turris/os/packages/-/issues/377resolver/unbound not listening on ipv6 iface2019-05-14T18:38:53+02:00Ghost Userresolver/unbound not listening on ipv6 iface@jpavlinec
TOS 3.11.4 | unbound 1.9.1
/etc/config/resolver
```
config resolver 'common'
list interface '127.0.0.1'
list interface '192.168.112.12'
list interface '::1'
list interface 'fd30:d64c:1eed:4c3a::12'
option forward_upstre...@jpavlinec
TOS 3.11.4 | unbound 1.9.1
/etc/config/resolver
```
config resolver 'common'
list interface '127.0.0.1'
list interface '192.168.112.12'
list interface '::1'
list interface 'fd30:d64c:1eed:4c3a::12'
option forward_upstream '0'
option prefered_resolver 'unbound'
option ignore_root_key '0'
option static_domains '1'
option dynamic_domains '1'
option keyfile '/etc/root.keys'
config resolver 'kresd'
option rundir '/tmp/kresd'
option log_stderr '1'
option log_stdout '1'
option forks '1'
option keep_cache '1'
#option include_config '/tmp/kresd.custom.conf'
#list hostname_config '/etc/hosts'
#list rpz_file '/tmp/file.rpz'
config resolver 'unbound'
option dhcp_link 'odhcpd'
option root_hints '/etc/unbound/named.cache'
config resolver 'unbound_includes'
list include_path "/etc/unbound/unbound_srv.conf"
list include_path "/etc/unbound/unbound_ext.conf"
config resolver 'unbound_remote_control'
option control_enable 'yes'
option control_use_cert 'no'
list control_interface '::1'
list control_interface '127.0.0.1'
```
With the above config it is expected that the resolver/unbound would be listening on the respective ipv4/ipv6 ifaces/addresses but it is only listening on the listed ipv4 ifaces/addresses but not on the ipv6.
![listening_ports](/uploads/74f0d80b246c432d69b6956d7a25c11e/listening_ports.png)Jan PavlinecJan Pavlinechttps://gitlab.nic.cz/turris/os/packages/-/issues/364keepalived: requires kmod-nf-ipvs2023-08-16T14:57:32+02:00Jan Pavlineckeepalived: requires kmod-nf-ipvsThis requirement prevents new keepalived from installing
Related forum topic https://forum.turris.cz/t/keepalived-depends-on-kmod-nf-ipvs-which-is-not-available/10036This requirement prevents new keepalived from installing
Related forum topic https://forum.turris.cz/t/keepalived-depends-on-kmod-nf-ipvs-which-is-not-available/10036https://gitlab.nic.cz/turris/os/packages/-/issues/342luci-app-wireguard: status fail to load; JavaScript error TypeError: String.f...2022-02-16T16:59:48+01:00David Beiteyluci-app-wireguard: status fail to load; JavaScript error TypeError: String.format is not a functionLoading the Wireguard status page in LuCI has worked at least once in the past, but now shows a screen stating "Collecting data...". In JavaScript, the page is making XHR requests but data processing is failing because of the following ...Loading the Wireguard status page in LuCI has worked at least once in the past, but now shows a screen stating "Collecting data...". In JavaScript, the page is making XHR requests but data processing is failing because of the following error:
```
TypeError: String.format is not a function wireguard:74:21
<anonymous> /cgi-bin/luci/admin/status/wireguard:74
onreadystatechange /luci-static/resources/xhr.js?v=git-18.328.59464-9636605:72
```
and this error occurs every few seconds as continued XHRs take place.
The issue appears to be that the JS function `String.format` from ` /www/luci-static/resources/cbi.js` isn't being loaded on this page and is thus null, causing the error. Looking into the JS that is loaded and only `xhr.js` (in the traceback above) and the inline JS on the HTML page are what's present.
I don't know the internals of LuCI or its pages, but manually defining that `String.format` function sees the rest of the page work as a test.
I'm on Turris Omnia `v3.11.2` with luci-app-wireguard version `git-18.328.59464-9636605-1`https://gitlab.nic.cz/turris/os/packages/-/issues/341ddns: writes ever 10 min to emmc2019-05-06T17:21:48+02:00Jan Pavlinecddns: writes ever 10 min to emmcIt is probably related to usage of HSTS (affected 3.x TO)
https://forum.turris.cz/t/ddns-hsts-writes-to-mmcblk0p1-every-10-minutes/9745It is probably related to usage of HSTS (affected 3.x TO)
https://forum.turris.cz/t/ddns-hsts-writes-to-mmcblk0p1-every-10-minutes/9745Jan PavlinecJan Pavlinechttps://gitlab.nic.cz/turris/os/packages/-/issues/313nut-driver-apcsmart is missing2022-02-16T17:00:28+01:00Josef Schlehofernut-driver-apcsmart is missingIn our latest releases (Turris OS 3.11.x), we don't have package nut-driver-apcsmart, which we had in past (Turris OS 3.10.x). This package is available in Turris OS 4.x.In our latest releases (Turris OS 3.11.x), we don't have package nut-driver-apcsmart, which we had in past (Turris OS 3.10.x). This package is available in Turris OS 4.x.https://gitlab.nic.cz/turris/os/packages/-/issues/312openssh client fails to listen on ipv6 socket at boot time2019-05-15T09:35:01+02:00Ghost Useropenssh client fails to listen on ipv6 socket at boot timeobserved on 3.11.2 & 3.11.3 RC | `dnsmasq` removed and `odchpd` acting as sole dhcp server for both ipv4 and ipv6
___
```
config interface 'foo'
option type 'bridge'
option proto 'static'
option ifname 'eth2.3'
option ipaddr '192.16...observed on 3.11.2 & 3.11.3 RC | `dnsmasq` removed and `odchpd` acting as sole dhcp server for both ipv4 and ipv6
___
```
config interface 'foo'
option type 'bridge'
option proto 'static'
option ifname 'eth2.3'
option ipaddr '192.168.112.12'
option netmask '255.255.255.0'
option macaddr 'd8:58:d7:00:87:5c'
list ip6addr 'fd30:d64c:1eed:4c3a::12'
```
```
config openssh
option AddressFamily any
list ListenAddress 192.168.112.12
list ListenAddress fd30:d64c:1eed:4c3a::12
```
___
upon system boot `sshd` has the ipv4 socket up but not the ipv6 socket. Once the system is fully booted the ipv6 socket for sshd becomes available *only after manually restarting/reloading* `sshd`
This likely being caused by `sshd` starting prior the releated ipv6 iface (foo) is fully up. Supposedly `sshd` should only start after the target iface is fully online.https://gitlab.nic.cz/turris/os/packages/-/issues/309ddns-scripts: ERROR : IP update not accepted by DDNS Provider2022-02-16T17:00:46+01:00Darshaka Pathiranaddns-scripts: ERROR : IP update not accepted by DDNS ProviderUpdating the IP reports an error, but the update itself is successful:
```
123228 : Waiting 600 seconds (Check Interval)
124228 : Detect registered/public IP
124228 : #> /bin/nslookup myexample.ddnss.org >/var/run/...Updating the IP reports an error, but the update itself is successful:
```
123228 : Waiting 600 seconds (Check Interval)
124228 : Detect registered/public IP
124228 : #> /bin/nslookup myexample.ddnss.org >/var/run/ddns/myddns_ipv4.dat 2>/var/run/ddns/myddns_ipv4.err
124228 : Registered IP '213.xx.xx.84' detected
124228 info : Rerun IP check at 2019-01-22 12:42
124228 : Detect local IP on 'network'
124228 : Local IP '213.xx.xx.84' detected on network 'wan'
124228 : Forced Update - L: '213.xx.xx.84' == R: '213.xx.xx.84'
124228 : #> /usr/bin/curl -RsS -o /var/run/ddns/myddns_ipv4.dat --stderr /var/run/ddns/myddns_ipv4.err --noproxy '*' 'http://ip4.ddnss.de/upd.php?user=myusername&pwd=***PW***&host=myexample.ddnss.org&ip=213.xx.xx.84'
124229 : DDNS Provider answered:
<head>
<meta name="robots" content="noindex">
<title>DDNSS - Kostenloser DynDNS Service : Re-ProutDNS v5.01v</title>
</head>
<body>
<p><font face="Verdana" size="2"></font></p>
<p><font face="Verdana" size="2">Updated 1 hostname.</font></p>
</body>
124229 ERROR : IP update not accepted by DDNS Provider
124229 : Waiting 600 seconds (Check Interval)
```
I've created an upstream issue: https://github.com/openwrt/packages/issues/8013
I am not sure, if this can be fixed on our side until it is fixed on upstream.https://gitlab.nic.cz/turris/os/packages/-/issues/308provide dependant for open-plc-utils-mdiogen2019-07-08T11:07:17+02:00Ghost Userprovide dependant for open-plc-utils-mdiogenWith `open-plc-utils-mdiogen` available in the TOS 3.11.2 repo its dependant is missing however
> ERROR:
> inconsistent: Package open-plc-utils-mdiogen *requires package open-plc-utils that is not available*.With `open-plc-utils-mdiogen` available in the TOS 3.11.2 repo its dependant is missing however
> ERROR:
> inconsistent: Package open-plc-utils-mdiogen *requires package open-plc-utils that is not available*.https://gitlab.nic.cz/turris/os/packages/-/issues/305nextcloud (15.0.2) occ command broken due to missing php on PATH2022-02-16T17:01:02+01:00cmacq2nextcloud (15.0.2) occ command broken due to missing php on PATHThe `occ` script to manage the nextcloud from the command line has the following shebang: `#!/usr/bin/env php`
Checking over SSH, `$PATH` is set to: `/usr/bin:/usr/sbin:/bin:/sbin` and `which php` cannot find a `php` executable.
A fix c...The `occ` script to manage the nextcloud from the command line has the following shebang: `#!/usr/bin/env php`
Checking over SSH, `$PATH` is set to: `/usr/bin:/usr/sbin:/bin:/sbin` and `which php` cannot find a `php` executable.
A fix could be to add symlink: `ln -s /usr/bin/php-cli /usr/bin/php`.Michal HruseckyMichal Hruseckyhttps://gitlab.nic.cz/turris/os/packages/-/issues/304nextcloud (15.0.2) lighttpd configuration broken2021-11-08T09:26:29+01:00cmacq2nextcloud (15.0.2) lighttpd configuration brokenUpgraded nextcloud from 14.06 to 15.02. The security check now complains about a missing `Referrer-Policy` header when, in fact, two `Referrer-Policy` headers are sent by the server.
It looks like as of 15.02 the previous fix for `/etc/...Upgraded nextcloud from 14.06 to 15.02. The security check now complains about a missing `Referrer-Policy` header when, in fact, two `Referrer-Policy` headers are sent by the server.
It looks like as of 15.02 the previous fix for `/etc/lighttpd/conf.d/nextcloud` to add this header is no longer applicable:
```
alias.url += ( "/nextcloud" => "/srv/www/nextcloud" )
$HTTP["url"] =~ "^/nextcloud" {
# Add 'X-Frame-Options' header, making sure it the website is not embedded in a frame or iframe.
# This avoids clickjacking, and might be helpfull for HTTPS websites
# As frames are not used nowadays, this should be safe to enable at least SAMEORIGIN
# Other option might be DENY or ALLOW-FROM. DENY is not used as frame is used in some old LuCI modules
#setenv.add-response-header += ( "X-Frame-Options" => "SAMEORIGIN")
setenv.add-response-header += ( "Referrer-Policy" => "no-referrer")
}
$HTTP["url"] =~ "^/nextcloud/(build|tests|config|lib|3rdparty|templates|data)" {
url.access-deny = ("")
}
```
Should now probably be:
```
alias.url += ( "/nextcloud" => "/srv/www/nextcloud" )
$HTTP["url"] =~ "^/nextcloud/(build|tests|config|lib|3rdparty|templates|data)" {
url.access-deny = ("")
}
```https://gitlab.nic.cz/turris/os/packages/-/issues/293nextcloud installation failing due to missing dependant perlbase-utf82023-08-01T11:53:49+02:00Ghost Usernextcloud installation failing due to missing dependant perlbase-utf8Reported in [TO forum](https://forum.turris.cz/t/nextcloud-error-installation/8765) the NC installation fails apparently due to missing the dependant `perlbase-utf8`. Installing `perlbase-utf8` appears to resolve the issue.
![c8ae1b7dfa...Reported in [TO forum](https://forum.turris.cz/t/nextcloud-error-installation/8765) the NC installation fails apparently due to missing the dependant `perlbase-utf8`. Installing `perlbase-utf8` appears to resolve the issue.
![c8ae1b7dfaf4a3d01899081fbba946600486481e](/uploads/3eec960bf39467c8588553ed16913f0f/c8ae1b7dfaf4a3d01899081fbba946600486481e.png)Michal HruseckyMichal Hruseckyhttps://gitlab.nic.cz/turris/os/packages/-/issues/291static route not being applied when a four 8-bit octets ipv4 subnet mask is set2019-06-05T19:03:24+02:00Ghost Userstatic route not being applied when a four 8-bit octets ipv4 subnet mask is setTOS 3.11.1
Adding a static subnet route via LuCI or ssh file edit the route is not applied when a subnet mask is set via four 8-bit octets. The route however is applied if the netmask is omitted and 255.255.255.255 is assumed and thus m...TOS 3.11.1
Adding a static subnet route via LuCI or ssh file edit the route is not applied when a subnet mask is set via four 8-bit octets. The route however is applied if the netmask is omitted and 255.255.255.255 is assumed and thus makes the target subnet a host address instead of a subnet.
According to the [upstream documentation](https://openwrt.org/docs/guide-user/network/routes_configuration) the syntax for subnets in ipv4 and ipv6 differs and yet seems that the ipv4 subnet mask for the target network receives the same parsing treatment as ipv6, i.e not as four 8-bit octets but its equivalent integer.
Not working (though it would be expected)
```
config route
option interface 'foobar'
option target 'ip'
option gateway 'ip'
option netmask ‘255.255.255.0’
```
Working instead (which is rather unexpected)
```
config route
option interface 'foobar'
option target 'ip/24'
option gateway 'ip'
```
Not sure whether it is a bug or by design and latter not having made into the documentation.
TO forum cross reference https://forum.turris.cz/t/static-route-not-applied/8525https://gitlab.nic.cz/turris/os/packages/-/issues/290provide dependant for luci-app-wifischedule2019-05-14T18:50:05+02:00Ghost Userprovide dependant for luci-app-wifischeduleWith `luci-app-wifischedule` available in the TOS 3.11.1 repo [its dependant](https://github.com/openwrt/packages/tree/openwrt-18.06/net/wifischedule) is missing however
> ERROR:
> inconsistent: Package luci-app-wifischedule requires pa...With `luci-app-wifischedule` available in the TOS 3.11.1 repo [its dependant](https://github.com/openwrt/packages/tree/openwrt-18.06/net/wifischedule) is missing however
> ERROR:
> inconsistent: Package luci-app-wifischedule requires package wifischedule that is not available.Jan PavlinecJan Pavlinechttps://gitlab.nic.cz/turris/os/packages/-/issues/289ntpd package collision with busybox-ntpd2019-07-31T14:23:31+02:00Ghost Userntpd package collision with busybox-ntpdhappning since TOS 3.11
according to [upstream documentation](https://openwrt.org/docs/guide-user/services/ntp/client-server) and since both, upstream and downstream, repos featuring/serving the [ntpd package](https://downloads.openwrt....happning since TOS 3.11
according to [upstream documentation](https://openwrt.org/docs/guide-user/services/ntp/client-server) and since both, upstream and downstream, repos featuring/serving the [ntpd package](https://downloads.openwrt.org/releases/18.06.1/packages/arm_cortex-a9/packages/ntpd_4.2.8p11-1_arm_cortex-a9.ipk) it would be expected to be able to install said package. However, which worked prior to TOS 3.11 is now producing:
> INFO:Checking for file collisions between packages
> line not found
> line not found
> line not found
> line not found
> line not found
> line not found
> DIE:
> [string "transaction"]:323: [string "transaction"]:149: **Collisions**:
> • /sbin/ntpd: busybox (existing-file), ntpd (new-file)
> Aborted
[cross reference TO forum](https://forum.turris.cz/t/installing-ntpd-on-turrisos/8912/3)https://gitlab.nic.cz/turris/os/packages/-/issues/285provide package from upstream for running unpriviliged lxc containers on the TO2019-06-05T18:48:15+02:00Ghost Userprovide package from upstream for running unpriviliged lxc containers on the TOApparently [this package](https://downloads.openwrt.org/releases/18.06.1/packages/arm_cortex-a9/packages/lxc-unprivileged_2.1.1-2_arm_cortex-a9.ipk) being essential for running unprivilged containers on OpenWRT, however it appears absent...Apparently [this package](https://downloads.openwrt.org/releases/18.06.1/packages/arm_cortex-a9/packages/lxc-unprivileged_2.1.1-2_arm_cortex-a9.ipk) being essential for running unprivilged containers on OpenWRT, however it appears absent from the TO repo.
cross reference https://patchwork.ozlabs.org/patch/844848/
It would nessessitate an up to date shadow package https://patchwork.ozlabs.org/patch/837829/ for newgidmap and newuidmap mapping.https://gitlab.nic.cz/turris/os/packages/-/issues/283lxc.utsname not being parsed into container's hostname2019-05-06T17:21:52+02:00Ghost Userlxc.utsname not being parsed into container's hostnameWith the container's config `lxc.utsname = foobar` it would be expected that the container's hostname would be matching `foobar` (parsed into hostname file of the respective container).
However, having tested various container installat...With the container's config `lxc.utsname = foobar` it would be expected that the container's hostname would be matching `foobar` (parsed into hostname file of the respective container).
However, having tested various container installation the hostname ends up being the standard one of the respective distro, e.g. this one ArchLinux
https://forum.turris.cz/uploads/default/original/2X/8/824139afea2ab70c51fc45b12a92292fe3297e8b.png
TOS RC 3.11.1 |
liblxc 1.1.5-15 |
luci-app-lxc 20160616-1 |
lxc 1.1.5-15 |
lxc-attach 1.1.5-15 |
lxc-auto 1.1.5-15 |
lxc-autostart 1.1.5-15 |
lxc-cgroup 1.1.5-15 |
lxc-checkconfig 1.1.5-15 |
lxc-clone 1.1.5-15 |
lxc-common 1.1.5-15 |
lxc-config 1.1.5-15 |
lxc-configs 1.1.5-15 |
lxc-console 1.1.5-15 |
lxc-create 1.1.5-15 |
lxc-destroy 1.1.5-15 |
lxc-device 1.1.5-15 |
lxc-execute 1.1.5-15 |
lxc-freeze 1.1.5-15 |
lxc-hooks 1.1.5-15 |
lxc-info 1.1.5-15 |
lxc-init 1.1.5-15 |
lxc-ls 1.1.5-15 |
lxc-lua 1.1.5-15 |
lxc-monitor 1.1.5-15 |
lxc-monitord 1.1.5-15 |
lxc-snapshot 1.1.5-15 |
lxc-start 1.1.5-15 |
lxc-stop 1.1.5-15 |
lxc-templates 1.1.5-15 |
lxc-unfreeze 1.1.5-15 |
lxc-unshare 1.1.5-15 |
lxc-user-nic 1.1.5-15 |
lxc-usernsexec 1.1.5-15 |
lxc-wait 1.1.5-15 |
rpcd-mod-lxc 20141012https://gitlab.nic.cz/turris/os/packages/-/issues/282static DHCP lease times neglected2019-08-03T17:16:49+02:00Ghost Userstatic DHCP lease times neglectedTOS RC 3.11.1 | dnsmasq-full 2.78-3
"/etc/config/dhcp"
```
config dhcp 'lan'
option leasetime '1h'
config host
option leasetime '7d'
```
The lease time for the host does not exceed 1h from the lan setting. It would be expected that...TOS RC 3.11.1 | dnsmasq-full 2.78-3
"/etc/config/dhcp"
```
config dhcp 'lan'
option leasetime '1h'
config host
option leasetime '7d'
```
The lease time for the host does not exceed 1h from the lan setting. It would be expected that lease times set for hosts are honoured.https://gitlab.nic.cz/turris/os/packages/-/issues/280sfdisk build config2019-05-06T17:21:53+02:00Ghost Usersfdisk build configTOS 3.11 stable | sfdisk 2.29.2-1
`sfdisk`
```
/usr/sbin/sfdisk: line 143: /home/beast/beast/workspace/omnia-master/staging_dir/host/bin/sed: No such file or directory
/usr/sbin/sfdisk: line 147: /home/beast/beast/workspace/omnia-master...TOS 3.11 stable | sfdisk 2.29.2-1
`sfdisk`
```
/usr/sbin/sfdisk: line 143: /home/beast/beast/workspace/omnia-master/staging_dir/host/bin/sed: No such file or directory
/usr/sbin/sfdisk: line 147: /home/beast/beast/workspace/omnia-master/staging_dir/host/bin/sed: No such file or directory
/usr/sbin/sfdisk: line 199: cd: /home/beast/beast/workspace/omnia-master/build_dir/target-arm_cortex-a9+vfpv3_musl-1.1.15_eabi/util-linux-2.29.2: No such file or directory
/usr/sbin/sfdisk: line 199: ccache_cc: command not found
```Jan PavlinecJan Pavlinec