Turris OS packages issueshttps://gitlab.nic.cz/turris/os/packages/-/issues2024-03-12T15:02:18+01:00https://gitlab.nic.cz/turris/os/packages/-/issues/855Turris 1.x zImage is not updated while updating to newer version2024-03-12T15:02:18+01:00Josef SchlehoferTurris 1.x zImage is not updated while updating to newer versionIssue: zImage is not updated in ``/dev/mmcblk0p1``, but it is updated in ``/dev/mmcblk0p2``
This results to hiccup when the kernel is updated, but you are running older version of kernel.
```
root@turris:~# uname -a
Linux turris 4.14....Issue: zImage is not updated in ``/dev/mmcblk0p1``, but it is updated in ``/dev/mmcblk0p2``
This results to hiccup when the kernel is updated, but you are running older version of kernel.
```
root@turris:~# uname -a
Linux turris 4.14.294 #0 SMP Tue Sep 27 03:45:29 2022 ppc GNU/Linux
root@turris:~# opkg list-installed | grep kernel
kernel - 5.10.147-1-42186e8efb70da7a8430b969416854a2
```
Maybe solution:
1. ~~Run `usr/sbin/turris1x-btrfs-kernel-install` in postinst script of turris1x-btrfs~~
Workaround: run ``pkgupdate``, reboot and that's it.Turris OS 6.0.2Michal HruseckyMichal Hruseckyhttps://gitlab.nic.cz/turris/os/packages/-/issues/944Knot Resolvers in Turris OS 7.02024-03-04T10:08:34+01:00Michal HruseckyKnot Resolvers in Turris OS 7.0Users reported problems with knot-resolver in Turris OS 7.0 RC, we should investigate.
https://forum.turris.cz/t/turris-os-7-0-is-in-rc/19755/7Users reported problems with knot-resolver in Turris OS 7.0 RC, we should investigate.
https://forum.turris.cz/t/turris-os-7-0-is-in-rc/19755/7Turris OS 7.0Michal HruseckyMichal Hruseckyhttps://gitlab.nic.cz/turris/os/packages/-/issues/857Omnia LEDs migrate can not access new sysfs files in postinst2022-10-20T06:06:45+02:00Josef SchlehoferOmnia LEDs migrate can not access new sysfs files in postinst```
fix-omnia-leds-migrate/postinst: Command failed: Not found
/usr/libexec/rainbow/led_activity.sh: line 165: /sys/class/leds/rgb:wan/trigger: No such file or directory
grep: /sys/class/leds/rgb:wan/trigger: No such file or directory
Wa...```
fix-omnia-leds-migrate/postinst: Command failed: Not found
/usr/libexec/rainbow/led_activity.sh: line 165: /sys/class/leds/rgb:wan/trigger: No such file or directory
grep: /sys/class/leds/rgb:wan/trigger: No such file or directory
Warning: activity setup failed for: wan
/usr/libexec/rainbow/led_activity.sh: line 165: /sys/class/leds/rgb:wlan-1/trigger: No such file or directory
grep: /sys/class/leds/rgb:wlan-1/trigger: No such file or directory
Warning: activity setup failed for: wlan-1
/usr/libexec/rainbow/led_activity.sh: line 165: /sys/class/leds/rgb:wlan-2/trigger: No such file or directory
grep: /sys/class/leds/rgb:wlan-2/trigger: No such file or directory
Warning: activity setup failed for: wlan-2
/usr/libexec/rainbow/led_activity.sh: line 165: /sys/class/leds/rgb:wlan-3/trigger: No such file or directory
grep: /sys/class/leds/rgb:wlan-3/trigger: No such file or directory
Warning: activity setup failed
```Turris OS 6.0.1https://gitlab.nic.cz/turris/os/packages/-/issues/850Rainbow: reconsider versioning for all three routers2022-09-16T14:03:23+02:00Josef SchlehoferRainbow: reconsider versioning for all three routersWhile reviewing https://gitlab.nic.cz/turris/os/packages/-/merge_requests/966, I noticed that we need to edit all three Makefiles if we bump rainbow-ng.
You should consider similar solution how it is done for shipping Turris u-boot pack...While reviewing https://gitlab.nic.cz/turris/os/packages/-/merge_requests/966, I noticed that we need to edit all three Makefiles if we bump rainbow-ng.
You should consider similar solution how it is done for shipping Turris u-boot packages in this repository or rather proposed solution, which I got on IRC #openwrt-devel:
```
20:23:24 <pepes> Guys, I am thinking. I would like to have dedicated U-boot package installable within opkg and I could copy the U-boot image from staging_dir and put it to whatever I want. Because right now, I compiling it twice. :-( Is there way, how can I use the same versioning from different package? So, I could know the version of U-boot by opkg. Any ideas?
20:24:05 <jow> pepes: there's no clean way
20:24:23 <jow> you could define a shared .mk file that just declares the version, then include that in both places
20:25:38 <jow> or you could use a construct like PKG_VERSION:=$(if $(DUMP),x,$(shell sed -ne 's#PKG_VERSION:=##p' $(topdir)/package/boot/u-boot-foo/Makefile))
20:28:04 <pepes> Thanks jow! I will try it, but it looks like it is going to help. THanks! I will let you know about it.
```
This means use shared .mk file.Turris OS 6.0.1https://gitlab.nic.cz/turris/os/packages/-/issues/839ouidb: use full device vendor names2024-03-04T10:13:09+01:00Martin Matějekouidb: use full device vendor namesOur pre processed oui database file use only partial names - first word of the manufacture full name.
Actual notification message:
```
New device appeared on your network (MAC address aa:bb:cc:11:22:33, vendor Hewlett)
```
while ideall...Our pre processed oui database file use only partial names - first word of the manufacture full name.
Actual notification message:
```
New device appeared on your network (MAC address aa:bb:cc:11:22:33, vendor Hewlett)
```
while ideally it should look like:
```
New device appeared on your network (MAC address aa:bb:cc:11:22:33, vendor Hewlett Packard)
```
This could be most likely fixed by adjusting this regex:
https://gitlab.nic.cz/turris/os/packages/-/blob/master/utils/ouidb/Makefile#L33Turris OS 7.1.0https://gitlab.nic.cz/turris/os/packages/-/issues/831Mox autosetup: the invalid interface sfp2024-03-12T15:02:52+01:00Karel KociMox autosetup: the invalid interface sfpAccording to the @prohar the `sfp` is used only if there is DSA managed switch otherwise the port is called `eth1` thus we assign invalid interface `sfp` to `wan` in `mox_autosetup`.According to the @prohar the `sfp` is used only if there is DSA managed switch otherwise the port is called `eth1` thus we assign invalid interface `sfp` to `wan` in `mox_autosetup`.Turris OS 6.0.1Michal HruseckyMichal Hruseckyhttps://gitlab.nic.cz/turris/os/packages/-/issues/830LEDs in sys are not found in rescue2022-10-17T21:28:55+02:00Josef SchlehoferLEDs in sys are not found in rescueRescue 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 6.1.02022-08-19https://gitlab.nic.cz/turris/os/packages/-/issues/828(HBL) TOS6.0 breaks IPv6 TCP connectivity2024-03-12T14:33:18+01:00Jan Betik(HBL) TOS6.0 breaks IPv6 TCP connectivityMy setup is losing IPv6 packets. See the wireshark dump. This does not affect IPv4 services.
I have bridge VLAN filtering enabled, with VLANs 1,10,255,2006. MY laptop is connected to the `VLAN 1 access port` LAN3
/etc/config/network
```...My setup is losing IPv6 packets. See the wireshark dump. This does not affect IPv4 services.
I have bridge VLAN filtering enabled, with VLANs 1,10,255,2006. MY laptop is connected to the `VLAN 1 access port` LAN3
/etc/config/network
```
config interface 'loopback'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'
option device 'lo'
config globals 'globals'
option ula_prefix 'fd19:2:168:0::/48'
config interface 'lan'
option proto 'static'
option ip6assign '64'
list ipaddr '192.168.23.1/24'
option ip6hint 'a'
option ip6ifaceid '::23:1'
option device 'br-lan.1'
config interface 'wan'
option proto 'dhcp'
option ipv6 '1'
option device 'eth2'
option hostname 'hagridovo'
option clientid '0004eae62f0920dd43deadface38fcbd32a5'
config interface 'wan6'
option proto 'dhcpv6'
option device '@wan'
option reqaddress 'try'
option reqprefix '60'
option clientid '0004eae62f0920dd43deadface38fcbd32a5'
config device
option type 'bridge'
option name 'br-lan'
list ports 'lan0'
list ports 'lan1'
list ports 'lan2'
list ports 'lan3'
list ports 'lan4'
option bridge_empty '1'
config interface 'swan'
option proto 'static'
list ipaddr '198.19.10.1/24'
option defaultroute '0'
option ip6ifaceid '::10:1'
list ip6class 'local'
list ip6class 'wan6'
option device 'br-lan.10'
option ip6assign '62'
config interface 'smgmt'
option proto 'static'
option ip6assign '64'
option ip6hint 'd'
option ip6ifaceid '::255:1'
list ip6class 'local'
option device 'br-lan.255'
list ipaddr '192.168.1.2/24'
list ipaddr '192.168.88.2/24'
list ipaddr '192.168.0.2/24'
config device
option name 'eth2'
config device
option vid '1'
option type '8021q'
option name 'br-lan.1'
option ifname 'br-lan'
config device
option vid '10'
option type '8021q'
option name 'br-lan.10'
option ifname 'br-lan'
config device
option vid '255'
option type '8021q'
option name 'br-lan.255'
option ifname 'br-lan'
config bridge-vlan
option device 'br-lan'
option vlan '1'
list ports 'lan0:t'
list ports 'lan1:u*'
list ports 'lan2:u*'
list ports 'lan3:u*'
config bridge-vlan
option device 'br-lan'
option vlan '10'
list ports 'lan0:t'
config bridge-vlan
option device 'br-lan'
option vlan '255'
list ports 'lan0:t'
config bridge-vlan
option device 'br-lan'
option vlan '2006'
list ports 'lan4:u*'
```
[nefunguje.pcapng](/uploads/3f42ad8b955e4a62d35fe09ab47bc44c/nefunguje.pcapng)Turris OS 6.0https://gitlab.nic.cz/turris/os/packages/-/issues/822Omnia: update rescue image2022-04-06T14:20:56+02:00Josef SchlehoferOmnia: update rescue imageTurris OS 6.1.0Michal HruseckyMichal Hruseckyhttps://gitlab.nic.cz/turris/os/packages/-/issues/791Adblock package doesn't update unblock config2021-09-03T16:33:19+02:00Vlastimil ZimaAdblock package doesn't update unblock configTo make adblock work on Turris 1.X I had to append
```
config resolver 'unbound_includes'
list include_path "/var/lib/unbound/adb_list.overall"
```
to the `/etc/config/resolver`.
I suspect that adblock can update `unbound` config, but ...To make adblock work on Turris 1.X I had to append
```
config resolver 'unbound_includes'
list include_path "/var/lib/unbound/adb_list.overall"
```
to the `/etc/config/resolver`.
I suspect that adblock can update `unbound` config, but its overridden by the `resolver-conf` anyway and thus adblock stops working.Turris OS 6.2.0https://gitlab.nic.cz/turris/os/packages/-/issues/733sentinel-proxy: data sending indication (v1.5)2023-05-30T14:38:01+02:00Karel Kocisentinel-proxy: data sending indication (v1.5)The feature release that includes indication of connected collectors as well as connection to the Sentinel server.
- [ ] turris/sentinel/sentinel#26The feature release that includes indication of connected collectors as well as connection to the Sentinel server.
- [ ] turris/sentinel/sentinel#26Turris OS 6.2.0https://gitlab.nic.cz/turris/os/packages/-/issues/729foris-controller-openvpn-module: IPv6 fix listening on IPv62021-06-01T18:26:38+02:00Martin Matějekforis-controller-openvpn-module: IPv6 fix listening on IPv6Fix "listen on IPv6" feature.
- [ ] [foris-controller-openvpn-module: fix listening on IPv6](https://gitlab.nic.cz/turris/foris-controller/foris-controller-openvpn-module/-/milestones/1)Fix "listen on IPv6" feature.
- [ ] [foris-controller-openvpn-module: fix listening on IPv6](https://gitlab.nic.cz/turris/foris-controller/foris-controller-openvpn-module/-/milestones/1)Turris OS 6.1.0https://gitlab.nic.cz/turris/os/packages/-/issues/671Sentinel-firewall: move configuration from firewall section to sentinel2022-12-28T22:29:56+01:00Karel KociSentinel-firewall: move configuration from firewall section to sentinelAt the moment fw3 complains with following warnings:
```
Warning: Option @zone[1].sentinel_dynfw is unknown
Warning: Option @zone[1].sentinel_minipot is unknown
Warning: Option @zone[1].haas_proxy is unknown
Warning: Option @zone[1].sent...At the moment fw3 complains with following warnings:
```
Warning: Option @zone[1].sentinel_dynfw is unknown
Warning: Option @zone[1].sentinel_minipot is unknown
Warning: Option @zone[1].haas_proxy is unknown
Warning: Option @zone[1].sentinel_fwlogs is unknown
```
These are harmless and used by sentinel-firewall scripts but it can confuse users.
We should rather move it to sentinel config and rather link zone name from there. This requires:
* [ ] modification of code to expect config rather in sentinel configuration over firewall
* [ ] fix package to migrate existing configuration from firewall to sentinel configTurris OS 6.2.0https://gitlab.nic.cz/turris/os/packages/-/issues/627Nexcloud database error2022-12-12T15:09:32+01:00leoprosperiNexcloud database errorAfter a brand new installation of Nextcloud 17 on Turris Omnia with v5.0.3, I saw the following warning on /nextcloud/index.php/settings/admin/overview:
> Some columns in the database are missing a conversion to big int. Due to the fact...After a brand new installation of Nextcloud 17 on Turris Omnia with v5.0.3, I saw the following warning on /nextcloud/index.php/settings/admin/overview:
> Some columns in the database are missing a conversion to big int. Due to the fact that changing column types on big tables could take some time they were not changed automatically. By running 'occ db:convert-filecache-bigint' those pending changes could be applied manually. This operation needs to be made while the instance is offline. For further details read the documentation page about this.
> mounts.storage_id
> mounts.root_id
> mounts.mount_id
Running this command cleared the issues:
`sudo -u nobody php-cli /srv/www/nextcloud/occ db:convert-filecache-bigint`Turris OS 6.1.0Michal HruseckyMichal Hruseckyhttps://gitlab.nic.cz/turris/os/packages/-/issues/591Mox: update rescue image2024-02-21T15:43:18+01:00Karel KociMox: update rescue imageFew issues were fixed when we were porting rescue image to Omnias 2019+. These fixes should be propagated to Mox as well.
Known fixes:
* select rescue mode directly from u-bootFew issues were fixed when we were porting rescue image to Omnias 2019+. These fixes should be propagated to Mox as well.
Known fixes:
* select rescue mode directly from u-bootTurris OS 7.1.0Michal HruseckyMichal Hruseckyhttps://gitlab.nic.cz/turris/os/packages/-/issues/589Mox: update u-boot to latest version2024-03-04T10:12:52+01:00Karel KociMox: update u-boot to latest versionUpdating U-boot in Moxes is highly needed to fix issues with BTRFS sparse blocks reading.Updating U-boot in Moxes is highly needed to fix issues with BTRFS sparse blocks reading.Turris OS 7.1.0Michal HruseckyMichal Hruseckyhttps://gitlab.nic.cz/turris/os/packages/-/issues/587Turris 1.x: Update U-boot2022-06-22T16:46:34+02:00Karel KociTurris 1.x: Update U-bootUpdate uboot to new version on Turris 1.x. Doing so should enable for example boot from USB.Update uboot to new version on Turris 1.x. Doing so should enable for example boot from USB.Turris OS 6.1.0https://gitlab.nic.cz/turris/os/packages/-/issues/42Add support for Luci configured remote log setting to syslog-ng2023-03-03T02:04:54+01:00Jan PavlinecAdd support for Luci configured remote log setting to syslog-ngMore info at
https://forum.turris.cz/t/remote-log-how-to-configure/992/6
https://github.com/CZ-NIC/turris-os/issues/32More info at
https://forum.turris.cz/t/remote-log-how-to-configure/992/6
https://github.com/CZ-NIC/turris-os/issues/32Turris OS 6.1.0https://gitlab.nic.cz/turris/os/packages/-/issues/950Ethtool - cannot connect DAC cable in 1000baseX-mode2024-03-14T03:34:05+01:00ssdnvvEthtool - cannot connect DAC cable in 1000baseX-modeI am trying to connect a TO (6.5.2, firmware not yet updated; eth2-switch set to SFP) via fibre to fibre switch (TP-Link SX3008F). The switch does neither allow speed 2500baseX nor autoneg
![grafik](/uploads/c43d3b007a5725279157977fe0a...I am trying to connect a TO (6.5.2, firmware not yet updated; eth2-switch set to SFP) via fibre to fibre switch (TP-Link SX3008F). The switch does neither allow speed 2500baseX nor autoneg
![grafik](/uploads/c43d3b007a5725279157977fe0a626d6/grafik.png)
(no idea why for the autoneg; I can only set fixed 1000M or 10G), I therefore set the switch to speed 1000/full duplex.
![grafik](/uploads/bc8a03d2762287935f2a7aad391f387e/grafik.png)
When plugging in the DAC-cable, I get no connectivity.
```
root@turris:~# ethtool eth2
Settings for eth2:
Supported ports: [ ]
Supported link modes: 2500baseX/Full
1000baseX/Full
Supported pause frame use: Symmetric
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 2500baseX/Full
Advertised pause frame use: Symmetric
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Speed: 2500Mb/s
Duplex: Full
Port: Direct Attach Copper
PHYAD: 0
Transceiver: internal
Auto-negotiation: off
Supports Wake-on: d
Wake-on: d
Link detected: no
Syslog:
Feb 22 21:49:00 turris kernel: [15889.570350] sfp sfp: module FS SFPP-PC01 rev A sn G2330438860-1 dc 231010
Feb 22 21:49:00 turris kernel: [15889.579710] mvneta f1034000.ethernet eth2: switched to inband/2500base-x link mode
```
I therefore tried to change the speed on the TO manually, but get the following error:
```
root@turris:~# ethtool -s eth2 speed 1000
Cannot advertise speed 1000
```
I tried exchanging the DAC by fibre modules
```
root@PatIsa_AP_EG:~# ethtool eth2
Settings for eth2:
Supported ports: [ MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Supported pause frame use: Symmetric
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Advertised pause frame use: Symmetric
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Speed: 10Mb/s
Duplex: Half
Port: MII
PHYAD: 0
Transceiver: internal
Auto-negotiation: off
Supports Wake-on: d
Wake-on: d
Link detected: no
[ 11.328173] sfp sfp: module FS SFP-10GSR-85 rev A sn F2220034338 dc 230830
[ 11.337564] mvneta f1034000.ethernet eth2: initial validation with support 0000800,00000000,c075b2ac failed: -22
```
which neither works - this time I can set the speed and also autoneg off/on, but this does not change the above shown values.
The only module, that does work, is the Turris SFP (with speed 2500 obviously). The cable itself did work in the past (when connecting a CRS305-1G-4S+IN), but again only with speed 2500.
Is there some hardcoding that if a switch/client with higher speeds is attached, the link rate is set to 2500 regardless of what was set via ethtool? How do I effectively set the link speed to 1000 und thus establish a connection between switch and TO?
Can you please delete the diagnostics once you downloaded the attached file [2024-03-14-03-16-17_26ec5908_anonymized.zip](/uploads/659300635e7f19eeced9ddc6d76015b4/2024-03-14-03-16-17_26ec5908_anonymized.zip)?https://gitlab.nic.cz/turris/os/packages/-/issues/942Squid segfaults in TOS 6.5.12024-03-12T14:19:28+01:00Lukas JelinekSquid segfaults in TOS 6.5.1The current version of Squid (package version 4.17-1) in TOS 6.5.1 immediately crashes with "segmentation fault". Originally reported [in the forum](https://forum.turris.cz/t/turris-os-6-5-1-is-out/19722/12).
It is reproducible (tested ...The current version of Squid (package version 4.17-1) in TOS 6.5.1 immediately crashes with "segmentation fault". Originally reported [in the forum](https://forum.turris.cz/t/turris-os-6-5-1-is-out/19722/12).
It is reproducible (tested on Omnia).
From a fast test with `strace`:
```
...
open("/lib/libgcc_s.so.1", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
fstat64(3, {st_mode=S_IFREG|0644, st_size=40963, ...}) = 0
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0000E\0\0004\0\0\0"..., 936) = 936
mmap2(NULL, 110592, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0xb6af8000
mmap2(0xb6b11000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x9000) = 0xb6b11000
close(3) = 0
mprotect(0xb6e9a000, 20480, PROT_READ) = 0
mprotect(0xb6e09000, 86016, PROT_READ) = 0
mprotect(0xb6c0c000, 4096, PROT_READ) = 0
mprotect(0xb6bf2000, 16384, PROT_READ) = 0
mprotect(0xb6b29000, 4096, PROT_READ) = 0
mprotect(0xb6b11000, 4096, PROT_READ) = 0
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_ACCERR, si_addr=0x817b10} ---
+++ killed by SIGSEGV +++
Segmentation fault
```
It will require more testing and/or debugging.