Turris Build issueshttps://gitlab.nic.cz/turris/os/build/-/issues2020-06-15T22:17:11+02:00https://gitlab.nic.cz/turris/os/build/-/issues/41Automatic package bumping should be package wide2020-06-15T22:17:11+02:00Karel KociAutomatic package bumping should be package wideCurrent work in progress implementation of automatic package bumper is using package name (real package to be build) to identify if it should be bumped. The problem is that in reality it is expected that packages from same Makefile have ...Current work in progress implementation of automatic package bumper is using package name (real package to be build) to identify if it should be bumped. The problem is that in reality it is expected that packages from same Makefile have same `PKG_VERSION` and `PKG_RELEASE`. This is because they are build from same source. Autobumber breaks that.
Solution is to just instead of looking if we should bump specific package, we should instead bump all packages in Makefile. This should be even easier to be done than current solution as we should modify `PKG_RELEASE` variable instead of hacking package creation process.
Simply put: when any package defined in Makefile is detected as different then we should change `PKG_RELEASE` and that way we bump all packages generated by that Makefile.
This should fix: https://gitlab.labs.nic.cz/turris/turris-os-packages/issues/417https://gitlab.nic.cz/turris/os/build/-/issues/231Generate medkits - pkgupdate can not be found as there are not enough depend...2021-10-14T11:42:50+02:00Josef SchlehoferGenerate medkits - pkgupdate can not be found as there are not enough dependencies installedI'm trying to use generate_medkits, but it seems I don't have installed required dependencies and it fails with such outputs:
```
configure: error: Package requirements (liburiparser >= 0.9) were not met:
No package 'liburiparser' found...I'm trying to use generate_medkits, but it seems I don't have installed required dependencies and it fails with such outputs:
```
configure: error: Package requirements (liburiparser >= 0.9) were not met:
No package 'liburiparser' found
Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.
```
and so on.
When I tried to run generate_medkits once again when I installed the dependency it fails with this output:
```
warning: redirecting to https://gitlab.nic.cz/turris/updater/updater.git/
/bin/bash: line 13: /foo/omnia-hbl/turris-tools/updater-ng/pkgupdate: No such file or directory
```
I know that correct solution would be install dependencies from this file https://gitlab.nic.cz/turris/updater/updater/-/blob/master/.gitlab-ci-docker/DockerFile_debian but I'm trying to document usage of generate medkits in README in this repository.
**It helps when I remove folder turris-tools and then I can use generate_medkits once again.**Turris OS 6.0https://gitlab.nic.cz/turris/os/build/-/issues/12SFP port on Turris Omnia does not work2019-05-07T13:53:14+02:00Karel KociSFP port on Turris Omnia does not workThere seems to be some problem with SFP on Omnia. It is not detected correctly and reports errors.
This was initially reported on forum: https://forum.turris.cz/t/turris-os-4-0-alpha4-is-out/9836/22
I reproduced it successfully with di...There seems to be some problem with SFP on Omnia. It is not detected correctly and reports errors.
This was initially reported on forum: https://forum.turris.cz/t/turris-os-4-0-alpha4-is-out/9836/22
I reproduced it successfully with different SFP module.
```
[ 4.716114] mdio_bus f1072004.mdio-mii: /soc/internal-regs/mdio@72004/sfp has invalid PHY address
[ 4.725015] mdio_bus f1072004.mdio-mii: scan phy sfp at address 0
[ 4.731127] mdio_bus f1072004.mdio-mii: scan phy sfp at address 1
[ 4.737241] mdio_bus f1072004.mdio-mii: scan phy sfp at address 2
[ 4.743354] mdio_bus f1072004.mdio-mii: scan phy sfp at address 3
```
Scan goes up to address 31 and then stops.Turris OS 4.0https://gitlab.nic.cz/turris/os/build/-/issues/13Device tree patching fails if SFP module is connected as first module2019-05-07T13:53:14+02:00Karel KociDevice tree patching fails if SFP module is connected as first moduleI connected SFP module as only module to Mox and it fails to start with following error in U-boot.
```
U-Boot 2018.11 (Dec 03 2018 - 09:33:41 +0000)
DRAM: 512 MiB
Enabling Armada 3720 wComphy-0: SGMII1 1.25 Gbps
Comphy-1: PEX0 ...I connected SFP module as only module to Mox and it fails to start with following error in U-boot.
```
U-Boot 2018.11 (Dec 03 2018 - 09:33:41 +0000)
DRAM: 512 MiB
Enabling Armada 3720 wComphy-0: SGMII1 1.25 Gbps
Comphy-1: PEX0 5 Gbps
Comphy-2: USB3_HOST0 5 Gbps
MMC: sdhci@d8000: 0
Loading Environment from SPI Flash... SF: Detected w25q64dw with page size 256 Bytes, erase size 4 KiB, total 8 MiB
OK
Model: CZ.NIC Turris Mox Board
Net: eth0: neta@30000
Turris Mox:
Board version: 22
RAM size: 512 MiB
Serial Number: 0000000D3000001B
ECDSA Public Key: 030149fd703bed9cbd664723986eaf76a2e4c1ef45ccb845dda2dab5b21ed0605b5a75abd9577d9bb29f0a88fc9d9c4d034dbb20332152075ede0c7199e0e8d9d2bc70
SD/eMMC version: SD
Module Topology:
1: SFP Module
Hit any key to stop autoboot: 0
gpio: pin GPIO221 (gpio 57) value is 0
gpio: pin GPIO220 (gpio 56) value is 1
SF: Detected w25q64dw with page size 256 Bytes, erase size 4 KiB, total 8 MiB
device 0 offset 0x7f0000, size 0x10000
SF: 65536 bytes @ 0x7f0000 Read: OK
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found U-Boot script /boot.scr
403 bytes read in 72 ms (4.9 KiB/s)
## Executing script at 04d00000
9959432 bytes read in 482 ms (19.7 MiB/s)
19292 bytes read in 66 ms (285.2 KiB/s)
## Flattened Device Tree blob at 04f00000
Booting using the fdt blob at 0x4f00000
Loading Device Tree to 000000001bf14000, end 000000001bf1bb5b ... OK
ERROR: board-specific fdt fixup failed: FDT_ERR_NOTFOUND
- must RESET the board to recover.
FDT creation failed! hanging...### ERROR ### Please RESET the board ###
```Turris OS 4.0Marek BehunMarek Behunhttps://gitlab.nic.cz/turris/os/build/-/issues/14SFP module transmit fault2023-08-16T11:04:32+02:00Ghost UserSFP module transmit faultwith 4.x alpha5 the log showing
> libphy: SFP I2C Bus: probed
> sfp sfp: module ALLNET ALL4781 rev V3.4 sn 0000000FC9157640 dc 29-03-18
> sfp sfp: unknown connector, encoding 8b10b, nominal bitrate 1.3Gbps +0% -0%
> sfp sfp: 1000B...with 4.x alpha5 the log showing
> libphy: SFP I2C Bus: probed
> sfp sfp: module ALLNET ALL4781 rev V3.4 sn 0000000FC9157640 dc 29-03-18
> sfp sfp: unknown connector, encoding 8b10b, nominal bitrate 1.3Gbps +0% -0%
> sfp sfp: 1000BaseSX+ 1000BaseLX- 1000BaseCX- 1000BaseT- 100BaseTLX- 1000BaseFX- BaseBX10- BasePX-
> sfp sfp: 10GBaseSR- 10GBaseLR- 10GBaseLRM- 10GBaseER-
> sfp sfp: Wavelength 0nm, fiber lengths:
> sfp sfp: 9µm SM : unsupported
> sfp sfp: 62.5µm MM OM1: unsupported/unspecified
> sfp sfp: 50µm MM OM2: unsupported/unspecified
> sfp sfp: 50µm MM OM3: unsupported/unspecified
> sfp sfp: 50µm MM OM4: 2.540km
> sfp sfp: Options: retimer
> sfp sfp: Diagnostics:
> sfp sfp: module transmit fault indicated
> sfp sfp: module transmit fault recovered
> sfp sfp: module transmit fault indicated
> sfp sfp: module persistently indicates fault, disabling
Mind you the ALLNET ALL4781 is a small form factor DSL modem in the SFP port and works without these hiccups in TOS3.x branch.
>Identifier : 0x03 (SFP)
>Extended identifier : 0x04 (GBIC/SFP defined by 2-wire interface ID)
>Connector : 0x22 (RJ45)
>Transceiver codes : 0x00 0x00 0x00 0x01 0x00 0x00 0x00 0x00 0x00
>Transceiver type : Ethernet: 1000BASE-SX
>Encoding : 0x01 (8B/10B)
>BR, Nominal : 1300MBd
>Rate identifier : 0x00 (unspecified)
>Length (SMF,km) : 0km
>Length (SMF) : 0m
>Length (50um) : 0m
>Length (62.5um) : 0m
>Length (Copper) : 255m
>Length (OM3) : 0m
>Laser wavelength : 0nm
>Vendor name : ALLNET
>Vendor OUI : 00:0f:c9
>Vendor PN : ALL4781
>Vendor rev : V3.4
>Option values : 0x08 0x00
>Option : Retimer or CDR implemented
>BR margin, max : 0%
>BR margin, min : 0%
>Vendor SN : 0000000FC9157640
>Date code : 18032900Tomáš HlaváčekTomáš Hlaváčekhttps://gitlab.nic.cz/turris/os/build/-/issues/18Sentinel proxy failure because of missing symbol in dependency2023-08-16T11:04:29+02:00Karel KociSentinel proxy failure because of missing symbol in dependencyRunning sentinel-proxy on HBD results to following failure:
```
Traceback (most recent call last):
File "/usr/libexec/sentinel_certgen.py", line 499, in <module>
main()
File "/usr/libexec/sentinel_certgen.py", line 495, in main
...Running sentinel-proxy on HBD results to following failure:
```
Traceback (most recent call last):
File "/usr/libexec/sentinel_certgen.py", line 499, in <module>
main()
File "/usr/libexec/sentinel_certgen.py", line 495, in main
start_state_machine(key_path, csr_path, cert_path, ca_path, sn, api_url, flags)
File "/usr/libexec/sentinel_certgen.py", line 434, in start_state_machine
state, sid, key, cert, csr, cert_sn = process_init(key_path, csr_path, cert_path, sn, flags)
File "/usr/libexec/sentinel_certgen.py", line 289, in process_init
generate_priv_key_file(key_path)
File "/usr/libexec/sentinel_certgen.py", line 178, in generate_priv_key_file
backend=default_backend())
File "/__init__.py", line 15, in default_backend
File "/__init__.py", line 7, in <module>
File "/backend.py", line 71, in <module>
File "/binding.py", line 15, in <module>
ImportError: Error relocating /usr/lib/python3.7/site-packages/cryptography/hazmat/bindings/_openssl.abi3.so: SSL_get0_next_proto_negotiated: symbol not found
Traceback (most recent call last):
File "/usr/libexec/sentinel_certgen.py", line 499, in <module>
main()
File "/usr/libexec/sentinel_certgen.py", line 495, in main
start_state_machine(key_path, csr_path, cert_path, ca_path, sn, api_url, flags)
File "/usr/libexec/sentinel_certgen.py", line 434, in start_state_machine
state, sid, key, cert, csr, cert_sn = process_init(key_path, csr_path, cert_path, sn, flags)
File "/usr/libexec/sentinel_certgen.py", line 289, in process_init
generate_priv_key_file(key_path)
File "/usr/libexec/sentinel_certgen.py", line 178, in generate_priv_key_file
backend=default_backend())
File "/__init__.py", line 15, in default_backend
File "/__init__.py", line 7, in <module>
File "/backend.py", line 71, in <module>
File "/binding.py", line 15, in <module>
ImportError: Error relocating /usr/lib/python3.7/site-packages/cryptography/hazmat/bindings/_openssl.abi3.so: SSL_get0_next_proto_negotiated: symbol not found
```
It seems that one of libraries used is cryptography and it is invalidly linked against some other library with different symbol.https://gitlab.nic.cz/turris/os/build/-/issues/19Syslog spammed with promiscuous mode messages2019-06-07T14:38:39+02:00Vojtech MyslivecSyslog spammed with promiscuous mode messages## Affected devices:
* MOX
## Affected HW combinations:
* MOX A + MOX B + MOX C
* MOX A + MOX E
## TurrisOS branch + date:
* HBS - 2019-03-10 (alfa 2)
* HBD - 2019-03-14
## Affected SW component (best guess)
* kernel / network config...## Affected devices:
* MOX
## Affected HW combinations:
* MOX A + MOX B + MOX C
* MOX A + MOX E
## TurrisOS branch + date:
* HBS - 2019-03-10 (alfa 2)
* HBD - 2019-03-14
## Affected SW component (best guess)
* kernel / network configuration
## Detailed description
Kernel spam syslog with *promiscuous mode* messages off `br-guest_turris` interface. There is always "on" and "off" consecutive messages circa ten times a second.
### Setup (+stacktraces/screenshots)
*syslog* fragment:
```
Mar 10 13:07:12 turris kernel: [ 2860.424244] device br-guest_turris entered promiscuous mode
Mar 10 13:07:12 turris kernel: [ 2860.494298] device br-guest_turris left promiscuous mode
Mar 10 13:07:12 turris kernel: [ 2861.014159] device br-guest_turris entered promiscuous mode
Mar 10 13:07:13 turris kernel: [ 2861.084074] device br-guest_turris left promiscuous mode
Mar 10 13:07:13 turris kernel: [ 2861.604066] device br-guest_turris entered promiscuous mode
Mar 10 13:07:13 turris kernel: [ 2861.663915] device br-guest_turris left promiscuous mode
```
### Unexpected behaviour
Log is full of useless messages. Changing this states probably slow down CPU/kernel from useful work (such as routing :slight\_smile: )
### Expected behaviour
Promiscuous mode is not changed so often or not at all.Turris OS 4.0https://gitlab.nic.cz/turris/os/build/-/issues/24mv88e6xxx SMI leak warning2019-07-10T06:00:11+02:00Ghost Usermv88e6xxx SMI leak warning> {"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"}}
___
> [ 4.432488] libphy: mv88e6xxx SMI: probed
> [ 4.437412] ------------[ cut here ]------------
> [ 4.442061] WARNING: CPU: 0 PID: 1 at fs/proc/generic.c:572 remove_proc_entry+0x140/0x154
> [ 4.450257] remove_proc_entry: removing non-empty directory 'irq/58', leaking at least 'mv88e6xxx-g2'
> [ 4.459501] Modules linked in:
> [ 4.462569] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.14.121 #0
> [ 4.468674] Hardware name: Marvell Armada 380/385 (Device Tree)
> [ 4.474623] [ <c010ed2c> ] (unwind_backtrace) from [<c010a9fc>] (show_stack+0x10/0x14)
> [ 4.482391] [ <c010a9fc> ] (show_stack) from [<c0793488>] (dump_stack+0x88/0x9c)
> [ 4.489634] [ <c0793488> ] (dump_stack) from [<c0121c94>] (__warn+0xe4/0x100)
> [ 4.496613] [ <c0121c94> ] (__warn) from [<c0121ce8>] (warn_slowpath_fmt+0x38/0x48)
> [ 4.504116] [ <c0121ce8> ] (warn_slowpath_fmt) from [<c0269d5c>] (remove_proc_entry+0x140/0x154)
> [ 4.512752] [ <c0269d5c> ] (remove_proc_entry) from [<c016bfd0>] (unregister_irq_proc+0xcc/0xe8)
> [ 4.521385] [ <c016bfd0> ] (unregister_irq_proc) from [<c01632f4>] (free_desc+0x2c/0x54)
> [ 4.529320] [ <c01632f4> ] (free_desc) from [<c016335c>] (irq_free_descs+0x40/0x74)
> [ 4.536821] [ <c016335c> ] (irq_free_descs) from [<c05b0590>] (mv88e6xxx_g1_irq_free_common+0x4c/0x74)
> [ 4.545975] [ <c05b0590> ] (mv88e6xxx_g1_irq_free_common) from [<c05b0618>] (mv88e6xxx_irq_poll_free+0x2c/0x38)
> [ 4.555914] [ <c05b0618> ] (mv88e6xxx_irq_poll_free) from [<c05b1fac>] (mv88e6xxx_probe+0x318/0x344)
> [ 4.564894] [ <c05b1fac> ] (mv88e6xxx_probe) from [<c051c6ac>] (really_probe+0x114/0x274)
> [ 4.572921] [ <c051c6ac> ] (really_probe) from [<c051aee4>] (bus_for_each_drv+0x44/0x98)
> [ 4.580857] [ <c051aee4> ] (bus_for_each_drv) from [<c051c528>] (__device_attach+0x78/0xe0)
> [ 4.589055] [ <c051c528> ] (__device_attach) from [<c051bb80>] (bus_probe_device+0x28/0x88)
> [ 4.597253] [ <c051bb80> ] (bus_probe_device) from [<c051a040>] (device_add+0x3d0/0x5b4)
> [ 4.605191] [ <c051a040> ] (device_add) from [<c05a8df4>] (mdio_device_register+0x1c/0x44)
> [ 4.613303] [ <c05a8df4> ] (mdio_device_register) from [<c064a140>] (of_mdiobus_register+0x168/0x2b4)
> [ 4.622377] [ <c064a140> ] (of_mdiobus_register) from [<c05b8108>] (orion_mdio_probe+0x204/0x2e8)
> [ 4.631099] [ <c05b8108> ] (orion_mdio_probe) from [<c051dc6c>] (platform_drv_probe+0x34/0x70)
> [ 4.639556] [ <c051dc6c> ] (platform_drv_probe) from [<c051c6ac>] (really_probe+0x114/0x274)
> [ 4.647840] [ <c051c6ac> ] (really_probe) from [<c051c898>] (__driver_attach+0x8c/0xb0)
> [ 4.655689] [ <c051c898> ] (__driver_attach) from [<c051ae38>] (bus_for_each_dev+0x4c/0xa0)
> [ 4.663888] [ <c051ae38> ] (bus_for_each_dev) from [<c051bdbc>] (bus_add_driver+0xe8/0x200)
> [ 4.672084] [ <c051bdbc> ] (bus_add_driver) from [<c051cfdc>] (driver_register+0xa8/0xe4)
> [ 4.680106] [ <c051cfdc> ] (driver_register) from [<c0101b10>] (do_one_initcall+0xc0/0x184)
> [ 4.688306] [ <c0101b10> ] (do_one_initcall) from [<c0a00f30>] (kernel_init_freeable+0x1c0/0x254)
> [ 4.697030] [ <c0a00f30> ] (kernel_init_freeable) from [<c07a6554>] (kernel_init+0x8/0x114)
> [ 4.705228] [ <c07a6554> ] (kernel_init) from [<c0107808>] (ret_from_fork+0x14/0x2c)
> [ 4.712827] ---[ end trace 622458f73aa20313 ]---Marek BehunMarek Behunhttps://gitlab.nic.cz/turris/os/build/-/issues/26erroneous btrfs warning/error in the kernel log?2023-08-16T11:04:27+02:00Ghost Usererroneous btrfs warning/error in the kernel log?> {"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"}}
___
* internal ssd with 2 `btrfs` partitions configured as `bftrfs raid1`
* only one partition (sda3) gets mounted via fstab (mountpoint /srv)
```
config 'mount'
option target '/srv'
option label 'srv'
option uuid '67eccb2b-cc29-4414-966e-0ff205bb5d3f'
option enabled '1'
config 'mount'
option target '/mnt/sda4'
option uuid '67eccb2b-cc29-4414-966e-0ff205bb5d3f'
option enabled '0'
```
to my understanding `bftrfs raid1` requires only 1 partition of the raid to be mounted by the OS and btrfs managing all partition consigned to the raid.
___
The kernel log reads:
> [ 5.099490] sda: sda1 sda2 sda3 sda4
> [ 13.716783] BTRFS: device label srv devid 2 transid 25313 /dev/sda4
> [ 13.723630] BTRFS info (device sda4): disk space caching is enabled
> [ 13.729914] BTRFS info (device sda4): has skinny extents
*The following seems erroneous however:*
> [ 13.735757] BTRFS warning (device sda4): devid 1 uuid 9d3f01b6-b4f6-4ca4-a7b4-36d6f3509d13 is missing
> [ 13.745020] BTRFS error (device sda4): failed to read the system array: -5
> [ 13.861295] BTRFS error (device sda4): open_ctree failed
considering that the raid appears fully mounted and working just fine:
`btrfs fi show`
> Label: none uuid: 1831a49e-3001-4e7e-b89f-0ec676763cb0
> Total devices 1 FS bytes used 485.02MiB
> devid 1 size 7.28GiB used 1.48GiB path /dev/mmcblk0p1
>
> Label: 'log' uuid: dc2d8d7b-f198-4f75-88c5-e4ed5079af8b
> Total devices 1 FS bytes used 12.34MiB
> devid 1 size 2.00GiB used 844.00MiB path /dev/sda2
>
> Label: 'srv' uuid: 67eccb2b-cc29-4414-966e-0ff205bb5d3f
> Total devices 2 FS bytes used 3.64GiB
> devid 1 size 463.49GiB used 5.01GiB path /dev/sda3
> devid 2 size 463.54GiB used 5.01GiB path /dev/sda4
`btrfs device usage /srv`
> /dev/sda3, ID: 1
> Device size: 463.49GiB
> Device slack: 0.00B
> Data,RAID0: 4.00GiB
> Metadata,RAID1: 1.00GiB
> System,RAID1: 8.00MiB
> Unallocated: 458.48GiB
>
> /dev/sda4, ID: 2
> Device size: 463.54GiB
> Device slack: 3.50KiB
> Data,RAID0: 4.00GiB
> Metadata,RAID1: 1.00GiB
> System,RAID1: 8.00MiB
> Unallocated: 458.53GiB
`btrfs filesystem show /dev/sda3`
> Label: 'srv' uuid: 67eccb2b-cc29-4414-966e-0ff205bb5d3f
> Total devices 2 FS bytes used 3.64GiB
> devid 1 size 463.49GiB used 5.01GiB path /dev/sda3
> devid 2 size 463.54GiB used 5.01GiB path /dev/sda4
`btrfs check --force /dev/sda3` | `btrfs check --force /dev/sda4`
> WARNING: filesystem mounted, continuing because of --force
> Checking filesystem on /dev/sda3 | Checking filesystem on /dev/sda4
> UUID: 67eccb2b-cc29-4414-966e-0ff205bb5d3f
> checking extents
> checking free space cache
> checking fs roots
> checking csums
> checking root refs
> found 3910221824 bytes used, no error found
> total csum bytes: 3698576
> total tree bytes: 120520704
> total fs tree bytes: 109297664
> total extent tree bytes: 6012928
> btree space waste bytes: 24959410
> file data blocks allocated: 3844587520
> referenced 3746054144
`btrfs filesystem df /srv`
> Data, RAID0: total=8.00GiB, used=3.53GiB
> System, RAID1: total=8.00MiB, used=16.00KiB
> Metadata, RAID1: total=1.00GiB, used=114.92MiB
> GlobalReserve, single: total=512.00MiB, used=0.00B
___
~~Not sure if perhaps if these unset kernel settings might cause it?~~
```
# CONFIG_BTRFS_FS_CHECK_INTEGRITY is not set
# CONFIG_BTRFS_FS_RUN_SANITY_TESTS is not set
# CONFIG_BTRFS_ASSERT is not set
```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/28[lxc] unprivileged container not booting - rootfs fails mounting2021-05-18T16:51:57+02:00Ghost User[lxc] unprivileged container not booting - rootfs fails mounting> {"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":"ab3fd04","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":"ab3fd04","target":"mvebu\/cortexa9","description":"TurrisOS 4.0-beta2 ab3fd04"}}
___
* installed are - lxc-unprivileged | shadow-newgidmap | shadow-newuidmap
* in absentia manually created /etc/subgid | /etc/subuid
* exec - `usermod --add-subuids 100000-165536 $USER && usermod --add-subgids 100000-165536 $USER`
* exec - `lxc-checkconfig` [lxc-checkconfig.txt](/uploads/690fb5525e27541df521a50f8b2b32fc/lxc-checkconfig.txt)
* container ubuntu disco created
* added `lxc.idmap = u 0 100000 65536` | `lxc.idmap = g 0 100000 65536` to [container.conf](/uploads/c388c071b44b10e8caf3c3c6e8befacb/container.conf)
___
* exec - `lxc-start test -F -o /logs/lxc/test -l debug` [log.txt](/uploads/7947c8e28842cda76d27b01d439202df/log.txt)
* `dmesg` not reporting anything related to the issue
* container boots with no issues if *privileged*
* `cat /proc/1/mounts` [mounts.text](/uploads/aa45adad744636327790e70862e4f39c/mounts.text)
* kernel conf [config](/uploads/7ff963b82770bf7f1e4270fc00823812/config)
* `stat /usr/lib/lxc/rootfs/`
> File: ‘/usr/lib/lxc/rootfs/’
> Size: 12 Blocks: 0 IO Block: 4096 directory
> Device: 10h/16d Inode: 31359 Links: 1
> Access: (0711/drwx--x--x) Uid: ( 0/ root) Gid: ( 0/ root)
* `cat /proc/self/cgroup`
> 11:debug:/
> 10:rdma:/
> 9:pids:/
> 8:net_cls:/
> 7:freezer:/
> 6:devices:/
> 5:memory:/
> 4:blkio:/
> 3:cpuacct:/
> 2:cpu:/
> 1:cpuset:/
* `ls -al /proc/sys/kernel/| grep unpriv`
> -rw-r--r-- 1 root root 0 Jun 5 12:58 unprivileged_bpf_disabled
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/30block-mount fstab service causes unmount of all FSs2019-06-05T13:29:45+02:00Karel Kociblock-mount fstab service causes unmount of all FSsRunning `/etc/init.d/fstab restart` causes all FSs to be unmounted and not mounted back. This is because it does not have reboot section so default one is provided. That one just calls `stop` and `start` in sequence. Problem is that `sto...Running `/etc/init.d/fstab restart` causes all FSs to be unmounted and not mounted back. This is because it does not have reboot section so default one is provided. That one just calls `stop` and `start` in sequence. Problem is that `stop` unmounts all FSs but `start` just prints message that `fstab` init script is obsoleted.
This is problematic because as part of update process we restart services. Restart of this service then causes just unmount of all additional FSs.Turris OS 4.0https://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/90Kernel for Turris1x fails to mount BTRFS root2019-11-20T10:50:22+01:00Ondřej CaletkaKernel for Turris1x fails to mount BTRFS rootJust tried current `hbk` and `hbl` medkits for Turris 1.0 (using Btrfs on SD card) and the router keeps restarting with kernel panic, because it cannot mount root fs, caused probably by this:
BTRFS error (device mmcblk0p2): superblo...Just tried current `hbk` and `hbl` medkits for Turris 1.0 (using Btrfs on SD card) and the router keeps restarting with kernel panic, because it cannot mount root fs, caused probably by this:
BTRFS error (device mmcblk0p2): superblock checksum mismatch
When rolled back manually to working Turris OS by taking the SD card out and changing `@` snapshot and `zImage`/`fdt` on FAT32 partition, the recovered TurrisOS remounted the root fs to read only due to broken FS. I had to backup all the data and recreate btrfs from scratch.
`hbt` and `hbs` branches are not affected.Turris OS 4.0.2https://gitlab.nic.cz/turris/os/build/-/issues/34[lxc] Failed to download http://repo.turris.cz/lxc//meta/1.0/index-user2019-06-06T16:01:54+02:00Ghost User[lxc] Failed to download http://repo.turris.cz/lxc//meta/1.0/index-user{"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":"758d612","target":"mvebu\/co...{"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":"758d612","target":"mvebu\/cortexa9","description":"TurrisOS 4.0-beta2 758d612"}}
___
container creation from http://repo.turris.cz/lxc fails with
> Setting up the GPG keyring
> Downloading the image index
> ERROR: Failed to download http://repo.turris.cz/lxc//meta/1.0/index-user
There seems to be a mismatch (index-**user** vs index-**system**), least when browsing the directory
![directory](/uploads/2c71401a8675d13e70c494ec0c2bfe31/directory.png)https://gitlab.nic.cz/turris/os/build/-/issues/37Cannot save LAN settings if the last octet exceeds 222019-06-19T17:00:47+02:00Ghost UserCannot save LAN settings if the last octet exceeds 22Tested in v3.11.4 and does not work in 4b2 either. More info in https://forum.turris.cz/t/cannot-save-any-lan-settings/10341.Tested in v3.11.4 and does not work in 4b2 either. More info in https://forum.turris.cz/t/cannot-save-any-lan-settings/10341.Štěpán HenekŠtěpán Henekhttps://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/40haveged starts too late2020-03-26T11:16:00+01:00Rosen Penevhaveged starts too lateI currently get this when booting my Omnia:
```
[ 6.508803] random: fast init done
[ 9.188468] random: jshn: uninitialized urandom read (4 bytes read)
[ 9.204723] random: jshn: uninitialized urandom read (4 bytes read)
[ 9.2...I currently get this when booting my Omnia:
```
[ 6.508803] random: fast init done
[ 9.188468] random: jshn: uninitialized urandom read (4 bytes read)
[ 9.204723] random: jshn: uninitialized urandom read (4 bytes read)
[ 9.219385] random: jshn: uninitialized urandom read (4 bytes read)
[ 12.865649] urandom_read: 2 callbacks suppressed
[ 12.865652] random: procd: uninitialized urandom read (4 bytes read)
[ 13.056906] urandom-seed: Seeding with /etc/urandom.seed
[ 13.698772] random: ubusd: uninitialized urandom read (4 bytes read)
[ 13.744295] random: ubusd: uninitialized urandom read (4 bytes read)
[ 16.794904] random: crng init done
[ 16.798318] random: 2 urandom warning(s) missed due to ratelimiting
```
The upstream solution uses an alternative to haveged that has START specified to 00 whereas haveged starts at 13. I have no idea how safe or unsafe it is to start haveged earlier.https://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/56infrequent crashes - Unable to handle kernel paging request at virtual address2020-06-29T13:28:18+02:00Ghost Userinfrequent crashes - Unable to handle kernel paging request at virtual address> {"kernel":"4.14.131","hostname":"to","system":"ARMv7 Processor rev 1 (v7l)","model":"Turris Omnia","board_name":"cznic,turris-omnia","release":{"distribution":"TurrisOS","version":"5.0-dev","revision":"202260a","target":"mvebu/cortexa9...> {"kernel":"4.14.131","hostname":"to","system":"ARMv7 Processor rev 1 (v7l)","model":"Turris Omnia","board_name":"cznic,turris-omnia","release":{"distribution":"TurrisOS","version":"5.0-dev","revision":"202260a","target":"mvebu/cortexa9","description":"TurrisOS 5.0-dev 202260a"}}
___
Observing infrequent crashes
[crash_log_1](/uploads/42611189213b46f8c3cb61f5784b104b/crash_log_1)
[crash_log_2](/uploads/267a0d45e01c6feec7ab9770ebdf0d4c/crash_log_2)
[crash_log_3](/uploads/17dd164e05e059b766c44c53126c31ea/crash_log_3)
, cannot reproduce at will, different taints but with what seems to be a common theme:
> Unable to handle kernel paging request at virtual address
> nf_conntrack_in+0xdc/0x714 [nf_conntrack]
`sysctl -a | grep track` [conntrack_kernel_parameters](/uploads/12db03bf3041f89a92e5e28cd3860dc5/conntrack_kernel_parameters)
`opkg list-installed *conntrack*`
> conntrack - 2018-05-01-88610abe-1.0
> iptables-mod-conntrack-extra - 1.8.2-3.51
> kmod-ipt-conntrack - 4.14.131-1-d7317cbbddf2a7868a9735d59f4d4520.0
> kmod-ipt-conntrack-extra - 4.14.131-1-d7317cbbddf2a7868a9735d59f4d4520.0
> kmod-nf-conntrack - 4.14.131-1-d7317cbbddf2a7868a9735d59f4d4520.0
> kmod-nf-conntrack-netlink - 4.14.131-1-d7317cbbddf2a7868a9735d59f4d4520.0
> kmod-nf-conntrack6 - 4.14.131-1-d7317cbbddf2a7868a9735d59f4d4520.0
> libnetfilter-conntrack - 2018-05-01-3ccae9f5-2.0
`lsmod | grep sch_cake`
> nf_conntrack 77824 31 sch_cake,ipt_MASQUERADE,xt_state,xt_nat,xt_helper,xt_conntrack,xt_connmark,xt_connlimit,xt_connbytes,xt_REDIRECT,xt_CT,nft_redir_ipv6,nft_redir_ipv4,nft_redir,nft_nat,nft_masq_ipv6,nft_masq_ipv4,nft_masq,nft_flow_offload,nft_ct,nf_nat_masquerade_ipv6,nf_nat_masquerade_ipv4,nf_conntrack_ipv6,nf_nat_ipv6,nf_conntrack_ipv4,nf_nat_ipv4,nf_nat_ftp,nf_nat,nf_flow_table,nf_conntrack_rtcache,nf_conntrack_ftp
> sch_cake 36864 0
`tc -s qdisc` [tc](/uploads/169deade7c6324df120707a33a047b23/tc)
___
maybe relates to what is displayed during boot
> sch_cake: Unknown symbol nf_conntrack_find_get (err 0)
> sch_cake: Unknown symbol nf_ct_get_tuplepr (err 0)
and a while later the log showing
> nf_conntrack: default automatic helper assignment has been turned off for security reasons and CT-based firewall rule not found. Use the iptables CT target to attach helpers instead.
___
probably no correlation with https://gitlab.labs.nic.cz/turris/turris-build/issues/35
___
lodged with upstream https://bugs.openwrt.org/index.php?do=details&task_id=2346Turris OS 5.1https://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 Behunhttps://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/57Turris Omnia kernel 4.19 support2019-07-31T16:32:53+02:00Karel KociTurris Omnia kernel 4.19 supportUpdate patches for Turris Omnia for kernel 4.19
Upstream set kernel version in master to 4.19 for mvebu architecture. We should follow with that.
Currently we do not have correct device tree because we split it to two device trees. Thi...Update patches for Turris Omnia for kernel 4.19
Upstream set kernel version in master to 4.19 for mvebu architecture. We should follow with that.
Currently we do not have correct device tree because we split it to two device trees. This means that package `omnia-support` fails with following error in master build:
```
install: cannot stat '/home/beast/beast/workspace/turris-os-packages-master-omnia/build/build_dir/target-arm_cortex-a9+vfpv3_musl_eabi/linux-mvebu_cortexa9/linux-4.19.56/arch/arm/boot/dts/armada-385-turris-omnia-*.dtb': No such file or directory
```
Porting patches to 4.19 should fix this.https://gitlab.nic.cz/turris/os/build/-/issues/70Updater won't remove Foris or Luci plugins because of language packages2019-09-02T11:54:15+02:00Karel KociUpdater won't remove Foris or Luci plugins because of language packagesThere is a bug with new code introduced in 1e07e9d4c89bfa004dbc9f6e44ba4ccf0e867e2a and 9656c3d85417e9221c87a98dcc4e36708c3fea22. The problem is that it installs translation packages if package is installed but if request to install that...There is a bug with new code introduced in 1e07e9d4c89bfa004dbc9f6e44ba4ccf0e867e2a and 9656c3d85417e9221c87a98dcc4e36708c3fea22. The problem is that it installs translation packages if package is installed but if request to install that package is no longer present it won't remove it nor translation package. That is because it is already installed. Mentioned code results to languages and in proxy installed package is required. That means it is never removed.
The correct behavior should be that if request to that package is dropped then it is removed and languages are removed as well.
This leads to some weak dependencies but we do not have anything like that in updater so we should think about how to do it with what we have in updater.Turris OS 4.0https://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/72Updater won't remove packages with webapp2019-09-02T11:53:53+02:00Karel KociUpdater won't remove packages with webappThis is same issue and reason as in https://gitlab.labs.nic.cz/turris/turris-build/issues/70 but for webapp packages.This is same issue and reason as in https://gitlab.labs.nic.cz/turris/turris-build/issues/70 but for webapp packages.Turris OS 4.0https://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/80fails to build 4.x2019-10-14T13:51:47+02:00Ghost Userfails to build 4.xTried building 4.x which however fails - run in debug mode (-x) and that is the tail end of the log
>make[4]: *** [Makefile:579: scripts] Error 2
>Removing child 0x56223d073370 PID 16016 from chain.
>make[4]: Leaving directory '/s...Tried building 4.x which however fails - run in debug mode (-x) and that is the tail end of the log
>make[4]: *** [Makefile:579: scripts] Error 2
>Removing child 0x56223d073370 PID 16016 from chain.
>make[4]: Leaving directory '/srv/compiled/tos/4/build_dir/target-arm_cortex-a9+vfpv3_musl_eabi/linux-mvebu_cortexa9/linux-4.14.137'
>Reaping losing child 0x562cd368f3e0 PID 14715
>make[3]: *** [Makefile:22: /srv/compiled/tos/4/build_dir/target-arm_cortex-a9+vfpv3_musl_eabi/linux-mvebu_cortexa9/linux-4.14.137/.modules] Error 2
>Removing child 0x562cd368f3e0 PID 14715 from chain.
>make[3]: Leaving directory '/srv/compiled/tos/4/target/linux/mvebu'
>Reaping losing child 0x5585a94e6920 PID 9658
>make[2]: *** [Makefile:13: compile] Error 2
>Removing child 0x5585a94e6920 PID 9658 from chain.
>make[2]: Leaving directory '/srv/compiled/tos/4/target/linux'
>time: target/linux/compile#35.01#25.67#45.99
>Reaping losing child 0x55cd40eb8650 PID 9650
>make[1]: *** [target/Makefile:25: target/linux/compile] Error 2
>Removing child 0x55cd40eb8650 PID 9650 from chain.
>make[1]: Leaving directory '/srv/compiled/tos/4'
>Reaping losing child 0x55f5ad74e7d0 PID 9624
>make: *** [/srv/compiled/tos/4/include/toplevel.mk:218: target/compile] Error 2
>Removing child 0x55f5ad74e7d0 PID 9624 from chain.
____
Since the verbosity is not very specific of what goes wrong I could only speculate whether one of the reported issues #79 | #78 | #77 could be the cause.
____
the make log [compile.txt](/uploads/6c88f14f856388c53efd00a026dde7fb/compile.txt)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/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/96HBK: wget is removed by updater2019-11-26T18:40:17+01:00Karel KociHBK: wget is removed by updaterThere seems to be a problem with updater not wanting to install `wget` package.
The combination of these two commits probably caused it: 6425621c66c7aff60a47a95bc0d6cee1e8a4fe73 80f46e2b75fbe2baa4b5ca76dbc42b8e556d5e04There seems to be a problem with updater not wanting to install `wget` package.
The combination of these two commits probably caused it: 6425621c66c7aff60a47a95bc0d6cee1e8a4fe73 80f46e2b75fbe2baa4b5ca76dbc42b8e556d5e04Turris OS 4.0.2https://gitlab.nic.cz/turris/os/build/-/issues/97Omnia reboots when wifi is accessed2019-12-09T16:00:13+01:00Karel KociOmnia reboots when wifi is accessedThere is problem in latest HBK and HBT. Omnia reboots (provably because of kernel panic) when wifi is acessed.
It was reported by users and I (@kkoci) was able to reproduce it as well on my home router.There is problem in latest HBK and HBT. Omnia reboots (provably because of kernel panic) when wifi is acessed.
It was reported by users and I (@kkoci) was able to reproduce it as well on my home router.Turris OS 4.0.2https://gitlab.nic.cz/turris/os/build/-/issues/99A CTI router can't update to TOS 4.0.22019-12-11T15:57:10+01:00Vojtech MyslivecA CTI router can't update to TOS 4.0.2A CTI Omnia router in HBS:
```
root@skolka:~# pkgupdate
INFO:Target Turris OS: 4.0.2
WARN:Package wpad is in cyclic dependency. It might fail its post-install script.
WARN:Package hostapd is in cyclic dependency. It might fail its post...A CTI Omnia router in HBS:
```
root@skolka:~# pkgupdate
INFO:Target Turris OS: 4.0.2
WARN:Package wpad is in cyclic dependency. It might fail its post-install script.
WARN:Package hostapd is in cyclic dependency. It might fail its post-install script.
WARN:Requested package pkglists-l10n-cs that is missing, ignoring as requested.
WARN:Requested package luci-i18n-adblock-en that is missing, ignoring as requested.
WARN:Requested package luci-i18n-adblock-cs that is missing, ignoring as requested.
WARN:Requested package luci-i18n-bcp38-en that is missing, ignoring as requested.
WARN:Requested package luci-i18n-bcp38-cs that is missing, ignoring as requested.
WARN:Requested package luci-i18n-mjpg-streamer-en that is missing, ignoring as requested.
WARN:Requested package luci-i18n-mjpg-streamer-cs that is missing, ignoring as requested.
WARN:Requested package luci-i18n-sqm-en that is missing, ignoring as requested.
WARN:Requested package luci-i18n-sqm-cs that is missing, ignoring as requested.
WARN:Requested package luci-i18n-rainbow-en that is missing, ignoring as requested.
WARN:Requested package luci-i18n-rainbow-cs that is missing, ignoring as requested.
line not found
line not found
line not found
line not found
line not found
ERROR:
inconsistent: Requested package turris-survey that is not available.
```
As the output says, updater tries to install `turris-survey` package, which is not available.Turris OS 4.0.2https://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/101kresd on 5.0-dev does not forward requests to the selected server2023-08-16T11:05:36+02:00Giuseppe Piscitellikresd on 5.0-dev does not forward requests to the selected serverI'm using Turris OS 5.0-dev on Omnia. Although it chooses a server from the list of those in Foris / DNS to forward my DNS queries, they continue to be resolved by my ISP's servers. I enclose two screenshots: in the first one we see that...I'm using Turris OS 5.0-dev on Omnia. Although it chooses a server from the list of those in Foris / DNS to forward my DNS queries, they continue to be resolved by my ISP's servers. I enclose two screenshots: in the first one we see that the configuration (in the example with Cloudflare) is correctly loaded in kresd; in the other, we see that by performing a test on dnsleaktest.com the server used is that of Telecom Italia (my ISP).
In addition, using reForis and opening the DNS tab, I see an error, which could be related to the bug above.![Schermata_del_2019-12-13_17-19-33](/uploads/3ce8d8c015b057f921d4dbda4a332bf2/Schermata_del_2019-12-13_17-19-33.png)![Schermata_del_2019-12-13_17-20-15](/uploads/4a50adf486266a26f9349b8e10bb0423/Schermata_del_2019-12-13_17-20-15.png)![Schermata_del_2019-12-13_15-47-50](/uploads/026f1bd7943d9d502e89ebd14cd79098/Schermata_del_2019-12-13_15-47-50.png)Jan PavlinecJan Pavlinechttps://gitlab.nic.cz/turris/os/build/-/issues/104Turris 1.x - flooding syslog with mmcblk0: error -84 transferring data and mm...2020-01-15T10:46:50+01:00Josef SchlehoferTurris 1.x - flooding syslog with mmcblk0: error -84 transferring data and mmc0: Internal clock never stabilised.I have been running HBK branch on Turris 1.1 for some time, but with the recent builds, my syslog is flooded with those messages:
```
Jan 7 20:59:48 turris kernel: [93318.602435] mmcblk0: error -84 transferring data, sector 903456, nr...I have been running HBK branch on Turris 1.1 for some time, but with the recent builds, my syslog is flooded with those messages:
```
Jan 7 20:59:48 turris kernel: [93318.602435] mmcblk0: error -84 transferring data, sector 903456, nr 64, cmd response 0x900, card status 0xc00
Jan 7 20:59:48 turris kernel: [93318.632515] mmc0: Internal clock never stabilised.
```
So, I thought this is microSD card issue as it happened on one our routers at work, which was running HBD. I removed the microSD card, insert there a new one, flashed it with HBS branch and it was running for an hour flawlessly. I used `switch-branch` to `hbk` and my router almost does not want to boot up, because those messages were back.Turris OS 4.0.5https://gitlab.nic.cz/turris/os/build/-/issues/105Turris 1.x: add fw_env.config for uboot-tools2020-12-02T14:11:53+01:00Karel KociTurris 1.x: add fw_env.config for uboot-toolsConfiguration for uboot tools is missing. We should either add it to uboot-tools package or we can just provide file `/etc/fw_env.config` with content
```
/dev/mtd5 0x20000 0x2000 0x20000
```Configuration for uboot tools is missing. We should either add it to uboot-tools package or we can just provide file `/etc/fw_env.config` with content
```
/dev/mtd5 0x20000 0x2000 0x20000
```Turris OS 5.2.0https://gitlab.nic.cz/turris/os/build/-/issues/110Package LXC fails to build2020-01-16T14:28:16+01:00Karel KociPackage LXC fails to buildFailed to build with:
```
OpenWrt-libtool: compile: ccache_cc -DHAVE_CONFIG_H -I. -I../../src -I/home/beast/beast/workspace/turris-os-packages-kittens-omnia/build/staging_dir/target-arm_cortex-a9+vfpv3_musl_eabi/usr/include -I/home/bea...Failed to build with:
```
OpenWrt-libtool: compile: ccache_cc -DHAVE_CONFIG_H -I. -I../../src -I/home/beast/beast/workspace/turris-os-packages-kittens-omnia/build/staging_dir/target-arm_cortex-a9+vfpv3_musl_eabi/usr/include -I/home/beast/beast/workspace/turris-os-packages-kittens-omnia/build/staging_dir/target-arm_cortex-a9+vfpv3_musl_eabi/include -I/home/beast/beast/workspace/turris-os-packages-kittens-omnia/build/staging_dir/toolchain-arm_cortex-a9+vfpv3_gcc-7.3.0_musl_eabi/usr/include -I/home/beast/beast/workspace/turris-os-packages-kittens-omnia/build/staging_dir/toolchain-arm_cortex-a9+vfpv3_gcc-7.3.0_musl_eabi/include/fortify -I/home/beast/beast/workspace/turris-os-packages-kittens-omnia/build/staging_dir/toolchain-arm_cortex-a9+vfpv3_gcc-7.3.0_musl_eabi/include -fPIC -DPIC -DLXCROOTFSMOUNT=\"/usr/lib/lxc/rootfs\" -DLXCPATH=\"/srv/lxc\" -DLXC_GLOBAL_CONF=\"/etc/lxc/lxc.conf\" -DLXCINITDIR=\"/usr/lib\" -DLIBEXECDIR=\"/usr/lib\" -DLXCTEMPLATEDIR=\"/usr/share/lxc/templates\" -DLXCTEMPLATECONFIG=\"/usr/share/lxc/config\" -DLOGPATH=\"/var/log/lxc\" -DLXC_DEFAULT_CONFIG=\"/etc/lxc/default.conf\" -DLXC_USERNIC_DB=\"/var/run/lxc/nics\" -DLXC_USERNIC_CONF=\"/etc/lxc/lxc-usernet\" -DDEFAULT_CGROUP_PATTERN=\"lxc/%n\" -DRUNTIME_PATH=\"/var/run\" -DSBINDIR=\"/usr/sbin\" -I ../../src -I ../../src/lxc -I ../../src/lxc/storage -I ../../src/lxc/cgroups -DHAVE_SECCOMP -I/home/beast/beast/workspace/turris-os-packages-kittens-omnia/build/staging_dir/target-arm_cortex-a9+vfpv3_musl_eabi/usr/include -pthread -Os -pipe -mcpu=cortex-a9 -mfpu=vfpv3-d16 -fno-caller-saves -fno-plt -fhonour-copts -Wno-error=unused-but-set-variable -Wno-error=unused-result -mfloat-abi=hard -iremap/home/beast/beast/workspace/turris-os-packages-kittens-omnia/build/build_dir/target-arm_cortex-a9+vfpv3_musl_eabi/lxc-3.0.3:lxc-3.0.3 -Wformat -Werror=format-security -fstack-protector -D_FORTIFY_SOURCE=1 -Wl,-z,now -Wl,-z,relro -fdiagnostics-color -Wimplicit-fallthrough -Wcast-align -fno-strict-aliasing -fstack-protector-strong -g -Werror=implicit-function-declaration -Wvla -std=gnu11 -Werror -MT liblxc_la-seccomp.lo -MD -MP -MF .deps/liblxc_la-seccomp.Tpo -c seccomp.c -fPIC -DPIC -o .libs/liblxc_la-seccomp.o
In file included from �[01m�[Kseccomp.c:28:0�[m�[K:
�[01m�[K/home/beast/beast/workspace/turris-os-packages-kittens-omnia/build/staging_dir/target-arm_cortex-a9+vfpv3_musl_eabi/usr/include/seccomp.h:705:10:�[m�[K �[01;31m�[Kfatal error: �[m�[Kseccomp-syscalls.h: No such file or directory
#include �[01;31m�[K<seccomp-syscalls.h>�[m�[K
�[01;31m�[K^~~~~~~~~~~~~~~~~~~~�[m�[K
compilation terminated.
```Turris OS 4.0.5https://gitlab.nic.cz/turris/os/build/-/issues/111Borked update of libubox causes procd crash but fixes security issue2023-08-16T11:03:51+02:00Karel KociBorked update of libubox causes procd crash but fixes security issueOpenWrt updated in 19.07 libubox and introduced bug that can be invoked by using `procd_add_param pidfile` in init file. This causes in some cases crash of procd.
Initially we fixed it by reverting it but it is required for security fix...OpenWrt updated in 19.07 libubox and introduced bug that can be invoked by using `procd_add_param pidfile` in init file. This causes in some cases crash of procd.
Initially we fixed it by reverting it but it is required for security fix in ucert. We do not want to revert ucert as well but it fails to build otherwise.Turris OS 5.0https://gitlab.nic.cz/turris/os/build/-/issues/190lists: pkglist drivers do not correctly install ct-htt wifi drivers2023-08-16T11:01:13+02:00Marcela Blazkovalists: pkglist drivers do not correctly install ct-htt wifi drivers![19055908](/uploads/e991e4400f675413ea55cc0c65c015ce/19055908.png)
![19055905](/uploads/2228833525bd10ae0fa1404f6bf0143f/19055905.png)![19055908](/uploads/e991e4400f675413ea55cc0c65c015ce/19055908.png)
![19055905](/uploads/2228833525bd10ae0fa1404f6bf0143f/19055905.png)Turris OS 5.1.3https://gitlab.nic.cz/turris/os/build/-/issues/103crashes in Foris (controller | client)2023-08-16T11:05:33+02:00Ghost Usercrashes in Foris (controller | client)>* {"kernel":"4.14.162","hostname":"to","system":"ARMv7 Processor rev 1 (v7l)","model":"Turris Omnia","board_name":"cznic,turris-omnia","release":{"distribution":TurrisOS","version":"5.0-dev","revision":"e7908af","target":"mvebu/cortexa9...>* {"kernel":"4.14.162","hostname":"to","system":"ARMv7 Processor rev 1 (v7l)","model":"Turris Omnia","board_name":"cznic,turris-omnia","release":{"distribution":TurrisOS","version":"5.0-dev","revision":"e7908af","target":"mvebu/cortexa9","description":"TurrisOS 5.0-dev eb156345419953a382cda233bffa4291f5cb78d8"}}
* also happens with a TOS Master instance
___
`/etc/init.d/foris-controller start` produces
>foris-controller: Traceback (most recent call last):
>foris-controller: File "/usr/bin/foris-controller", line 11, in <module>
>foris-controller: load_entry_point('foris-controller==1.0.8', 'console_scripts', 'foris-controller')()
>foris-controller: File "/__main__.py", line 184, in main
>foris-controller: File "/mqtt.py", line 417, in __init__
>foris-controller: File "/usr/lib/python3.7/site-packages/paho/mqtt/client.py", line 937, in connect
>foris-controller: return self.reconnect()
>foris-controller: File "/usr/lib/python3.7/site-packages/paho/mqtt/client.py", line 1071, in reconnect
>foris-controller: sock = self._create_socket_connection()
>foris-controller: File "/usr/lib/python3.7/site-packages/paho/mqtt/client.py", line 3522, in _create_socket_connection
>foris-controller: return socket.create_connection(addr, source_address=source, timeout=self._keepalive)
>foris-controller: File "/socket.py", line 728, in create_connection
>foris-controller: File "/socket.py", line 716, in create_connection
>foris-controller: ConnectionRefusedError: [Errno 111] Connection refused
finally terminating with
>procd: Instance foris-controller::instance1 s in a crash loop 6 crashes, 1 seconds since last crash
___
potential domino effect (or separate issue)
`ps | lighttpd -D -f /etc/lighttpd/lighttpd.conf`
>Traceback (most recent call last):
> File "/usr/bin/foris", line 11, in <module>
> load_entry_point('Foris==100.6', 'console_scripts', 'foris')()
> File "/__main__.py", line 124, in main
> File "/backend.py", line 62, in __init__
> File "/mqtt.py", line 184, in __init__
> File "/base.py", line 56, in __init__
>Exception in thread foris-client-reply-listener:
>Traceback (most recent call last):
> File "/threading.py", line 926, in _bootstrap_inner
> File "/mqtt.py", line 161, in run
> File "/usr/lib/python3.7/site-packages/paho/mqtt/client.py", line 937, in connect
> return self.reconnect()
> File "/usr/lib/python3.7/site-packages/paho/mqtt/client.py", line 1071, in reconnect
> sock = self._create_socket_connection()
> File "/usr/lib/python3.7/site-packages/paho/mqtt/client.py", line 3522, in _create_socket_connection
> return socket.create_connection(addr, source_address=source, timeout=self._keepalive)
> File "/socket.py", line 728, in create_connection
> File "/socket.py", line 716, in create_connection
>ConnectionRefusedError: [Errno 111] Connection refusedTurris OS 4.0.6https://gitlab.nic.cz/turris/os/build/-/issues/113compilation issues for nodejs2023-08-16T11:03:50+02:00Michael Richardsoncompilation issues for nodejsHere Be Kittens, with the update that fixes #111 fails with:
gyp info spawn args [ 'BUILDTYPE=Release', '-C', 'build' ]
make[4]: Entering directory '/ssw/projects/cerowrt/turris-build/build/build_dir/target-arm_cortex-a9+vfpv3_m...Here Be Kittens, with the update that fixes #111 fails with:
gyp info spawn args [ 'BUILDTYPE=Release', '-C', 'build' ]
make[4]: Entering directory '/ssw/projects/cerowrt/turris-build/build/build_dir/target-arm_cortex-a9+vfpv3_musl_eabi/node-hashtable-2.0.2/ipkg-install/usr/lib/node_modules/hashtable/build'
ccache_cxx '-DNODE_GYP_MODULE_NAME=native' '-DUSING_UV_SHARED=1' '-DUSING_V8_SHARED=1' '-DV8_DEPRECATION_WARNINGS=1' '-DV8_DEPRECATION_WARNINGS' '-DV8_IMMINENT_DEPRECATION_WARNINGS' '-D_LARGEFILE_SOURCE' '-D_FILE_OFFSET_BITS=64' '-DOPENSSL_NO_PINSHARED' '-DOPENSSL_THREADS' '-DBUILDING_NODE_EXTENSION' -I/ssw/projects/cerowrt/turris-build/build/staging_dir/target-arm_cortex-a9+vfpv3_musl_eabi/usr/include/node -I/ssw/projects/cerowrt/turris-build/build/staging_dir/target-arm_cortex-a9+vfpv3_musl_eabi/usr/src -I/ssw/projects/cerowrt/turris-build/build/staging_dir/target-arm_cortex-a9+vfpv3_musl_eabi/usr/deps/openssl/config -I/ssw/projects/cerowrt/turris-build/build/staging_dir/target-arm_cortex-a9+vfpv3_musl_eabi/usr/deps/openssl/openssl/include -I/ssw/projects/cerowrt/turris-build/build/staging_dir/target-arm_cortex-a9+vfpv3_musl_eabi/usr/deps/uv/include -I/ssw/projects/cerowrt/turris-build/build/staging_dir/target-arm_cortex-a9+vfpv3_musl_eabi/usr/deps/zlib -I/ssw/projects/cerowrt/turris-build/build/staging_dir/target-arm_cortex-a9+vfpv3_musl_eabi/usr/deps/v8/include -I../node_modules/nan -fPIC -pthread -Wall -Wextra -Wno-unused-parameter -std=c++11 -Wall -O3 -fno-omit-frame-pointer -fno-rtti -fno-exceptions -std=gnu++1y -MMD -MF ./Release/.deps/Release/obj.target/native/src/hashtable.o.d.raw -Os -pipe -fno-caller-saves -fno-plt -fhonour-copts -Wno-error=unused-but-set-variable -Wno-error=unused-result -mfloat-abi=hard -iremap/ssw/projects/cerowrt/turris-build/build/build_dir/target-arm_cortex-a9+vfpv3_musl_eabi/node-hashtable-2.0.2:node-hashtable-2.0.2 -Wformat -Werror=format-security -fpic -fstack-protector-strong -D_FORTIFY_SOURCE=2 -Wl,-z,now -Wl,-z,relro -fpic -I/ssw/projects/cerowrt/turris-build/build/staging_dir/target-arm_cortex-a9+vfpv3_musl_eabi/usr/include -I/ssw/projects/cerowrt/turris-build/build/staging_dir/target-arm_cortex-a9+vfpv3_musl_eabi/include -I/ssw/projects/cerowrt/turris-build/build/staging_dir/toolchain-arm_cortex-a9+vfpv3_gcc-7.5.0_musl_eabi/usr/include -I/ssw/projects/cerowrt/turris-build/build/staging_dir/toolchain-arm_cortex-a9+vfpv3_gcc-7.5.0_musl_eabi/include/fortify -I/ssw/projects/cerowrt/turris-build/build/staging_dir/toolchain-arm_cortex-a9+vfpv3_gcc-7.5.0_musl_eabi/include -fpic -c -o Release/obj.target/native/src/hashtable.o ../src/hashtable.cpp
In file included from ../src/hashtable.h:15:0,
from ../src/hashtable.cpp:1:
../src/v8_value_hasher.h: In member function 'bool v8_value_equal_to::operator()(CopyablePersistent*, CopyablePersistent*) const':
../src/v8_value_hasher.h:43:24: error: no matching function for call to 'v8::Value::Equals(v8::Local<v8::Value>&)'
if (a->Equals(b)) { /* same as JS == */
^
In file included from /ssw/projects/cerowrt/turris-build/build/staging_dir/target-arm_cortex-
a9+vfpv3_musl_eabi/usr/include/node/node.h:63:0,
from ../src/hashtable.h:13,
from ../src/hashtable.cpp:1:
/ssw/projects/cerowrt/turris-build/build/staging_dir/target-arm_cortex-
9+vfpv3_musl_eabi/usr/include/node/v8.h:2616:37: note: candidate: v8::Maybe<bool>
v8::Value::Equals(v8::Local<v8::Context>, v8::Local<v8::Value>) const V8_WARN_UNUSED_RESULT Maybe<bool>
Equals(Local<Context> context,
...
(I'm not blaming #111 for this, I couldn't get this far before)
I run:
./compile_pkgs -t omnia -p hbk -x prepare_tools
cd build
make V=s
because ./generate_medkit usually dies with issues in updater_ng, which I gave up trying to fix, and from my reading of that, I don't need that to work now if I don't care about having patches available. Maybe they are related.
I have no personal need for nodejs, I'd just disable it, but other stuff seems to require, and I don't know what yet.https://gitlab.nic.cz/turris/os/build/-/issues/114Transmission does not start through procd2023-08-16T11:03:47+02:00Stepan MocekTransmission does not start through procdAfter update from 21.1. and a reboot of Turris Omnia was the contact with Transmission lost. It does not work even with TOS 4.X.After update from 21.1. and a reboot of Turris Omnia was the contact with Transmission lost. It does not work even with TOS 4.X.Turris OS 5.0.2https://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/117Pakon Signature verification failure2020-02-24T16:54:58+01:00Jan HoracekPakon Signature verification failureIt is not possible to update due to broken signature on one HBL user list
runtime: [string "requests"]:417: [string "utils"]:429: Unable to finish URI (https://repo.turris.cz/hbl/omnia/lists/pkglists/pakon.lua): Signature verification f...It is not possible to update due to broken signature on one HBL user list
runtime: [string "requests"]:417: [string "utils"]:429: Unable to finish URI (https://repo.turris.cz/hbl/omnia/lists/pkglists/pakon.lua): Signature verification failureTurris OS 5.0https://gitlab.nic.cz/turris/os/build/-/issues/118java issues with building on plain Ubuntu LTS 18.042023-08-16T11:04:15+02:00Michael Richardsonjava issues with building on plain Ubuntu LTS 18.04I've abandoned the build host that I used successfully in 2019, and spun up an EC2 with Ubuntu 18.04.
classpath-0.99 needs a javac. (Why do we need classpath... I don't know).
openjdk does not seem to satisfy it.
gcj doesn't seem to be a...I've abandoned the build host that I used successfully in 2019, and spun up an EC2 with Ubuntu 18.04.
classpath-0.99 needs a javac. (Why do we need classpath... I don't know).
openjdk does not seem to satisfy it.
gcj doesn't seem to be a thing on ubuntu.
oracle java 11 or 13 seems to be incompatible, so I copied java 8 from my old build server and adjusted /etc/alternatives/javac.... but now I get the following silly warning that becomes an error.
Sigh.
```
make[7]: Entering directory '/home/ubuntu/turris-build/build/build_dir/target-arm_cortex-a9+vfpv3_musl_eabi/classpath-0.99/native/jni/java-math'
/bin/bash ../../../libtool --tag=CC --mode=compile ccache_cc -DHAVE_CONFIG_H -I. -I../../../include -I../../../include -I../../../native/jni/classpath -I../../../native/jni/native-lib -I/home/ubuntu/turris-build/build/staging_dir/target-arm_cortex-a9+vfpv3_musl_eabi/usr/include -I/home/ubuntu/turris-build/build/staging_dir/target-arm_cortex-a9+vfpv3_musl_eabi/include -I/home/ubuntu/turris-build/build/staging_dir/toolchain-arm_cortex-a9+vfpv3_gcc-7.3.0_musl_eabi/usr/include -I/home/ubuntu/turris-build/build/staging_dir/toolchain-arm_cortex-a9+vfpv3_gcc-7.3.0_musl_eabi/include/fortify -I/home/ubuntu/turris-build/build/staging_dir/toolchain-arm_cortex-a9+vfpv3_gcc-7.3.0_musl_eabi/include -W -Wall -Wmissing-declarations -Wwrite-strings -Wmissing-prototypes -Wno-long-long -Werror -I/home/ubuntu/turris-build/build/staging_dir/target-arm_cortex-a9+vfpv3_musl_eabi/usr/include -Os -pipe -mcpu=cortex-a9 -mfpu=vfpv3-d16 -fno-caller-saves -fno-plt -fhonour-copts -Wno-error=unused-but-set-variable -Wno-error=unused-result -mfloat-abi=hard -iremap/home/ubuntu/turris-build/build/build_dir/target-arm_cortex-a9+vfpv3_musl_eabi/classpath-0.99:classpath-0.99 -Wformat -Werror=format-security -fstack-protector -D_FORTIFY_SOURCE=1 -Wl,-z,now -Wl,-z,relro -MT gnu_java_math_GMP.lo -MD -MP -MF .deps/gnu_java_math_GMP.Tpo -c -o gnu_java_math_GMP.lo gnu_java_math_GMP.c
OpenWrt-libtool: compile: ccache_cc -DHAVE_CONFIG_H -I. -I../../../include -I../../../include -I../../../native/jni/classpath -I../../../native/jni/native-lib -I/home/ubuntu/turris-build/build/staging_dir/target-arm_cortex-a9+vfpv3_musl_eabi/usr/include -I/home/ubuntu/turris-build/build/staging_dir/target-arm_cortex-a9+vfpv3_musl_eabi/include -I/home/ubuntu/turris-build/build/staging_dir/toolchain-arm_cortex-a9+vfpv3_gcc-7.3.0_musl_eabi/usr/include -I/home/ubuntu/turris-build/build/staging_dir/toolchain-arm_cortex-a9+vfpv3_gcc-7.3.0_musl_eabi/include/fortify -I/home/ubuntu/turris-build/build/staging_dir/toolchain-arm_cortex-a9+vfpv3_gcc-7.3.0_musl_eabi/include -W -Wall -Wmissing-declarations -Wwrite-strings -Wmissing-prototypes -Wno-long-long -Werror -I/home/ubuntu/turris-build/build/staging_dir/target-arm_cortex-a9+vfpv3_musl_eabi/usr/include -Os -pipe -mcpu=cortex-a9 -mfpu=vfpv3-d16 -fno-caller-saves -fno-plt -fhonour-copts -Wno-error=unused-but-set-variable -Wno-error=unused-result -mfloat-abi=hard -iremap/home/ubuntu/turris-build/build/build_dir/target-arm_cortex-a9+vfpv3_musl_eabi/classpath-0.99:classpath-0.99 -Wformat -Werror=format-security -fstack-protector -D_FORTIFY_SOURCE=1 -Wl,-z,now -Wl,-z,relro -MT gnu_java_math_GMP.lo -MD -MP -MF .deps/gnu_java_math_GMP.Tpo -c gnu_java_math_GMP.c -fPIC -DPIC -o .libs/gnu_java_math_GMP.o
gnu_java_math_GMP.c: In function 'Java_gnu_java_math_GMP_natSetBitCount':
gnu_java_math_GMP.c:1134:13: error: this statement may fall through [-Werror=implicit-fallthrough=]
res = mpz_popcount (_this);
~~~~^~~~~~~~~~~~~~~~~~~~~~
gnu_java_math_GMP.c:1135:7: note: here
default:
^~~~~~~
cc1: all warnings being treated as errors
Makefile:531: recipe for target 'gnu_java_math_GMP.lo' failed
make[7]: *** [gnu_java_math_GMP.lo] Error 1
make[7]: Leaving directory '/home/ubuntu/turris-build/build/build_dir/target-arm_cortex-a9+vfpv3_musl_eabi/classpath-0.99/native/jni/java-math'
Makefile:469: recipe for target 'all-recursive' failed
make[6]: *** [all-recursive] Error 1
make[6]: Leaving directory '/home/ubuntu/turris-build/build/build_dir/target-arm_cortex-a9+vfpv3_musl_eabi/classpath-0.99/native/jni'
Makefile:457: recipe for target 'all-recursive' failed
make[5]: *** [all-recursive] Error 1
make[5]: Leaving directory '/home/ubuntu/turris-build/build/build_dir/target-arm_cortex-a9+vfpv3_musl_eabi/classpath-0.99/native'
Makefile:516: recipe for target 'all-recursive' failed
make[4]: *** [all-recursive] Error 1
```https://gitlab.nic.cz/turris/os/build/-/issues/119Package tvheadend requires package libx264 that is not available2020-03-09T19:06:22+01:00Karel KociPackage tvheadend requires package libx264 that is not availableTurris OS 5.0https://gitlab.nic.cz/turris/os/build/-/issues/120Requested package lvm2 that is not available2023-08-16T11:05:31+02:00Karel KociRequested package lvm2 that is not availableTurris OS 5.0https://gitlab.nic.cz/turris/os/build/-/issues/121Package mariadb-server requires package libaio that is not available2023-08-16T11:05:28+02:00Karel KociPackage mariadb-server requires package libaio that is not availableTurris OS 5.0https://gitlab.nic.cz/turris/os/build/-/issues/123HBL: Package perf is not compiled2020-03-04T22:17:39+01:00Michael RichardsonHBL: Package perf is not compiledOn an Ubuntu 18.04 LTS host (EC2), with hbl checked out, after running `compile_pkgs prepare_tools -t omnia `
successfully, a build fails with:
```
Makefile.config:304: *** No gnu/libc-version.h found, please install glibc-dev[el]. St...On an Ubuntu 18.04 LTS host (EC2), with hbl checked out, after running `compile_pkgs prepare_tools -t omnia `
successfully, a build fails with:
```
Makefile.config:304: *** No gnu/libc-version.h found, please install glibc-dev[el]. Stop.
Makefile.perf:203: recipe for target 'sub-make' failed
make[4]: *** [sub-make] Error 2
Makefile:76: recipe for target '/home/ubuntu/turris-build/build/build_dir/target-arm_cortex-a9+vfpv3_musl_eabi/linux-mvebu_cortexa9/linux-4.14.171/tools/perf-target-arm_cortex-a9+vfpv3_musl_eabi/.built' failed
make[3]: *** [/home/ubuntu/turris-build/build/build_dir/target-arm_cortex-a9+vfpv3_musl_eabi/linux-mvebu_cortexa9/linux-4.14.171/tools/perf-target-arm_cortex-a9+vfpv3_musl_eabi/.built] Error 2
```
I will attempt again after cleaning the build directory again.
I tried hbl, after failing repeatedly with hbk, and 4.0.5.https://gitlab.nic.cz/turris/os/build/-/issues/124Turris 1.x: fails to boot2021-07-28T14:03:28+02:00Karel KociTurris 1.x: fails to bootBooting Turris 1.x in HBL fails to continue. Last message is warning.
```
Hit any key to stop autoboot: 0
BOOT NAND
reading zImage
4310887 bytes read in 197 ms (20.9 MiB/s)
wdt status 00000003
reading fdt
13241 bytes read in 14 ms (92...Booting Turris 1.x in HBL fails to continue. Last message is warning.
```
Hit any key to stop autoboot: 0
BOOT NAND
reading zImage
4310887 bytes read in 197 ms (20.9 MiB/s)
wdt status 00000003
reading fdt
13241 bytes read in 14 ms (922.9 KiB/s)
WARNING: adjusting available memory to 30000000
## Booting kernel from Legacy Image at 02100000 ...
Image Name: Linux-4.14.171
Created: 2020-03-03 0:13:45 UTC
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 4310823 Bytes = 4.1 MiB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
## Flattened Device Tree blob at 02000000
Booting using the fdt blob at 0x2000000
Uncompressing Kernel Image ... OK
Loading Device Tree to 03ff9000, end 03fff3b8 ... OK
WARNING: could not find compatible node fsl-usb2-dr
```
The question is why it fails to boot. It seems to correctly load everything but kernel just prints only this warning and that is it.Turris OS 5.0https://gitlab.nic.cz/turris/os/build/-/issues/125Turris 1.x: no interfaces for DSA switch chip2020-03-04T12:32:37+01:00Karel KociTurris 1.x: no interfaces for DSA switch chipOn HBL there are no LAN interfaces from DSA managed switch chip.On HBL there are no LAN interfaces from DSA managed switch chip.Turris OS 5.0https://gitlab.nic.cz/turris/os/build/-/issues/129extended Active Connections2020-03-17T13:26:19+01:00Jan Horacekextended Active ConnectionsIt would be advisable to increase the number of active connections that the router can serve to a value corresponding to at least the version of TOS 3.x ie 65536 or moreIt would be advisable to increase the number of active connections that the router can serve to a value corresponding to at least the version of TOS 3.x ie 65536 or moreTurris 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/136busybox collision with binutils2023-08-16T11:04:11+02:00Ghost Userbusybox collision with binutilsexhibits on
> {"kernel":"4.19.93","hostname":"to","system":"ARMv7 Processor rev 1 (v7l)","model":"Turris Omnia","board_name":"cznic,turris-omnia","release":{"distribution":"TurrisOS","version":"6.0-future","revision":"a52af5d","target":...exhibits on
> {"kernel":"4.19.93","hostname":"to","system":"ARMv7 Processor rev 1 (v7l)","model":"Turris Omnia","board_name":"cznic,turris-omnia","release":{"distribution":"TurrisOS","version":"6.0-future","revision":"a52af5d","target":"mvebu/cortexa9","description":"TurrisOS 6.0-future 7936cb94a930dcff0d30d294efb693648e1768ff"}}
and
>{"kernel":"4.14.172","hostname":"to","system":"ARMv7 Processor rev 1 (v7l)","model":"Turris Omnia","board_name":"cznic,turris-omnia","release":{"distribution":"TurrisOS","version":"5.1.0","revision":"5b9b833","target":"mvebu/cortexa9","description":"TurrisOS 5.1.0 5b9b833f8c4dc973f557e90f1038d7d3f1d2042b"}}
___
trying to install *gcc* package terminates with
>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"]:328: [string "transaction"]:153: Collisions:
>• /bin/strings: busybox (existing-file), binutils (new-file)Turris OS 5.0https://gitlab.nic.cz/turris/os/build/-/issues/138Cannot install less2023-08-16T11:04:09+02:00Leonardo Brondani SchenkelCannot install lessTurrisOS 5.0.0 (but happened on earlier versions as well)
```
# opkg install less
Installing less (530-1.0) to root...
Downloading https://repo.turris.cz/hbt/omnia/packages/packages/less_530-1_arm_cortex-a9_vfpv3.ipk
Collected errors:
...TurrisOS 5.0.0 (but happened on earlier versions as well)
```
# opkg install less
Installing less (530-1.0) to root...
Downloading https://repo.turris.cz/hbt/omnia/packages/packages/less_530-1_arm_cortex-a9_vfpv3.ipk
Collected errors:
* check_data_file_clashes: Package less wants to install file /bin/less
But that file is already provided by package * busybox
* opkg_install_cmd: Cannot install package less.
```
Shouldn't be this be using the alternative system as mentioned in https://gitlab.labs.nic.cz/turris/turris-os-packages/issues/579?https://gitlab.nic.cz/turris/os/build/-/issues/139Limit size of lighttpd error log2023-08-16T11:01:05+02:00Karel KociLimit size of lighttpd error logLighttpd is configured to create error log in `/var/log/lighttpd/error.log`. This just grows and logs every error lighttpd encounters. It is possible that it eats whole `/tmp` when some web service starts periodically failing.
* [ ] We ...Lighttpd is configured to create error log in `/var/log/lighttpd/error.log`. This just grows and logs every error lighttpd encounters. It is possible that it eats whole `/tmp` when some web service starts periodically failing.
* [ ] We should limit line duplicates somehow (possibly by sending log trough syslog?)
* [x] Logrotate should be configured for this logTurris OS 5.2.0Jan PavlinecJan Pavlinechttps://gitlab.nic.cz/turris/os/build/-/issues/141Mox: kernel fails to boot because of sparse blocks2020-04-27T09:54:46+02:00Karel KociMox: kernel fails to boot because of sparse blocksU-boot in Turris Mox fails to correctly reads sparse blocks from BTRFS. Boot fails if kernel is saved to FS with such content.
Common output on serial console:
```
U-Boot 2018.11 (Dec 16 2018 - 12:50:19 +0000), Build: jenkins-turris-os-...U-boot in Turris Mox fails to correctly reads sparse blocks from BTRFS. Boot fails if kernel is saved to FS with such content.
Common output on serial console:
```
U-Boot 2018.11 (Dec 16 2018 - 12:50:19 +0000), Build: jenkins-turris-os-packages-kittens-mox-90
DRAM: 512 MiB
Enabling Armada 3720 wComphy-0: SGMII1 3.125 Gbps
Comphy-1: PEX0 5 Gbps
Comphy-2: USB3_HOST0 5 Gbps
MMC: sdhci@d8000: 0
Loading Environment from SPI Flash... SF: Detected w25q64dw with page size 256 Bytes, erase size 4 KiB, total 8 MiB
OK
Model: CZ.NIC Turris Mox Board
Net: eth0: neta@30000
Turris Mox:
Board version: 22
RAM size: 512 MiB
Serial Number: 000000000000000
ECDSA Public Key: 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
SD/eMMC version: SD
Module Topology:
1: Passthrough Mini-PCIe Module
2: USB 3.0 Module (4 ports)
3: Topaz Switch Module (4-port)
Hit any key to stop autoboot: 0
gpio: pin GPIO221 (gpio 57) value is 0
gpio: pin GPIO220 (gpio 56) value is 1
SF: Detected w25q64dw with page size 256 Bytes, erase size 4 KiB, total 8 MiB
device 0 offset 0x7f0000, size 0x10000
SF: 65536 bytes @ 0x7f0000 Read: OK
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found U-Boot script /boot.scr
963 bytes read in 90 ms (9.8 KiB/s)
## Executing script at 04d00000
19412 bytes read in 61 ms (310.5 KiB/s)
btrfs_map_logical_to_physical: Cannot map logical address 0 to physical
btrfs_file_read: Error reading extent
An error occured while reading file /@/boot/Image
0 bytes read in 384 ms (0 Bytes/s)
## Flattened Device Tree blob at 04f00000
Booting using the fdt blob at 0x4f00000
Loading Device Tree to 000000001bf14000, end 000000001bf1bbd3 ... OK
Starting kernel ...
"Synchronous Abort" handler, esr 0x02000000
elr: ffffffffe5a4d000 lr : 00000000000026c4 (reloc)
elr: 0000000005980000 lr : 000000001ff356c4
x0 : 000000001bf14000 x1 : 0000000000000000
x2 : 0000000000000000 x3 : 0000000000000000
x4 : 0000000005080000 x5 : 0000000000000001
x6 : 0000000000000008 x7 : 0000000000000000
x8 : 000000001c100000 x9 : 0000000000000002
x10: 000000000a200023 x11: 0000000000000002
x12: 0000000000000002 x13: 00000000ffffffff
x14: 0000000000000000 x15: 000000001ff34b34
x16: 0000000000000002 x17: 000000001bf1bbd4
x18: 000000001bf22de8 x19: 000000001ffd39d0
x20: 0000000000000000 x21: 0000000000000000
x22: 0000000000000003 x23: 000000001bfd3238
x24: 000000001ffc1b00 x25: 0000000000000000
x26: 000000001ff356ec x27: 0000000000000400
x28: 000000001bfd3260 x29: 000000001bf1d890
Resetting CPU ...
resetting ...
```Turris OS 5.0Michal HruseckyMichal Hruseckyhttps://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/145foris & luci unreachable on 5.02020-05-14T17:22:28+02:00Claude Nobsforis & luci unreachable on 5.0some recent update broke foris & luci (but not reforis) on my turris omnia.
current version:
TurrisOS 5.0.0 a8c92e9eda1f9f801345255eac80bf16f65f6f4c
# symptoms
foris would just not show up
luci, after a long time shows :
`/usr/lib/lu...some recent update broke foris & luci (but not reforis) on my turris omnia.
current version:
TurrisOS 5.0.0 a8c92e9eda1f9f801345255eac80bf16f65f6f4c
# symptoms
foris would just not show up
luci, after a long time shows :
`/usr/lib/lua/luci/dispatcher.lua:426: /etc/config/luci seems to be corrupt, unable to find section 'main'`
# solution
`ln -sfn /usr/bin/python3 /usr/bin/python`
don't know whether that fix solves the issue or is just a workaround. but hey it works.Turris OS 5.0Jan PavlinecJan Pavlinechttps://gitlab.nic.cz/turris/os/build/-/issues/149Multiple SSID does not work on SDIO Wi-Fi card2023-08-16T11:01:26+02:00Josef SchlehoferMultiple SSID does not work on SDIO Wi-Fi cardChip Marvell 88W8997 used on Wi-Fi card has some issues with Multiple SSID, which prevents using mostly Guest network.
There is a forum thread about that: https://forum.turris.cz/t/enterprise-wi-fi-does-not-work-with-mox-sdio-wi-fi/1049...Chip Marvell 88W8997 used on Wi-Fi card has some issues with Multiple SSID, which prevents using mostly Guest network.
There is a forum thread about that: https://forum.turris.cz/t/enterprise-wi-fi-does-not-work-with-mox-sdio-wi-fi/10494/3?u=pepe
However, we prepared workaround for Guest network - https://forum.turris.cz/t/guest-network-sdio-wi-fi-issue-workaround/11899 , but it was tested by just one user and this does not help if it works or not. We need better feedback on it. I think we can try to send that firmware to HBL/HBD branches to see if it is better.Turris OS 5.0.4https://gitlab.nic.cz/turris/os/build/-/issues/152Network configuration reloaded to broken wifi state when wpad is installed2021-02-16T21:49:51+01:00Karel KociNetwork configuration reloaded to broken wifi state when wpad is installedThis happens only once after boot when wpad package is reinstalled. Subsequent updates do not have the same effect.
The problem is that something triggers reload of network once files are moved to location and synced. At the same time t...This happens only once after boot when wpad package is reinstalled. Subsequent updates do not have the same effect.
The problem is that something triggers reload of network once files are moved to location and synced. At the same time this reload fails to configure correctly wifi. We can fix it by just simply reloading network service.
To compare this is end of updater's trace output till the point wifi is disconnected.
```
INFO:transaction.lua:164 (fun):Running pre-install and pre-rm scripts and merging packages to root file system
DEBUG:backend.lua:817 (pkg_merge_control):Removing previous version control file wpad.prerm
DEBUG:backend.lua:817 (pkg_merge_control):Removing previous version control file wpad.control
DEBUG:backend.lua:817 (pkg_merge_control):Removing previous version control file wpad.postinst
DEBUG:backend.lua:817 (pkg_merge_control):Removing previous version control file wpad.list
DEBUG:backend.lua:817 (pkg_merge_control):Removing previous version control file wpad.files-sha256
DEBUG:backend.lua:840 (pkg_merge_control):Putting control file files-sha256 into place
DEBUG:src/lib/interpreter.c:326 (lua_run_generic):Util command: cp -Lpf /usr/share/updater/unpacked//updater-mlalPO/control/files-sha256 /usr/lib/opkg/info//wpad.files-sha256
TRACE:src/lib/events.c:548 (run_command_a):Running command /tmp/updater-busybox-AhipiG/busybox
DEBUG:backend.lua:840 (pkg_merge_control):Putting control file prerm into place
DEBUG:src/lib/interpreter.c:326 (lua_run_generic):Util command: cp -Lpf /usr/share/updater/unpacked//updater-mlalPO/control/prerm /usr/lib/opkg/info//wpad.prerm
TRACE:src/lib/events.c:548 (run_command_a):Running command /tmp/updater-busybox-AhipiG/busybox
DEBUG:backend.lua:840 (pkg_merge_control):Putting control file postinst into place
DEBUG:src/lib/interpreter.c:326 (lua_run_generic):Util command: cp -Lpf /usr/share/updater/unpacked//updater-mlalPO/control/postinst /usr/lib/opkg/info//wpad.postinst
TRACE:src/lib/events.c:548 (run_command_a):Running command /tmp/updater-busybox-AhipiG/busybox
DEBUG:backend.lua:840 (pkg_merge_control):Putting control file control into place
DEBUG:src/lib/interpreter.c:326 (lua_run_generic):Util command: cp -Lpf /usr/share/updater/unpacked//updater-mlalPO/control/control /usr/lib/opkg/info//wpad.control
TRACE:src/lib/events.c:548 (run_command_a):Running command /tmp/updater-busybox-AhipiG/busybox
DEBUG:backend.lua:766 (pkg_merge_files):Creating dir /
DEBUG:backend.lua:766 (pkg_merge_files):Creating dir /usr
DEBUG:backend.lua:766 (pkg_merge_files):Creating dir /usr/sbin
DEBUG:backend.lua:782 (pkg_merge_files):Installing file /usr/sbin/wpa_supplicant
TRACE:src/lib/events.c:548 (run_command_a):Running command /tmp/updater-busybox-AhipiG/busybox
DEBUG:backend.lua:782 (pkg_merge_files):Installing file /usr/sbin/hostapd
TRACE:src/lib/events.c:548 (run_command_a):Running command /tmp/updater-busybox-AhipiG/busybox
DEBUG:backend.lua:782 (pkg_merge_files):Installing file /usr/sbin/wpad
TRACE:src/lib/events.c:548 (run_command_a):Running command /tmp/updater-busybox-AhipiG/busybox
TRACE:src/lib/interpreter.c:791 (lua_sync):Sync
```
This is relevant output from syslog:
```
May 27 07:26:44 mox-home updater[7070]: transaction.lua:164 (fun): Running pre-install and pre-rm scripts and merging packages to root file system
May 27 07:26:44 mox-home netifd: Network device 'wlan0' link is down
May 27 07:26:44 mox-home hostapd: wlan0: INTERFACE-DISABLED
May 27 07:26:44 mox-home kernel: [ 429.647835] br-lan: port 7(wlan0) entered disabled state
May 27 07:26:44 mox-home kernel: [ 429.697850] device wlan0 left promiscuous mode
May 27 07:26:44 mox-home kernel: [ 429.702243] br-lan: port 7(wlan0) entered disabled state
May 27 07:26:45 mox-home kernel: [ 429.994043] mwifiex_sdio mmc0:0001:1: EVENT: BT coex wlan param update
May 27 07:26:45 mox-home kernel: [ 430.004065] br-lan: port 6(wlan1) entered disabled state
May 27 07:26:45 mox-home netifd: Network device 'wlan1' link is down
May 27 07:26:45 mox-home hostapd: Failed to set beacon parameters
May 27 07:26:45 mox-home hostapd: wlan1: AP-STA-DISCONNECTED 88:ad:d2:26:0a:e8
May 27 07:26:45 mox-home hostapd: wlan1: INTERFACE-DISABLED
May 27 07:26:45 mox-home netifd: Network device 'wlang5' link is down
May 27 07:26:45 mox-home kernel: [ 430.142965] br-guest: port 2(wlang5) entered disabled state
May 27 07:26:45 mox-home kernel: [ 430.154374] device wlan1 left promiscuous mode
May 27 07:26:45 mox-home kernel: [ 430.158989] br-lan: port 6(wlan1) entered disabled state
May 27 07:26:45 mox-home hostapd: Failed to set beacon parameters
May 27 07:26:45 mox-home kernel: [ 430.317906] device wlang5 left promiscuous mode
May 27 07:26:45 mox-home kernel: [ 430.322664] br-guest: port 2(wlang5) entered disabled state
May 27 07:26:45 mox-home updater[7070]: transaction.lua:235 (fun): Removing packages and leftover files
May 27 07:26:45 mox-home updater[7070]: transaction.lua:240 (fun): Running post-install and post-rm scripts
May 27 07:26:45 mox-home updater[7070]: src/lib/logging.c:204 (log_subproc_open): Running postinst of wpad
May 27 07:26:45 mox-home netifd: Network device 'wlang2' link is down
May 27 07:26:45 mox-home kernel: [ 430.382172] br-guest: port 3(wlang2) entered disabled state
May 27 07:26:45 mox-home kernel: [ 430.419513] device wlang2 left promiscuous mode
May 27 07:26:45 mox-home kernel: [ 430.424012] br-guest: port 3(wlang2) entered disabled state
May 27 07:26:46 mox-home kernel: [ 431.016736] mwifiex_sdio mmc0:0001:1: CMD_RESP: cmd 0x20 error, result=0x1
May 27 07:26:46 mox-home mac80211: Failed command: iw phy phy1 set antenna 0xffffffff 0xffffffff
May 27 07:26:46 mox-home netifd: radio1 (7286): command failed: Not supported (-95)
May 27 07:26:46 mox-home mac80211: Failed command: iw phy phy1 set antenna_gain 0
May 27 07:26:46 mox-home hostapd: Configuration file: /var/run/hostapd-phy0.conf
May 27 07:26:46 mox-home updater[7070]: transaction.lua:254 (fun): Cleaning up control files
May 27 07:26:47 mox-home updater[7070]: src/lib/logging.c:204 (log_subproc_open): Executing postupdate hook: 20_update_alternatives.sh
May 27 07:26:47 mox-home kernel: [ 432.339540] ath10k_pci 0000:00:00.0: 10.1 wmi init: vdevs: 16 peers: 127 tid: 256
May 27 07:26:47 mox-home updater[7070]: src/lib/logging.c:204 (log_subproc_open): Executing postupdate hook: 95_schnapps.sh
May 27 07:26:47 mox-home kernel: [ 432.356834] ath10k_pci 0000:00:00.0: wmi print 'P 128 V 8 T 410'
May 27 07:26:47 mox-home kernel: [ 432.363132] ath10k_pci 0000:00:00.0: wmi print 'msdu-desc: 1424 sw-crypt: 0 ct-sta: 0'
May 27 07:26:47 mox-home kernel: [ 432.371808] ath10k_pci 0000:00:00.0: wmi print 'alloc rem: 20904 iram: 26056'
May 27 07:26:47 mox-home kernel: [ 432.438558] ath10k_pci 0000:00:00.0: pdev param 0 not supported by firmware
May 27 07:26:47 mox-home hostapd: Failed to set beacon parameters
May 27 07:26:47 mox-home kernel: [ 432.453576] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
May 27 07:26:47 mox-home hostapd: wlan0: INTERFACE-ENABLED
May 27 07:26:47 mox-home hostapd: Failed to set beacon parameters
May 27 07:26:47 mox-home hostapd: wlan0: INTERFACE-DISABLED
May 27 07:26:47 mox-home hostapd: nl80211: Could not configure driver mode
May 27 07:26:47 mox-home hostapd: nl80211: deinit ifname=wlan0 disabled_11b_rates=0
May 27 07:26:47 mox-home hostapd: nl80211 driver initialization failed.
May 27 07:26:47 mox-home hostapd: wlan0: interface state UNINITIALIZED->DISABLED
May 27 07:26:47 mox-home hostapd: wlang5: AP-DISABLED
May 27 07:26:47 mox-home hostapd: wlang5: CTRL-EVENT-TERMINATING
May 27 07:26:47 mox-home hostapd: hostapd_free_hapd_data: Interface wlang5 wasn't started
May 27 07:26:47 mox-home hostapd: wlan0: AP-DISABLED
May 27 07:26:47 mox-home hostapd: wlan0: CTRL-EVENT-TERMINATING
May 27 07:26:47 mox-home hostapd: hostapd_free_hapd_data: Interface wlan0 wasn't started
May 27 07:26:47 mox-home kernel: [ 432.629264] IPv6: ADDRCONF(NETDEV_UP): wlan1: link is not ready
May 27 07:26:47 mox-home hostapd: wlan1: INTERFACE-ENABLED
May 27 07:26:47 mox-home netifd: radio0 (7260): WARNING (wireless_add_process): executable path /usr/sbin/wpad does not match process 4048 path (/proc/4048/exe)
May 27 07:26:47 mox-home netifd: radio0 (7260): Device setup failed: HOSTAPD_START_FAILED
May 27 07:26:47 mox-home hostapd: Configuration file: /var/run/hostapd-phy1.conf
May 27 07:26:48 mox-home updater[7070]: src/lib/logging.c:204 (log_subproc_open): Executing postupdate hook: 99_approvals_cleanup
May 27 07:26:49 mox-home hostapd: Failed to set beacon parameters
May 27 07:26:49 mox-home kernel: [ 434.140903] IPv6: ADDRCONF(NETDEV_CHANGE): wlan1: link becomes ready
May 27 07:26:49 mox-home hostapd: wlan1: INTERFACE-DISABLED
May 27 07:26:49 mox-home kernel: [ 434.160286] mwifiex_sdio mmc0:0001:1: EVENT: BT coex wlan param update
May 27 07:26:49 mox-home hostapd: wlan1: INTERFACE-ENABLED
May 27 07:26:49 mox-home kernel: [ 434.182154] IPv6: ADDRCONF(NETDEV_UP): wlan1: link is not ready
May 27 07:26:50 mox-home kernel: [ 435.685405] IPv6: ADDRCONF(NETDEV_CHANGE): wlan1: link becomes ready
May 27 07:26:50 mox-home kernel: [ 435.704431] br-lan: port 6(wlan1) entered blocking state
May 27 07:26:50 mox-home kernel: [ 435.710095] br-lan: port 6(wlan1) entered disabled state
May 27 07:26:50 mox-home kernel: [ 435.717231] device wlan1 entered promiscuous mode
May 27 07:26:50 mox-home kernel: [ 435.722846] br-lan: port 6(wlan1) entered blocking state
May 27 07:26:50 mox-home kernel: [ 435.728518] br-lan: port 6(wlan1) entered forwarding state
May 27 07:26:50 mox-home hostapd: ctrl_iface exists and seems to be in use - cannot override it
May 27 07:26:50 mox-home hostapd: Delete '/var/run/hostapd/wlan1' manually if it is not used anymore
May 27 07:26:50 mox-home hostapd: Failed to setup control interface for wlan1
May 27 07:26:50 mox-home hostapd: wlan1: Unable to setup interface.
May 27 07:26:50 mox-home hostapd: wlan1: interface state UNINITIALIZED->DISABLED
May 27 07:26:50 mox-home hostapd: wlang2: AP-DISABLED
May 27 07:26:50 mox-home hostapd: wlang2: CTRL-EVENT-TERMINATING
May 27 07:26:50 mox-home hostapd: hostapd_free_hapd_data: Interface wlang2 wasn't started
May 27 07:26:50 mox-home hostapd: wlan1: AP-DISABLED
May 27 07:26:50 mox-home hostapd: wlan1: CTRL-EVENT-TERMINATING
May 27 07:26:50 mox-home hostapd: hostapd_free_hapd_data: Interface wlan1 wasn't started
May 27 07:26:50 mox-home hostapd: nl80211: deinit ifname=wlan1 disabled_11b_rates=0
May 27 07:26:50 mox-home kernel: [ 435.767242] device wlan1 left promiscuous mode
May 27 07:26:50 mox-home kernel: [ 435.772114] br-lan: port 6(wlan1) entered disabled state
May 27 07:26:50 mox-home netifd: radio1 (7286): WARNING (wireless_add_process): executable path /usr/sbin/wpad does not match process 4425 path (/proc/4425/exe)
May 27 07:26:50 mox-home netifd: radio1 (7286): Device setup failed: HOSTAPD_START_FAILED
May 27 07:26:51 mox-home hostapd: Failed to set beacon parameters
May 27 07:26:51 mox-home hostapd: Failed to set beacon parameters
May 27 07:26:55 mox-home hostapd: Failed to set beacon parameters
```Turris OS 5.1https://gitlab.nic.cz/turris/os/build/-/issues/154"5.1" hbl Packages list asks for kernel.0 version when none exists2023-08-16T11:01:38+02:00Michael Richardson"5.1" hbl Packages list asks for kernel.0 version when none existsRunning ./generate_medkit -t mox from a checkout at:
commit 24d9b4c25b1a743bf3e6b50c0feb8865196d87b0 (HEAD -> hbl, origin/hbl)
pulls down:
https://repo.turris.cz/hbl/mox/packages/core/Packages
and complains:
ERROR:
inconsi...Running ./generate_medkit -t mox from a checkout at:
commit 24d9b4c25b1a743bf3e6b50c0feb8865196d87b0 (HEAD -> hbl, origin/hbl)
pulls down:
https://repo.turris.cz/hbl/mox/packages/core/Packages
and complains:
ERROR:
inconsistent: Package kmod-cfg80211 requires package kernel that is not available.
which I've seen this before. This is because of the .0 on line 221 of include/kernel.mk:
define Package/kmod-$(1)
TITLE:=$(TITLE)
SECTION:=kernel
CATEGORY:=Kernel modules
DESCRIPTION:=$(DESCRIPTION)
VERSION:=$(LINUX_VERSION)$(if $(PKG_VERSION),+$(PKG_VERSION))-$(if $(PKG_RELEASE),$(PKG_RELEASE),$(LINUX_RELEASE))-$(LINUX_VERMAGIC)
EXTRA_DEPENDS:=kernel (=$(LINUX_VERSION)-$(LINUX_RELEASE)-$(LINUX_VERMAGIC).0)
somewhere the kernel was intended to have a trailing .0 on it, which it does not. This is not in openwrt upstream.
Removing the .0 here fixes the package dependancy problem, but then I have to build all the packages, which as reported and acknowledged, regularly does not complete. (Yes, I finally have a minimal .config, but it may too minimal)
If one examines the above URL for the Packages file in an editor one sees:
Package: kernel
Version: 4.14.180-1-b05c242413ba31ef0a03c70a9c2877a9.11
Depends: libc
...
Package: kmod-cfg80211
Version: 4.14.180+4.19.120-1-1-b05c242413ba31ef0a03c70a9c2877a9.11
Depends: kernel (=4.14.180-1-b05c242413ba31ef0a03c70a9c2877a9.0), iw, wireless-regdbTurris OS 5.1https://gitlab.nic.cz/turris/os/build/-/issues/157zerotier: segmentaion fault2020-06-11T19:14:40+02:00Jan Pavlineczerotier: segmentaion faultReported on a forum and confirmed on HBL https://forum.turris.cz/t/zerotier-segmentation-fault-on-tos-5/13160
Upstream issue https://github.com/openwrt/packages/issues/12482Reported on a forum and confirmed on HBL https://forum.turris.cz/t/zerotier-segmentation-fault-on-tos-5/13160
Upstream issue https://github.com/openwrt/packages/issues/12482Jan PavlinecJan Pavlinechttps://gitlab.nic.cz/turris/os/build/-/issues/158syslog-ng: fails with disabled IPv62020-06-30T14:58:17+02:00Jan Pavlinecsyslog-ng: fails with disabled IPv6reported on forum https://forum.turris.cz/t/syslog-ng-not-running-in-tos-5-0-0/13060/8
```
I guess it was caused by disabled ipv6. syslog-ng has this in config:
source net {
network(ip("::1") port(514) transport(udp) ip-protocol(6));...reported on forum https://forum.turris.cz/t/syslog-ng-not-running-in-tos-5-0-0/13060/8
```
I guess it was caused by disabled ipv6. syslog-ng has this in config:
source net {
network(ip("::1") port(514) transport(udp) ip-protocol(6));
}
which fails if ipv6 isn’t available
… after enabling ipv6 on wan interface, syslogn-ng runs.
```
Turris OS 5.0.3https://gitlab.nic.cz/turris/os/build/-/issues/165[Omnia] kernel's bridge FDB not reconciling switch's ATU2023-08-16T10:58:09+02:00Ghost User[Omnia] kernel's bridge FDB not reconciling switch's ATUIssue observed by users and reported in forums:
- https://forum.turris.cz/t/to-lan-switch-or-bridge-blocks-dhcp-replies-intermittently/13242
- https://forum.turris.cz/t/lan-ports-arent-accessible-for-wifi-client-for-the-first-250-330-se...Issue observed by users and reported in forums:
- https://forum.turris.cz/t/to-lan-switch-or-bridge-blocks-dhcp-replies-intermittently/13242
- https://forum.turris.cz/t/lan-ports-arent-accessible-for-wifi-client-for-the-first-250-330-seconds-after-connection/12071
- https://forum.turris.cz/t/omnia-vlan-on-dsa-port-breaks-arp-responses-tos-4-0-5/12584
- https://forum.openwrt.org/t/access-point-configuration-problem/52938
---
With the Wlan cards and the switch utilising different buses there is no direct information exchange but only via CPU/kernel. That results in the switch's ATU being unaware of client MAC addresses connected to Wlan since the bridge/DSA driver does not reconcile its bridge FDB entries with the switch's ATU.
For that the node's clients roaming from one of its Lan ports to a Wlan port are not able to receive traffic from the Lan ports until the switch's ATU ageing register (default ~ 300 seconds) clears the roamed client's MAC, as it remains unaware that the client has moved to another port (Wlan) and therefore drops traffic for that client's MAC.
The issue started to manifest only with the introduction of DSA and subsequent removal of OpenWrt's *swconfig* which if enabled routed all Lan traffic through the CPU(s).
Whilst this may seem like an inherent design flaw of the kernel's DSA/bridge driver it may not be accepted upstream as such.Turris OS 6.0https://gitlab.nic.cz/turris/os/build/-/issues/172RJ45 SFP module does not work in TOS 4.02020-07-09T16:11:30+02:00Vojtech MyslivecRJ45 SFP module does not work in TOS 4.0Follow-up from turris/rtools-gui#55
1 Gbps RJ45 SFP module S-RJ01 from MikroTik does not work well for Omnia after TOS 4.0 upgrade.
It spam serial console/syslog with `no PHY detected messages`.Follow-up from turris/rtools-gui#55
1 Gbps RJ45 SFP module S-RJ01 from MikroTik does not work well for Omnia after TOS 4.0 upgrade.
It spam serial console/syslog with `no PHY detected messages`.Turris OS 6.0Marek BehunMarek Behunhttps://gitlab.nic.cz/turris/os/build/-/issues/173OpenVPN in endless loop (re)start2023-08-16T10:58:49+02:00Martin KebertOpenVPN in endless loop (re)startHi,
not sure whther it is fresh or not, but after TOS 5.0.3 update I noticed that load is quite high and in *logread -f* endlessly flows this:
<details>
<summary>Log exerpt</summary>
```
Jul 10 07:56:34 omnia openvpn(server_turris)[1102...Hi,
not sure whther it is fresh or not, but after TOS 5.0.3 update I noticed that load is quite high and in *logread -f* endlessly flows this:
<details>
<summary>Log exerpt</summary>
```
Jul 10 07:56:34 omnia openvpn(server_turris)[11022]: OpenVPN 2.4.7 arm-openwrt-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD]
Jul 10 07:56:34 omnia openvpn(server_turris)[11022]: library versions: OpenSSL 1.1.1g 21 Apr 2020, LZO 2.10
Jul 10 07:56:34 omnia openvpn(server_turris)[11022]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Jul 10 07:56:34 omnia openvpn(server_turris)[11022]: Diffie-Hellman initialized with 2048 bit key
Jul 10 07:56:34 omnia openvpn(server_turris)[11022]: TUN/TAP device tun_turris opened
Jul 10 07:56:34 omnia netifd: Interface 'vpn_turris' is enabled
Jul 10 07:56:34 omnia netifd: Network device 'tun_turris' link is up
Jul 10 07:56:34 omnia netifd: Interface 'vpn_turris' has link connectivity
Jul 10 07:56:34 omnia netifd: Interface 'vpn_turris' is setting up now
Jul 10 07:56:34 omnia openvpn(server_turris)[11022]: TUN/TAP TX queue length set to 100
Jul 10 07:56:34 omnia netifd: Interface 'vpn_turris' is now up
Jul 10 07:56:34 omnia openvpn(server_turris)[11022]: /sbin/ifconfig tun_turris 192.168.123.1 pointopoint 192.168.123.2 mtu 1500
Jul 10 07:56:34 omnia openvpn(server_turris)[11022]: /sbin/ifconfig tun_turris add 2001:db8:d01::1/64
Jul 10 07:56:34 omnia openvpn(server_turris)[11022]: /sbin/route add -net 192.168.123.0 netmask 255.255.255.0 gw 192.168.123.2
Jul 10 07:56:34 omnia openvpn(server_turris)[11022]: Could not determine IPv4/IPv6 protocol. Using AF_INET
Jul 10 07:56:34 omnia openvpn(server_turris)[11022]: Socket Buffers: R=[163840->163840] S=[163840->163840]
Jul 10 07:56:34 omnia openvpn(server_turris)[11022]: UDPv4 link local (bound): [AF_INET][undef]:1194
Jul 10 07:56:34 omnia openvpn(server_turris)[11022]: UDPv4 link remote: [AF_UNSPEC]
Jul 10 07:56:34 omnia openvpn(server_turris)[11022]: MULTI: multi_init called, r=256 v=256
Jul 10 07:56:34 omnia openvpn(server_turris)[11022]: IFCONFIG POOL IPv6: (IPv4) size=62, size_ipv6=65536, netbits=64, base_ipv6=2001:db8:d01::1000
Jul 10 07:56:34 omnia openvpn(server_turris)[11022]: IFCONFIG POOL: base=192.168.123.4 size=62, ipv6=1
Jul 10 07:56:34 omnia openvpn(server_turris)[11022]: IFCONFIG POOL LIST
Jul 10 07:56:34 omnia openvpn(server_turris)[11022]: Initialization Sequence Completed
Jul 10 07:56:36 omnia firewall: Reloading firewall due to ifup of vpn_turris (tun_turris)
Jul 10 07:56:37 omnia openvpn(server_turris)[11022]: event_wait : Interrupted system call (code=4)
Jul 10 07:56:37 omnia openvpn(server_turris)[11022]: /sbin/route del -net 192.168.123.0 netmask 255.255.255.0
Jul 10 07:56:37 omnia openvpn(server_turris)[11022]: Closing TUN/TAP interface
Jul 10 07:56:37 omnia openvpn(server_turris)[11022]: /sbin/ifconfig tun_turris 0.0.0.0
Jul 10 07:56:37 omnia openvpn(server_turris)[11022]: /sbin/ifconfig tun_turris del 2001:db8:d01::1/64
Jul 10 07:56:37 omnia netifd: Network device 'tun_turris' link is down
Jul 10 07:56:37 omnia netifd: Interface 'vpn_turris' has link connectivity loss
Jul 10 07:56:37 omnia netifd: Interface 'vpn_turris' is now down
Jul 10 07:56:37 omnia openvpn(server_turris)[11022]: SIGTERM[hard,] received, process exiting
Jul 10 07:56:37 omnia netifd: Interface 'vpn_turris' is disabled
```
</details>
<details>
<summary>Perhaps not much useful ps w | grep vpn</summary>
```
root@omnia:~# ps w | grep vpn
4374 root 3756 S /usr/sbin/openvpn --syslog openvpn(server_turris) --status /var/run/openvpn.server_turris.status --cd /va
4813 root 1192 S grep vpn
root@omnia:~# ps w | grep vpn
4929 root 3756 S /usr/sbin/openvpn --syslog openvpn(server_turris) --status /var/run/openvpn.server_turris.status --cd /va
5023 root 1240 S /bin/sh /usr/bin/foris-notify-wrapper -n -m networks -a network_change {"network":"vpn_turris","device":"
root@omnia:~# ps w | grep vpn
4929 root 3756 S /usr/sbin/openvpn --syslog openvpn(server_turris) --status /var/run/openvpn.server_turris.status --cd /va
5023 root 1240 S /bin/sh /usr/bin/foris-notify-wrapper -n -m networks -a network_change {"network":"vpn_turris","device":"
root@omnia:~# ps w | grep vpn
4929 root 3756 S /usr/sbin/openvpn --syslog openvpn(server_turris) --status /var/run/openvpn.server_turris.status --cd /va
5440 root 1192 S grep vpn
root@omnia:~# ps w | grep vpn
5495 root 3756 S /usr/sbin/openvpn --syslog openvpn(server_turris) --status /var/run/openvpn.server_turris.status --cd /va
5588 root 1240 S /bin/sh /usr/bin/foris-notify-wrapper -n -m networks -a network_change {"network":"vpn_turris","device":"
root@omnia:~# ps w | grep vpn
5495 root 3756 S /usr/sbin/openvpn --syslog openvpn(server_turris) --status /var/run/openvpn.server_turris.status --cd /va
5588 root 1240 S /bin/sh /usr/bin/foris-notify-wrapper -n -m networks -a network_change {"network":"vpn_turris","device":"
5824 root 1192 S grep vpn
root@omnia:~# ps w | grep vpn
5992 root 1208 S ash /etc/hotplug.d/iface/42-openvpn
5998 root 1344 R /bin/sh /etc/rc.common /etc/init.d/openvpn restart
6032 root 1192 S grep vpn
root@omnia:~# ps w | grep vpn
6039 root 3756 S /usr/sbin/openvpn --syslog openvpn(server_turris) --status /var/run/openvpn.server_turris.status --cd /va
6117 root 1240 S /bin/sh /usr/bin/foris-notify-wrapper -n -m networks -a network_change {"network":"vpn_turris","device":"
6364 root 1192 S grep vpn
root@omnia:~# ps w | grep vpn
6581 root 3756 S /usr/sbin/openvpn --syslog openvpn(server_turris) --status /var/run/openvpn.server_turris.status --cd /va
6658 root 1240 S /bin/sh /usr/bin/foris-notify-wrapper -n -m networks -a network_change {"network":"vpn_turris","device":"
6666 root 1192 S grep vpn
root@omnia:~# ps w | grep vpn
6581 root 3756 S /usr/sbin/openvpn --syslog openvpn(server_turris) --status /var/run/openvpn.server_turris.status --cd /va
6658 root 1240 S /bin/sh /usr/bin/foris-notify-wrapper -n -m networks -a network_change {"network":"vpn_turris","device":"
6881 root 1192 S grep vpn
root@omnia:~#
```
</details>https://gitlab.nic.cz/turris/os/build/-/issues/176luci fails with JSON cyclic structure error after initial wizard setup2023-08-16T10:58:54+02:00Michael Richardsonluci fails with JSON cyclic structure error after initial wizard setup# Summary
This is probably the wrong repo to report this, but gitlab.nic.cz doesn't have a luci repo, and this is certainly something wrong in some interaction between reForis and luci.
When I go into: https://n6416fd.r.dasblinkenled.o...# Summary
This is probably the wrong repo to report this, but gitlab.nic.cz doesn't have a luci repo, and this is certainly something wrong in some interaction between reForis and luci.
When I go into: https://n6416fd.r.dasblinkenled.org/cgi-bin/luci/admin/network/network
and select "Edit" on any of the network interfaces, I get an error:
TypeError
JSON.stringify cannot serialize cyclic structures.
This only thing that has been doing anything to the configuration is reForis (Turris 5.1.0).
I therefore suspect something inside uci has gotten confused.
This is a JS error
# Steps To Reproduce
1. flash MEDKIT
2. go through configuration wizard, setup LAN/WAN, setup Wifi and guest_wifi
3. go into Luci (was wondering why guest_wifi did not get IPv6 ULA)
# Expected Result
Luci should open Interface editor
# Actual Result
JSON.stringify cannon serialize cyclic structures.
I will see what other builds exhibit this problem.https://gitlab.nic.cz/turris/os/build/-/issues/179Turris 1.x migration is broken because of broken updater from Turris OS 5.12023-08-16T11:00:54+02:00Karel KociTurris 1.x migration is broken because of broken updater from Turris OS 5.1Migration on Turris 1.x fails once new updater is running. Version from Turris OS 5.1.0 terminates with following error:
```
2020-09-01 16:57:50 info updater[7673]: src/lib/logging.c:206 (log_subproc_open): Running postinst of liblua
202...Migration on Turris 1.x fails once new updater is running. Version from Turris OS 5.1.0 terminates with following error:
```
2020-09-01 16:57:50 info updater[7673]: src/lib/logging.c:206 (log_subproc_open): Running postinst of liblua
2020-09-01 16:57:50 info updater[7673]: src/lib/logging.c:206 (log_subproc_open): Running postinst of libubox
2020-09-01 16:57:50 info updater[7673]: src/lib/logging.c:206 (log_subproc_open): Running postinst of libuci
2020-09-01 16:57:50 info updater[7673]: src/lib/logging.c:206 (log_subproc_open): Running postinst of libuci-lua
2020-09-01 16:57:50 info updater[7673]: src/lib/logging.c:206 (log_subproc_open): Running postinst of updater-ng
2020-09-01 16:57:50 info updater[7673]: transaction.lua:239 (fun): Removing packages and leftover files
2020-09-01 16:57:51 info sshd[8029]: syslogin_perform_logout: logout() returned an error
2020-09-01 16:57:55 info updater[7673]: transaction.lua:252 (fun): Cleaning up control files
2020-09-01 16:57:56 info kernel[]: [ 152.998627] pkgupdate[7673]: unhandled signal 4 at b7ec2060 nip b7ec2060 lr b7eb16b0 code 30001
2020-09-01 16:57:56 info updater-supervisor[]: pkgupdate exited with: -4
```
Clearly it is problem that packages in Turris OS 5.1.0 on Turris 1.x are build differently over those in Turris OS 3.x. It has to be investigated why actually updater uses illegal instruction and if that is some CPU mode or if that is just issue that is present in Turris OS 5.1.0 as well.Turris OS 3.11.20https://gitlab.nic.cz/turris/os/build/-/issues/241Kernel is reinstalled after opkg usage2022-03-02T10:22:14+01:00Josef SchlehoferKernel is reinstalled after opkg usageWhile doing new update on router, it seems that there is repeated installation of the same kernel packages, which are already installed.
Reported on our forum: https://forum.turris.cz/t/repeated-install-of-packages/14170
* [x] turris/u...While doing new update on router, it seems that there is repeated installation of the same kernel packages, which are already installed.
Reported on our forum: https://forum.turris.cz/t/repeated-install-of-packages/14170
* [x] turris/updater/updater#311Turris OS 6.0https://gitlab.nic.cz/turris/os/build/-/issues/182Alternatives seems to not be updated correctly after migration2020-10-08T23:29:59+02:00Karel KociAlternatives seems to not be updated correctly after migrationThis is probably tied to how we fix broken links of busybox in Turris OS 5.0.This is probably tied to how we fix broken links of busybox in Turris OS 5.0.https://gitlab.nic.cz/turris/os/build/-/issues/187Unable to interact with hardware clock on Turris Omnia2023-08-16T10:58:45+02:00Cedric GirardUnable to interact with hardware clock on Turris OmniaI am running TurrisOS 5.1.1. I noticed my hardware clock is several days out of date, causing a lot of operations to fail at boot until system time is updated by NTP. The issue is I cannot update the hardware clock and the value I can re...I am running TurrisOS 5.1.1. I noticed my hardware clock is several days out of date, causing a lot of operations to fail at boot until system time is updated by NTP. The issue is I cannot update the hardware clock and the value I can read with busybox hwclock is always the same.
```
root@turris:~# date
Fri Sep 25 16:25:07 CEST 2020
root@turris:~# hwclock -r
Fri Sep 18 14:48:26 2020 0.000000 seconds
root@turris:~# hwclock -w
root@turris:~# hwclock -r
Fri Sep 18 14:48:26 2020 0.000000 seconds
root@turris:~# date
Fri Sep 25 16:25:24 CEST 2020
```
A strace of the `-w` operation of hwclock from busybox does not display anything wrong:
```
open("/dev/rtc0", O_WRONLY|O_LARGEFILE) = 3
clock_gettime(CLOCK_REALTIME, {tv_sec=1601045609, tv_nsec=617766075}) = 0
open("/etc/TZ", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_CLOEXEC) = -1 ENOENT (No such file or directory)
ioctl(3, RTC_SET_TIME, {tm_sec=29, tm_min=53, tm_hour=16, tm_mday=25, tm_mon=8, tm_year=120, ...}) = 0
exit_group(0) = ?
+++ exited with 0 +++
```
With util-linux hwclock, I can't even access `/dev/rtc0`:
```
root@turris:~# /usr/sbin/hwclock -r -v
hwclock from util-linux 2.34
System Time: 1601045759.232281
Trying to open: /dev/rtc0
Using the rtc interface to the clock.
Assuming hardware clock is kept in UTC time.
Waiting for clock tick...
hwclock: select() to /dev/rtc0 to wait for clock tick timed out
...synchronization failed
```https://gitlab.nic.cz/turris/os/build/-/issues/189Root password in medkit is not locked, it should be2023-08-16T11:01:17+02:00Karel KociRoot password in medkit is not locked, it should beFor some reason root password is not locked but it should be to force user to configure it trough Foris.
We should either add package that locks it on first boot or add patch to make it in default locked.For some reason root password is not locked but it should be to force user to configure it trough Foris.
We should either add package that locks it on first boot or add patch to make it in default locked.Turris OS 5.1.3https://gitlab.nic.cz/turris/os/build/-/issues/205Mismatch of Turris OS version due not updated base-files2022-08-12T23:54:36+02:00Josef SchlehoferMismatch of Turris OS version due not updated base-filesIt happens that `/etc/turris-version` provides version from `NEWS` and it is provided by package `turris-version`. Thing is that base-files provides many files, but among them, these two are important `/etc/openwrt_release`- and `/etc/os...It happens that `/etc/turris-version` provides version from `NEWS` and it is provided by package `turris-version`. Thing is that base-files provides many files, but among them, these two are important `/etc/openwrt_release`- and `/etc/os-release`
Right now, base-files is versioned by PKG_RELEASE in Makefile, but also with hash (revision) from openwrt-19.07 branch in OpenWrt. Source: https://github.com/openwrt/openwrt/blob/openwrt-19.07/package/base-files/Makefile#L43
# Let's take a look:
```
opkg list-installed | grep base-files
base-files - 204.2-78c4c04
```
Hash corresponds to this commit:
https://github.com/openwrt/openwrt/commit/78c4c04dd7979a7f6d3cadeb1783b6c38d63b575
We should find a way how to have correct versions of Turris OS in base-files if there are no changes done in OpenWrt branch.
# Current behaviour:
```
root@turris:~# cat /etc/openwrt_release
DISTRIB_ID='TurrisOS'
DISTRIB_RELEASE='5.1.3'
DISTRIB_REVISION='78c4c04'
DISTRIB_TARGET='mvebu/cortexa9'
DISTRIB_ARCH='arm_cortex-a9_vfpv3-d16'
DISTRIB_DESCRIPTION='TurrisOS 5.1.3 78c4c04dd7979a7f6d3cadeb1783b6c38d63b575'
DISTRIB_TAINTS='busybox'
root@turris:~# cat /etc/turris-version
5.1.4
```
We haven't noticed until now as we released Turris OS 5.1.4 into RC fast since we released Turris OS 5.1.3.Turris OS 5.3.4https://gitlab.nic.cz/turris/os/build/-/issues/207Turris 1.x routers ends up in reboot loop2023-08-16T11:00:47+02:00Josef SchlehoferTurris 1.x routers ends up in reboot loopDescription:
- Turris 1.x routers using the latest builds in HBL ends up in reboot loop.
With log:
```
[ 21.207862] BUG: Kernel NULL pointer dereference at 0x0000009c
[ 21.213700] Faulting instruction address: 0xc0606570
[ 21.2186...Description:
- Turris 1.x routers using the latest builds in HBL ends up in reboot loop.
With log:
```
[ 21.207862] BUG: Kernel NULL pointer dereference at 0x0000009c
[ 21.213700] Faulting instruction address: 0xc0606570
[ 21.218664] Oops: Kernel access of bad area, sig: 11 [#1]
```
Logs:
- https://gitlab.nic.cz/-/snippets/1364
- https://gitlab.nic.cz/-/snippets/1365Turris OS 5.1.5https://gitlab.nic.cz/turris/os/build/-/issues/208hwclock on Turris 1.x routers can not find RTC2023-08-16T10:56:07+02:00Josef Schlehoferhwclock on Turris 1.x routers can not find RTCbusybox:
```
root@turris:~# hwclock
hwclock: can't open '/dev/misc/rtc': No such file or directory
```
util-linux:
```
root@turris:~# /usr/sbin/hwclock -r -v
hwclock from util-linux 2.34
System Time: 1606814388.436183
Trying to open...busybox:
```
root@turris:~# hwclock
hwclock: can't open '/dev/misc/rtc': No such file or directory
```
util-linux:
```
root@turris:~# /usr/sbin/hwclock -r -v
hwclock from util-linux 2.34
System Time: 1606814388.436183
Trying to open: /dev/rtc0
Trying to open: /dev/rtc
Trying to open: /dev/misc/rtc
No usable clock interface found.
hwclock: Cannot access the Hardware Clock via any known method.
```
Reported on support #1173168 and reproduced on Turris 1.1, HBL.Turris OS 5.3.4https://gitlab.nic.cz/turris/os/build/-/issues/209/etc/dhparam/dh-default.pem symlink doesn't exist in medkit for shield2020-12-02T17:32:09+01:00Martin Matějek/etc/dhparam/dh-default.pem symlink doesn't exist in medkit for shieldThere is no symlink to default dh params in medkit for turris shield (HBS, 5.1.4).
`/etc/dhparam/dh-default.pem -> /etc/dhparam/dh2048.pem`
Therefore you can't start openvpn server without manual intervention on device.
My guess is th...There is no symlink to default dh params in medkit for turris shield (HBS, 5.1.4).
`/etc/dhparam/dh-default.pem -> /etc/dhparam/dh2048.pem`
Therefore you can't start openvpn server without manual intervention on device.
My guess is that symlink is only created during install of package.
Not sure if we will hotfix it or just wait for release of 5.2.0.Turris OS 5.1.5Jan PavlinecJan Pavlinechttps://gitlab.nic.cz/turris/os/build/-/issues/210Reporting statistics from compile_pkgs2023-08-16T10:58:31+02:00Josef SchlehoferReporting statistics from compile_pkgsWhile using: `./compile_pkgs stats`
I received this output:
```
Reporting statistics
Statistics of the build:
* 251 binary packages built
* 0find: ‘logs/package/’: No such file or directory
/0 source packages failed
```
While I do: ...While using: `./compile_pkgs stats`
I received this output:
```
Reporting statistics
Statistics of the build:
* 251 binary packages built
* 0find: ‘logs/package/’: No such file or directory
/0 source packages failed
```
While I do: cat build/logs/stats
It shows:
```
Statistics of the build:
* 251 binary packages built
* 0/0 source packages failed
```Turris OS 5.1.9https://gitlab.nic.cz/turris/os/build/-/issues/215LuCI: LXC containers are not listed after installation2021-04-09T11:19:44+02:00Karel KociLuCI: LXC containers are not listed after installationThe issue is that there are no containers listed in LuCI if there are any already or if they are created after that till the reboot is performed.
This happens only if you install LXC not when you remove and install it back on running ro...The issue is that there are no containers listed in LuCI if there are any already or if they are created after that till the reboot is performed.
This happens only if you install LXC not when you remove and install it back on running router. Boot of device has to be without LXC installed.
The cause is missing LXC in ubus. Any direct operation such as creation of container are successful but anything modifying existing containers uses ubus. LXC ubus support is provided by package `rpcd-mod-lxc`. This package clearly is not forcing rpcd reload.Turris OS 5.2.0https://gitlab.nic.cz/turris/os/build/-/issues/217Update erased custom uboot settings2021-01-04T09:04:07+01:00Jan PavlinecUpdate erased custom uboot settingsThis issue is probably related only to HBL.
After pkgupdate u-boot setting is erased. In case that user is booting from ssd/usb this can cause switch to emmc boot
pkgupdate output https://gist.github.com/BKPepe/e94be219949b4b4b5a506fe1...This issue is probably related only to HBL.
After pkgupdate u-boot setting is erased. In case that user is booting from ssd/usb this can cause switch to emmc boot
pkgupdate output https://gist.github.com/BKPepe/e94be219949b4b4b5a506fe1ff2a52b3
Maybe related to https://gitlab.nic.cz/turris/turris-build/-/merge_requests/186Turris OS 5.1.5https://gitlab.nic.cz/turris/os/build/-/issues/218Turris 1.x routers is restarted irregularly itself2023-08-16T10:58:39+02:00Josef SchlehoferTurris 1.x routers is restarted irregularly itselfIt was reported on our forum that in some cases reboots of Turris 1.x routers happens.
From what we have it seems to be related to this:
```
[12415.905252] PowerPC Book-E Watchdog Exception
[12415.905254] PowerPC Book-E Watchdog Excepti...It was reported on our forum that in some cases reboots of Turris 1.x routers happens.
From what we have it seems to be related to this:
```
[12415.905252] PowerPC Book-E Watchdog Exception
[12415.905254] PowerPC Book-E Watchdog Exception
```
More details are included in this thread: https://forum.turris.cz/t/turris-os-4-5-pro-turris-1-x/11555/61Turris OS 5.1.5https://gitlab.nic.cz/turris/os/build/-/issues/262Some services are not enabled by default2023-08-16T10:58:06+02:00Josef SchlehoferSome services are not enabled by defaultTurris Omnia, HBD:
- It affects services like `syslog-ng`, `kresd`, `wpad`, `cron` and so on.
I was switching from HBLTurris Omnia, HBD:
- It affects services like `syslog-ng`, `kresd`, `wpad`, `cron` and so on.
I was switching from HBLTurris OS 6.0Jan PavlinecJan Pavlinechttps://gitlab.nic.cz/turris/os/build/-/issues/229/etc/fw_env.config deleted after migration from 3.11.26 to TOS 5.1.42023-08-16T10:57:59+02:00Marc Elser/etc/fw_env.config deleted after migration from 3.11.26 to TOS 5.1.4If you use foris experimental update from 3.11.26 to TOS 5.1.4 the file /etc/fw_env.config get's deleted so you can no longer use fw_setenv to switch from ssd to emmc and vice versa.
I don't know if it is possible to deploy a proper /et...If you use foris experimental update from 3.11.26 to TOS 5.1.4 the file /etc/fw_env.config get's deleted so you can no longer use fw_setenv to switch from ssd to emmc and vice versa.
I don't know if it is possible to deploy a proper /etc/fw_env.config for the different Hardware out there but I think at least if should not be deleted. It can be cumbersome to search the forums for a proper one if you for example want to be able to switch from 3.11.26 (msata) to 5.1.4 (emmc) and vice versa.https://gitlab.nic.cz/turris/os/build/-/issues/232Medkit: target model has to be provided2021-06-01T22:12:38+02:00Josef SchlehoferMedkit: target model has to be providedI was fiddling around medkits for a while as somebody on IRC complained about documentation and build process. Documentation will be handled in turris/os/build!326.
I wanted to add a stage in Gitlab CI to know, but I am not able to gene...I was fiddling around medkits for a while as somebody on IRC complained about documentation and build process. Documentation will be handled in turris/os/build!326.
I wanted to add a stage in Gitlab CI to know, but I am not able to generate medkit in branch HBL.
HBL pipeline: https://gitlab.nic.cz/turris/turris-build/-/jobs/482658
Output: `DIE:Target model has to be provided by BOARD environment variable.`
I tried to generate medkits with this command: `./generate_medkits -t omnia` and I tried to use even script, which is located in `helpers` folder and still no go for HBL branch. I can reproduce this even locally.
When I took a script from HBK and move it to HBL, it seems like it was doing something: https://gitlab.nic.cz/turris/turris-build/-/jobs/482694 but it didn't say it was successful or not. I can build HBK medkits just fine even locally.Turris OS 5.2.0https://gitlab.nic.cz/turris/os/build/-/issues/233Using Medkit with checksum file does not work2021-06-01T22:21:56+02:00Josef SchlehoferUsing Medkit with checksum file does not work> I downloaded the latest medkit (SB I think) and the sha256 checksum file and put them onto a USB to flash to the router. It went through the process but didn't reboot, it would just hang with flashing blue lights. I opened the checksum...> I downloaded the latest medkit (SB I think) and the sha256 checksum file and put them onto a USB to flash to the router. It went through the process but didn't reboot, it would just hang with flashing blue lights. I opened the checksum file and manually hashed the firmware, it matched successfully but the filename next to the hash didn't match the firmware filename which I concluded was the issue...
> So I deleted the checksum file from the USB (having satisfied myself by doing it manually) and the upgrade process completed successfully afterwards.
From https://www.reddit.com/r/Turris/comments/kxvusb/please_help_a_newcomer_omnia_silver/gjn4pip/Turris OS 5.2.0https://gitlab.nic.cz/turris/os/build/-/issues/240dnsmasq spams system logs after introducing fixes for dnspooq (OpenWrt 19.07.6)2021-01-27T22:06:02+01:00Josef Schlehoferdnsmasq spams system logs after introducing fixes for dnspooq (OpenWrt 19.07.6)In some cases, dnsmasq were spamming system log with these errors:
- failed to send packet: Address family not supported by protocol
- failed to send packet: Network unreachable
- failed to send packet: Operation not permitted
This was...In some cases, dnsmasq were spamming system log with these errors:
- failed to send packet: Address family not supported by protocol
- failed to send packet: Network unreachable
- failed to send packet: Operation not permitted
This was introduced in Turris OS 5.1.7, which was based on OpenWrt 19.07.6 due to DNSpooq:
- https://github.com/openwrt/openwrt/commit/8055e38794741313f8f4e6059f83c71dc0ab1d1c
References:
- https://forum.openwrt.org/t/security-advisory-2021-01-19-1-dnsmasq-multiple-vulnerabilities/85903/44
- https://forum.turris.cz/t/security-advisory-2021-01-19-1-dnsmasq-multiple-vulnerabilities/14666/5?u=pepeTurris OS 5.1.8https://gitlab.nic.cz/turris/os/build/-/issues/243Turris Omnia WiFi cards dectection sometimes fails2021-10-06T15:41:09+02:00Karel KociTurris Omnia WiFi cards dectection sometimes fails```
ls: /sys/bus/pci/devices/0000:00:01.0/000*/iee*/phy*: No such file or directory
```
This happens most likely because wifi cards are not yet detected at time of board script execution.
The `/etc/board.d` scripts are executed as one...```
ls: /sys/bus/pci/devices/0000:00:01.0/000*/iee*/phy*: No such file or directory
```
This happens most likely because wifi cards are not yet detected at time of board script execution.
The `/etc/board.d` scripts are executed as one of the last steps in preinit but all kernel modules are loaded right after preinit. The drivers are not built in so the devices are just not available.
The result of this is that led for wifi card is just not configured to blink with appropriate device. In effect it is set to not blink at all.Turris OS 5.3.0https://gitlab.nic.cz/turris/os/build/-/issues/250Switching from HBD to HBL - dnsmasq does not start up2021-03-11T15:10:42+01:00Josef SchlehoferSwitching from HBD to HBL - dnsmasq does not start up```
Mar 3 13:58:09 turris dnsmasq[4923]: directory /tmp/resolv.conf.d/resolv.conf.auto for resolv-file is missing, cannot poll
Mar 3 13:58:09 turris dnsmasq[4923]: FAILED to start up
``````
Mar 3 13:58:09 turris dnsmasq[4923]: directory /tmp/resolv.conf.d/resolv.conf.auto for resolv-file is missing, cannot poll
Mar 3 13:58:09 turris dnsmasq[4923]: FAILED to start up
```Turris OS 6.0Jan PavlinecJan Pavlinechttps://gitlab.nic.cz/turris/os/build/-/issues/253Service umount is not enabled in medkit2021-06-07T19:42:51+02:00Karel KociService umount is not enabled in medkitThe service `umount` is in `/etc/services_wanted` and on update of package `base-files` that contains it is enabled and started but in medkit it is not.
This looks like issue of the chicken and an egg. The `base-files` packages is esse...The service `umount` is in `/etc/services_wanted` and on update of package `base-files` that contains it is enabled and started but in medkit it is not.
This looks like issue of the chicken and an egg. The `base-files` packages is essentially the first package to be installed and contains also `/etc/services_wanted`. It is likely that not all what is needed is available and thus service is not enabled.
This is not a big issue as the service only tries to correctly umount all mounted filesystems except of root. The same operation is automatically performed by kernel.https://gitlab.nic.cz/turris/os/build/-/issues/254HBD foris packages fails because of HOST_PYTHON3_PACKAGE_BUILD_DEPENDS2021-04-16T13:01:13+02:00Jan PavlinecHBD foris packages fails because of HOST_PYTHON3_PACKAGE_BUILD_DEPENDSThis is probably caused by the change in upstream which enforce hash-checking mode https://github.com/openwrt/packages/commit/722a5b8efa19fd54728af462441dce08cd7e545b#diff-fa6b0696cebe1268910fdb21771e2592ee327510315d970731e585571f1cd7b8...This is probably caused by the change in upstream which enforce hash-checking mode https://github.com/openwrt/packages/commit/722a5b8efa19fd54728af462441dce08cd7e545b#diff-fa6b0696cebe1268910fdb21771e2592ee327510315d970731e585571f1cd7b8
Example of error message for foris-diagnostics-plugin
switched to the more experimental branch.
```
ERROR: Could not open requirements file: [Errno 2] No such file or directory: '/home/beast/beast/workspace/turris-os-packages-dragons-omnia/build/feeds/packages/lang/python/host-pip-requirements/libsass==0.14.5.txt'
make[2]: *** [Makefile:50: /home/beast/beast/workspace/turris-os-packages-dragons-omnia/build/build_dir/target-arm_cortex-a9+vfpv3-d16_musl_eabi/foris-diagnostics-plugin-python3/foris-diagnostics-plugin-12.2/.built] Error 1
time: package/feeds/turrispackages/foris-diagnostics-plugin/python3/compile#0.77#0.18#0.92
```Turris OS 6.0https://gitlab.nic.cz/turris/os/build/-/issues/255php: memory limit is too low for nextcloud2021-04-10T18:26:12+02:00Jan Pavlinecphp: memory limit is too low for nextcloudThe memory limit is too low for nextcloud installation. Because of that nextcloud is complaining
```
The current PHP memory limit is below the recommended value of 512MB.
```
This should be changed in https://gitlab.nic.cz/turris/turr...The memory limit is too low for nextcloud installation. Because of that nextcloud is complaining
```
The current PHP memory limit is below the recommended value of 512MB.
```
This should be changed in https://gitlab.nic.cz/turris/turris-build/-/blob/hbk/patches/packages/branding/0009-php7-Tunning-of-default-options.patch to 512MBTurris OS 5.3.0Jan PavlinecJan Pavlinechttps://gitlab.nic.cz/turris/os/build/-/issues/263uboot-tools fails to build for Turris1x2023-08-16T10:58:02+02:00Jan Pavlinecuboot-tools fails to build for Turris1xThis is affecting HBD branch for Turris1.x
Error log
```
In file included from include/configs/sandbox.h:67,
from include/config.h:4,
from ./include/common.h:16:
include/config_distro_bootcmd.h:337:3: e...This is affecting HBD branch for Turris1.x
Error log
```
In file included from include/configs/sandbox.h:67,
from include/config.h:4,
from ./include/common.h:16:
include/config_distro_bootcmd.h:337:3: error: #error "sandbox EFI support is only supported on ARM and x86"
# error "sandbox EFI support is only supported on ARM and x86"
^~~~~
make[4]: *** [scripts/Makefile.autoconf:77: u-boot.cfg] Error 1
```Turris OS 6.0Jan PavlinecJan Pavlinechttps://gitlab.nic.cz/turris/os/build/-/issues/268Fix netboot file names in sums2021-10-15T17:22:19+02:00Vojtech MyslivecFix netboot file names in sumsMOX netboot image has the same "latest" symlink scheme as medkit has.
We should fix the file names in the "latest" files generated by `shasum` (etc.)MOX netboot image has the same "latest" symlink scheme as medkit has.
We should fix the file names in the "latest" files generated by `shasum` (etc.)https://gitlab.nic.cz/turris/os/build/-/issues/270migration 3x and fix-dhparam-to-cagen2023-08-16T10:57:08+02:00Jan Pavlinecmigration 3x and fix-dhparam-to-cagenA user reported, that after successful migration from 3x to 5.2.1 he had to manually install fix-dhparam-to-cagen package https://tracker.nic.cz/Ticket/Display.html?id=1331823A user reported, that after successful migration from 3x to 5.2.1 he had to manually install fix-dhparam-to-cagen package https://tracker.nic.cz/Ticket/Display.html?id=1331823Turris OS 5.2.4https://gitlab.nic.cz/turris/os/build/-/issues/271Service enabled query reports disabled service for those without START2021-09-21T12:24:48+02:00Karel KociService enabled query reports disabled service for those without STARTServices can specify one of or both `START`, `STOP` numbers. The enable then creates appropriate file. The issue is that right now `enabled` check verifies only existence of `START` file while there are common and even basic (such as `um...Services can specify one of or both `START`, `STOP` numbers. The enable then creates appropriate file. The issue is that right now `enabled` check verifies only existence of `START` file while there are common and even basic (such as `umount`) services that do not specify only `STOP`.Turris OS 5.3.0https://gitlab.nic.cz/turris/os/build/-/issues/275btrfs instruction not supported on TurrisOS 5.2.12023-08-16T10:59:12+02:00Mikebtrfs instruction not supported on TurrisOS 5.2.1`➜ ~ btrfs sub show -ruh /srv
ERROR: uh is not a valid numeric value.
➜ ~ btrfs sub show -ru /srv
ERROR: u is not a valid numeric value.
➜ ~ btrfs sub show -uh /srv
ERROR: can't find uuid '6d650000-a875-5100-2000-000000000000' on ...`➜ ~ btrfs sub show -ruh /srv
ERROR: uh is not a valid numeric value.
➜ ~ btrfs sub show -ru /srv
ERROR: u is not a valid numeric value.
➜ ~ btrfs sub show -uh /srv
ERROR: can't find uuid '6d650000-a875-5100-2000-000000000000' on '/srv'
[1] 22243 illegal hardware instruction btrfs sub show -uh /srv
➜ ~ btrfs sub show -u /srv
btrfs subvolume show: exactly 1 argument expected, 0 given
`Michal HruseckyMichal Hruseckyhttps://gitlab.nic.cz/turris/os/build/-/issues/276Command failed: Not found reported from almost all packages on update to TOS 6.02023-08-16T10:55:27+02:00Karel KociCommand failed: Not found reported from almost all packages on update to TOS 6.0The error is generated from ubus call. The issue seems to be that procd stops talking to ubus and thus it is no longer possible to spawn any service.
There is just nothing on ubus and ubus reports that error. The effect is that services...The error is generated from ubus call. The issue seems to be that procd stops talking to ubus and thus it is no longer possible to spawn any service.
There is just nothing on ubus and ubus reports that error. The effect is that services are not reloaded but also that any operation that ubus is required for just
simply fails.
This seems like there was some ubus change that is not compatible or that there is some bug in procd that fails to reconnect to ubus.Turris OS 6.0