Turris OS packages issueshttps://gitlab.nic.cz/turris/os/packages/-/issues2022-09-03T15:38:50+02:00https://gitlab.nic.cz/turris/os/packages/-/issues/311add support for odhcpd & ipv6 in dhcp_host_domain_ng.py2022-09-03T15:38:50+02:00Ghost Useradd support for odhcpd & ipv6 in dhcp_host_domain_ng.pyas apparent from the current code `ipv6` is not supported and `odhcpd` settings are neglected, such as
```
option leasefile
option/list domain
```
This may cause some grievance for users making the transition to ipv6.as apparent from the current code `ipv6` is not supported and `odhcpd` settings are neglected, such as
```
option leasefile
option/list domain
```
This may cause some grievance for users making the transition to ipv6.https://gitlab.nic.cz/turris/os/packages/-/issues/694Initial snapshot after finishing guide2020-11-09T13:52:22+01:00Lukas JelinekInitial snapshot after finishing guideI think that an initial filesystem snapshot should be done after finishing (or leaving) the first setup guide. This snapshot would allow to get back a clean but configured system.I think that an initial filesystem snapshot should be done after finishing (or leaving) the first setup guide. This snapshot would allow to get back a clean but configured system.https://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/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/265Update hangs if Dynamic DNS updater active2021-11-30T21:34:15+01:00Tony QuanUpdate hangs if Dynamic DNS updater activeIf the Dynamic DNS updater is active/running, updates from 3.10.8 to 3.11 TurrisOS hang and never complete. pkgupdate log shows the following and nothing after this point in the log.
```
DEBUG:backend.lua:1021 (script_run):
DEBUG:backe...If the Dynamic DNS updater is active/running, updates from 3.10.8 to 3.11 TurrisOS hang and never complete. pkgupdate log shows the following and nothing after this point in the log.
```
DEBUG:backend.lua:1021 (script_run):
DEBUG:backend.lua:1009 (script_run):Running postinst of ddns-scripts
DEBUG:src/lib/interpreter.c:320 (lua_run_generic):Command: /usr/lib/opkg/info//ddns-scripts.postinst configure
TRACE:src/lib/events.c:542 (run_command_a):Running command /usr/lib/opkg/info//ddns-scripts.postinst
```
This bug seems to have occurred before in the upgrade to 3.10.1 as pointed out [in this forum post](https://forum.turris.cz/t/solved-pkgupdate-not-working-probably-after-update-3-10-1/7653/4). As the Dynamic DNS updater is a pretty common service, testing of updates should be performed with it in place and active.https://gitlab.nic.cz/turris/os/packages/-/issues/929turris auth breaks lightppd2023-11-11T18:31:47+01:00Filip Hronturris auth breaks lightppd# outline
The "not-valid-json" error is probably caused by occasional breakdowns of turris auth
User refernce: https://forum.turris.cz/t/error-reforis-not-valid-json/19018/14?u=image
Target file: https://gitlab.nic.cz/turris/os/package...# outline
The "not-valid-json" error is probably caused by occasional breakdowns of turris auth
User refernce: https://forum.turris.cz/t/error-reforis-not-valid-json/19018/14?u=image
Target file: https://gitlab.nic.cz/turris/os/packages/-/blob/master/web/turris-auth/files/lighttpd.conf
# steps
- [ ] investigate logs when this occurs and find out why turris auth fails
- [ ] fix the problemMichal HruseckyMichal Hruseckyhttps://gitlab.nic.cz/turris/os/packages/-/issues/921You should know better... Don't change modprobe configuration files on updates2024-03-12T14:34:04+01:00Greg CYou should know better... Don't change modprobe configuration files on updatesI came in this morning to find half of my business network hard down.
I received the update for my Omnia recently and it installed and updated the system automatically. Generally this isn't a problem.
This specific update, overwrote my ...I came in this morning to find half of my business network hard down.
I received the update for my Omnia recently and it installed and updated the system automatically. Generally this isn't a problem.
This specific update, overwrote my /etc/modules.d/40-bonding file, the new one is set to hard-disable bonding support with the max option set to 0.
This is never an acceptable update.
1) If the bonding package is installed, someone is using it as it's not part of the base installation.
2) If you are going to overwrite a known used file, you need to leave the prior one on the disk for a reference (-old .backup whatever)
You should know better, please don't do something like this again.Richard MuzikRichard Muzikhttps://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/689initial-config: Allow hashed passwords to be specified in config2020-10-31T02:57:21+01:00Karel Kociinitial-config: Allow hashed passwords to be specified in configInitial version of initial-config addressed only unsecure but simple configuration. It would be better to allows users to use hashed password even when generating of it is more complicated. It would be an option for advanced users having...Initial version of initial-config addressed only unsecure but simple configuration. It would be better to allows users to use hashed password even when generating of it is more complicated. It would be an option for advanced users having to do configuration without ethernet as well.
The following discussion from !560 should be addressed:
- [ ] @vmyslivec started a [discussion](https://gitlab.nic.cz/turris/turris-os-packages/-/merge_requests/560#note_178336): (+5 comments)
> follow-up from https://gitlab.nic.cz/turris/turris-os-packages/-/merge_requests/560#note_177635
>
> Is it intended to let users generate a config that would be left on some USB flash drive with cleartext (non-hashed) passwords?
>
> I know we can't get rid of Wi-Fi password in clear text but foris and system password can be prepared in their hashed form.
>
> This README can include steps to generate desired hash.https://gitlab.nic.cz/turris/os/packages/-/issues/27resolver: add support for ipv6 static leases2021-07-29T09:57:19+02:00Jan Pavlinecresolver: add support for ipv6 static leaseshttps://forum.turris.cz/t/kresd-ipv6-hints/3680https://forum.turris.cz/t/kresd-ipv6-hints/3680https://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/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/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.https://gitlab.nic.cz/turris/os/packages/-/issues/936DHCP server replies with secs field set to one2024-03-12T14:21:31+01:00Nick KossifidisDHCP server replies with secs field set to oneIs this an issue with DNSMasq ? The RFC is pretty clear about this...
![image](/uploads/ef46a69869c6ada92f9788a2edb14003/image.png)Is this an issue with DNSMasq ? The RFC is pretty clear about this...
![image](/uploads/ef46a69869c6ada92f9788a2edb14003/image.png)https://gitlab.nic.cz/turris/os/packages/-/issues/935unable to switch omnia2016 wan to sfp2024-03-12T14:27:14+01:00Marius Durbacaunable to switch omnia2016 wan to sfpAs already reported to support (case #1542462) I'm unable to switch omnia2016 wan to sfp
I've done the following:
```
cd /boot/
rm dtb
ln -s armada-385-turris-omnia-sfp.dtb dtb
reboot
```
But after reboot there is sfp only phy support ...As already reported to support (case #1542462) I'm unable to switch omnia2016 wan to sfp
I've done the following:
```
cd /boot/
rm dtb
ln -s armada-385-turris-omnia-sfp.dtb dtb
reboot
```
But after reboot there is sfp only phy support :
```
[ 1.799021] mvneta f1034000.ethernet eth2: Using device tree mac address <redacted-mac-address-here>
[ 18.167496] mvneta f1034000.ethernet eth2: PHY [f1072004.mdio-mii:01] driver [Marvell 88E1510] (irq=POLL)
[ 18.167700] mvneta f1034000.ethernet eth2: configuring for phy/sgmii link mode
```
also updated fw but the same result as above ^
```
root@turris:~# opkg install turris-nor-update
Package turris-nor-update (1.1.0-7) installed in root is up to date.
root@turris:~# nor-update
Verifying /dev/mtd0 against uboot ...
a3a04aa6143fe437e00b96fbcc8cd20f - /dev/mtd0
a3a04aa6143fe437e00b96fbcc8cd20f - uboot
root@turris:~# reboot
root@turris:~#
```
other reports on forum https://forum.turris.cz/t/g-fast-sfp-worked-in-tos-3-stopped-working-in-tos-5/16690https://gitlab.nic.cz/turris/os/packages/-/issues/932syslog-ng http destination does not load with latest update2024-03-06T11:42:25+01:00Peter Czaniksyslog-ng http destination does not load with latest updateThe latest Turris OS update updated syslog-ng to version 4.4.0. This version adds compression to the http() destination (https://www.syslog-ng.com/community/b/blog/posts/compressing-http-traffic-in-syslog-ng) using zlib from curl. Howeve...The latest Turris OS update updated syslog-ng to version 4.4.0. This version adds compression to the http() destination (https://www.syslog-ng.com/community/b/blog/posts/compressing-http-traffic-in-syslog-ng) using zlib from curl. However, syslog-ng cannot load the http module:
```
root@turris:~# syslog-ng -V
syslog-ng 4 (4.4.0)
Config version: 4.2
Installer-Version: 4.4.0
Revision:
Compile-Date: Oct 9 2023 18:02:40
Module-Directory: /usr/lib/syslog-ng
Module-Path: /usr/lib/syslog-ng
Include-Path: /usr/share/syslog-ng/include
Error opening plugin module; module='http', error='Error relocating /usr/lib/syslog-ng/libhttp.so: deflateEnd: symbol not found'
Available-Modules: kvformat,json-plugin,timestamp,rate-limit-filter,correlation,hook-commands,map-value-pairs,cryptofuncs,basicfuncs,disk-buffer,syslogformat,metrics-probe,secure-logging,cef,system-source,afprog,afstomp,afuser,add-contextual-data,linux-kmsg-format,azure-auth-header,xml,afsocket,tfgetent,pseudofile,regexp-parser,tags-parser,csvparser,confgen,affile,appmodel,graphite,stardate,examples
Enable-Debug: off
Enable-GProf: off
Enable-Memtrace: off
Enable-IPv6: on
Enable-Spoof-Source: off
Enable-TCP-Wrapper: off
Enable-Linux-Caps: off
Enable-Systemd: off
```
Is zlib compression enabled in the curl package?
This problem does not affect the default configuration. However, if a user created a configuration to log to elasticsearch or one of the cloud services, like Slack or Sumologic, then starting syslog-ng fails.https://gitlab.nic.cz/turris/os/packages/-/issues/931rescue-mode-omnia: reflash from the internet is broken2023-10-23T10:15:16+02:00Aleksandr Gumroianrescue-mode-omnia: reflash from the internet is brokenIf `mode 6` is selected during reflash on my Omnia a.k.a `Flashing from the Cloud :-)` the following occurs:
- The reflash is stuck on step 1 - downloading the latest Omnia medkit, the serial console log:
<details>
<summary>Click to ex...If `mode 6` is selected during reflash on my Omnia a.k.a `Flashing from the Cloud :-)` the following occurs:
- The reflash is stuck on step 1 - downloading the latest Omnia medkit, the serial console log:
<details>
<summary>Click to expand</summary>
```
1s left
0s left
Mode 6 selected!
Flashing from the Cloud :-)
[ 9.101834] mvneta f1034000.ethernet eth2: PHY [f1072004.mdio-mii:01] driver [Marvell 88E1510]
[ 9.110598] mvneta f1034000.ethernet eth2: configuring for phy/sgmii link mode
[ 9.118241] IPv6: ADDRCONF(NETDEV_UP): eth2: link is not ready
udhcpc: started, v1.31.1
Setting IP address 0.0.0.0 on eth2
udhcpc: sending discover
udhcpc: sending discover
[ 12.311611] mvneta f1034000.ethernet eth2: Link is Up - 1Gbps/Full - flow control rx/tx
[ 12.319646] IPv6: ADDRCONF(NETDEV_CHANGE): eth2: link becomes ready
udhcpc: sending discover
udhcpc: sending select for 192.168.0.24
udhcpc: lease of 192.168.0.24 obtained, lease time 604800
Setting IP address 192.168.0.24 on eth2
Deleting routers
route: SIOCDELRT: No such process
Adding router 192.168.0.1
Recreating /etc/resolv.conf
Adding DNS server 192.168.0.1
Got IPv4!
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 532
link/ether d8:58:d7:00:55:13 brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 532
link/ether d8:58:d7:00:55:11 brd ff:ff:ff:ff:ff:ff
4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 532
link/ether d8:58:d7:00:55:12 brd ff:ff:ff:ff:ff:ff
inet 192.168.0.24/24 brd 192.168.0.255 scope global eth2
valid_lft forever preferred_lft forever
inet6 2a02:8308:280:5d00:da58:d7ff:fe00:5512/64 scope global dynamic
valid_lft 3456000sec preferred_lft 2592000sec
inet6 fe80::da58:d7ff:fe00:5512/64 scope link
valid_lft forever preferred_lft forever
5: lan0@eth1: <BROADCAST,MULTICAST,M-DOWN> mtu 1500 qdisc noop state DOWN qlen 1000
link/ether d8:58:d7:00:55:11 brd ff:ff:ff:ff:ff:ff
6: lan1@eth1: <BROADCAST,MULTICAST,M-DOWN> mtu 1500 qdisc noop state DOWN qlen 1000
link/ether d8:58:d7:00:55:11 brd ff:ff:ff:ff:ff:ff
7: lan2@eth1: <BROADCAST,MULTICAST,M-DOWN> mtu 1500 qdisc noop state DOWN qlen 1000
link/ether d8:58:d7:00:55:11 brd ff:ff:ff:ff:ff:ff
8: lan3@eth1: <BROADCAST,MULTICAST,M-DOWN> mtu 1500 qdisc noop state DOWN qlen 1000
link/ether d8:58:d7:00:55:11 brd ff:ff:ff:ff:ff:ff
9: lan4@eth0: <BROADCAST,MULTICAST,M-DOWN> mtu 1500 qdisc noop state DOWN qlen 1000
link/ether d8:58:d7:00:55:13 brd ff:ff:ff:ff:ff:ff
default via 192.168.0.1 dev eth2
192.168.0.0/24 dev eth2 scope link src 192.168.0.24
--2023-10-10 12:38:17-- https://repo.turris.cz/hbs/medkit/medkit-omnia-latest.tar.gz
```
</details>
- If you follow the [URL](https://repo.turris.cz/hbs/medkit/medkit-omnia-latest.tar.gz) from the log, you will get - `404 Not Found`
- https://repo.turris.cz/hbs/medkit/medkit-omnia-latest.tar.gz ❌
- https://repo.turris.cz/hbs/medkit/omnia-medkit-latest.tar.gz ✅
- The downloading of the image and the overall process of reflashing is stuck:
<details><summary>Click to expand</summary>
![telegram-cloud-photo-size-4-5848131056711089750-y](/uploads/72d7f6a843d0ece07f41b89b52afcd3f/telegram-cloud-photo-size-4-5848131056711089750-y.jpg)
</details>
There is obviously a problem somewhere in the [rescue script](https://gitlab.nic.cz/turris/os/packages/-/blob/master/hardware/rescue-image/files/helpers.sh#L112), but I could not find it.
Tested on Turris Omnia: Turris OS 6.3.2, HBS & Turris OS 6.4.2, HBS.https://gitlab.nic.cz/turris/os/packages/-/issues/930[develop branch / HBD]: Compilation of foris-controller-*-module fails2024-03-18T15:21:44+01:00Magnus Kessler[develop branch / HBD]: Compilation of foris-controller-*-module failsCurrently, on the develop (hbd) branch compilation of foris-controller-*-module fails with error messages similar to:
```
/usr/bin/env bash /home/ubuntu/development/TurrisBuild/feeds/packages/lang/python/python-package-install.sh "/home...Currently, on the develop (hbd) branch compilation of foris-controller-*-module fails with error messages similar to:
```
/usr/bin/env bash /home/ubuntu/development/TurrisBuild/feeds/packages/lang/python/python-package-install.sh "/home/ubuntu/development/TurrisBuild/build_dir/target-arm_cortex-a9+vfpv3-d16_musl_eabi/foris-controller-schnapps-module-0.5/ipkg-install" "/home/ubuntu/development/TurrisBuild/build_dir/target-arm_cortex-a9+vfpv3-d16_musl_eabi/foris-controller-schnapps-module-0.5/.pkgdir/foris-controller-schnapps-module" "$V_Py3Package_foris_controller_schnapps_module_filespec"
Copying: "/usr/lib/python3.11/site-packages"
Removing: "/usr/lib/python3.11/site-packages/foris_controller_modules/__init__.py"
Error: "/home/ubuntu/development/TurrisBuild/build_dir/target-arm_cortex-a9+vfpv3-d16_musl_eabi/foris-controller-schnapps-module-0.5/.pkgdir/foris-controller-schnapps-module//usr/lib/python3.11/site-packages/foris_controller_modules/__init__.py" not found
make[2]: *** [Makefile:48: /home/ubuntu/development/TurrisBuild/build_dir/target-arm_cortex-a9+vfpv3-d16_musl_eabi/foris-controller-schnapps-module-0.5/.pkgdir/foris-controller-schnapps-module.installed] Error 1
make[2]: Leaving directory '/home/ubuntu/development/TurrisBuild/feeds/turrispackages/web/foris-controller/foris-controller-schnapps-module'
time: package/feeds/turrispackages/foris-controller-schnapps-module/compile#0.27#0.08#0.34
ERROR: package/feeds/turrispackages/foris-controller-schnapps-module failed to build.
make[1]: *** [package/Makefile:120: package/feeds/turrispackages/foris-controller-schnapps-module/compile] Error 1
```
The removal of the `__init__.py` file appears to be a result of how the filespec is set up for these modules.
The following patch leads to successful compilation. It simply removes the lines that try to remove `__init__.py`:
```
diff --git a/web/foris-controller/foris-controller/files/foris-controller-module.mk b/web/foris-controller/foris-controller/files/foris-controller-module.mk
index 5471a82db..25e6fe20a 100644
--- a/web/foris-controller/foris-controller/files/foris-controller-module.mk
+++ b/web/foris-controller/foris-controller/files/foris-controller-module.mk
@@ -7,8 +7,6 @@ define ForisControllerModule
define Py3Package/$(1)/filespec
+|$(PYTHON3_PKG_DIR)
--|$(PYTHON3_PKG_DIR)/foris_controller_modules/__init__.py
--|$(PYTHON3_PKG_DIR)/foris_controller_backends/__init__.py
endef
define Py3Package/$(1)/install
```
I'm not sure that this is ultimately the correct solution, as I haven't been able to spot recent changes that lead to the failure in the first place.Michal HruseckyMichal Hruseckyhttps://gitlab.nic.cz/turris/os/packages/-/issues/927schnapps: soft dependencies2023-09-20T11:21:24+02:00Richard Muzikschnapps: soft dependenciesSchnapps uses some packages (gnupg, sshfs...), that are not necessary for it to work, but some functionalities won't be available. So we should make them soft (suggested) dependencies.Schnapps uses some packages (gnupg, sshfs...), that are not necessary for it to work, but some functionalities won't be available. So we should make them soft (suggested) dependencies.https://gitlab.nic.cz/turris/os/packages/-/issues/922LTE support lost after 6.4.0 upgrade2024-03-12T14:30:59+01:00Romuald ContyLTE support lost after 6.4.0 upgradeAfter 6.4.0 upgrade, I loose the LTE support using an E3372 USB dongle.
This dongle uses a firmware (*HiLink*) that act as a router and expose an `eth` interface, but after the upgrade the interface is not available.
`lsusb` still list ...After 6.4.0 upgrade, I loose the LTE support using an E3372 USB dongle.
This dongle uses a firmware (*HiLink*) that act as a router and expose an `eth` interface, but after the upgrade the interface is not available.
`lsusb` still list the device.
Restoring the 6.3.3 snapshot brings the support back.
Note: The package set **Extensions of network protocols for 3G/LTE** in packages list is installed.