Turris OS packages issueshttps://gitlab.nic.cz/turris/os/packages/-/issues2022-06-22T16:46:34+02:00https://gitlab.nic.cz/turris/os/packages/-/issues/587Turris 1.x: Update U-boot2022-06-22T16:46:34+02:00Karel KociTurris 1.x: Update U-bootUpdate uboot to new version on Turris 1.x. Doing so should enable for example boot from USB.Update uboot to new version on Turris 1.x. Doing so should enable for example boot from USB.Turris OS 6.1.0https://gitlab.nic.cz/turris/os/packages/-/issues/780Restarting kresd or resolver leads to no such file or directory for resolv.co...2022-07-02T08:55:14+02:00Josef SchlehoferRestarting kresd or resolver leads to no such file or directory for resolv.conf.vpnThis is happening on Turris OS 6.0.
```
root@omnia:~# /etc/init.d/kresd stop
root@omnia:~# /etc/init.d/kresd start
ls: /etc/resolv.conf.vpn.*: No such file or directory
job 4 at Sun Jul 18 09:12:00 2021
root@omnia:~# /etc/init.d/kresd s...This is happening on Turris OS 6.0.
```
root@omnia:~# /etc/init.d/kresd stop
root@omnia:~# /etc/init.d/kresd start
ls: /etc/resolv.conf.vpn.*: No such file or directory
job 4 at Sun Jul 18 09:12:00 2021
root@omnia:~# /etc/init.d/kresd stop
root@omnia:~# /etc/init.d/kresd start
ls: /etc/resolv.conf.vpn.*: No such file or directory
job 5 at Sun Jul 18 09:12:00 2021
root@omnia:~# /etc/init.d/kresd stop
root@omnia:~# /etc/init.d/kresd start
ls: /etc/resolv.conf.vpn.*: No such file or directory
job 6 at Sun Jul 18 09:12:00 2021
```Turris OS 5.3.11https://gitlab.nic.cz/turris/os/packages/-/issues/579ip-full broken in TurrisOS 5.0.0, breaks mwan32022-07-04T20:29:18+02:00Leonardo Brondani Schenkelip-full broken in TurrisOS 5.0.0, breaks mwan3Using `hbt` branch in Turris Omnia:
```
/etc/turris-version: 5.0.0
ip-full - 5.0.0-2.1.0
mwan3 - 2.8.1-1.17
```
`mwan3` needs `ip-full` to work. I have both installed, but the Turris setup is broken. This is logged during `mwan3` start-...Using `hbt` branch in Turris Omnia:
```
/etc/turris-version: 5.0.0
ip-full - 5.0.0-2.1.0
mwan3 - 2.8.1-1.17
```
`mwan3` needs `ip-full` to work. I have both installed, but the Turris setup is broken. This is logged during `mwan3` start-up:
```
ip: invalid argument '0x3d00/0x3F00' to 'fwmark'
ip: invalid argument '0x3e00/0x3F00' to 'fwmark'
ip: invalid argument '0x3d00/0x3F00' to 'fwmark'
ip: invalid argument '0x3e00/0x3F00' to 'fwmark'
ip: invalid argument '0x100/0x3F00' to 'fwmark'
```
The reason for this error is because `ip-full` does not update the `ip` symlink:
```
# opkg files ip-full
Package ip-full (5.0.0-2.1.0) is installed on root and has the following files:
/usr/libexec/ip-full
# ls -l /sbin/ip
lrwxrwxrwx 1 root root 20 Apr 18 13:25 /sbin/ip -> ../bin/busybox
# opkg search /sbin/ip
busybox - 1.30.1-5.18
```
`ip-full` should be updating the `/sbin/ip` symlink to point to `/usr/libexec/ip-full` (or `mwan3` should be updated to invoke `/usr/libexec/ip-full`). If I update the symlink myself, everything works. However, this is an incredible fragile setup because any update restores the symlink back to busybox.
IMO Turris should ship with `ip-full` as the default `ip` command. It does not make sense to use `busybox` since it is not resource-constrained in the same way as most routers.Turris OS 5.0https://gitlab.nic.cz/turris/os/packages/-/issues/832Fosquitto fails to start during boot on Mox AEEE2022-07-12T14:40:30+02:00Martin MatějekFosquitto fails to start during boot on Mox AEEE## Description
Foris-controller fails to start because mosquitto is not running.
Manual restart of both fixes it.
Mosquitto fails with following error:
```
Feb 22 18:07:13 MOOOOX kernel: [ 26.145185] mv88e6085 d0032004.mdio-mii:10: p...## Description
Foris-controller fails to start because mosquitto is not running.
Manual restart of both fixes it.
Mosquitto fails with following error:
```
Feb 22 18:07:13 MOOOOX kernel: [ 26.145185] mv88e6085 d0032004.mdio-mii:10: p10: already a member of VLAN 1
Feb 22 18:07:13 MOOOOX kernel: [ 26.176386] mv88e6085 d0032004.mdio-mii:11: p9: already a member of VLAN 1
Feb 22 17:07:13 MOOOOX mosquitto[3778]: 1645549633: Error: Address not available
Feb 22 17:07:13 MOOOOX procd: Instance fosquitto::instance1 s in a crash loop 26 crashes, 0 seconds since last crash
[...]
Feb 22 17:07:16 MOOOOX netifd: bridge 'br-lan' link is up
Feb 22 17:07:16 MOOOOX netifd: Interface 'lan' has link connectivity
Feb 22 17:07:17 MOOOOX turris: Router Turris successfully started.
```
Most likely culprit is that bridges are not up and running at the time, when mosquitto is starting. So it is most likely timing issue.
## How to reproduce
MOX (AEEE), TOS 6.0, HBL, no VLAN configured
2x modules E seems OK, 3x seems to trigger it.
cc: @jhoracekhttps://gitlab.nic.cz/turris/os/packages/-/issues/814WIP: Turris 1x broken after migration2022-07-29T11:42:09+02:00Jan BetikWIP: Turris 1x broken after migrationI started with TOS 3.11.23 - asked for the migration process to be run by updater. No special setup, only the NTFS formatted SD card installed, thus th system was before `btrfs_migrate`.
Updater started with migration and first problem ...I started with TOS 3.11.23 - asked for the migration process to be run by updater. No special setup, only the NTFS formatted SD card installed, thus th system was before `btrfs_migrate`.
Updater started with migration and first problem appeared.
```
2021-12-28 16:12:27 info updater[17062]: src/lib/logging.c:206 (log_subproc_open): Running postinst of libgcc
2021-12-28 16:12:27 info kernel[]: [ 282.537902] libgcc.postinst[18262]: unhandled signal 11 at fffffb34 nip b7f2a05c lr b7f196b0 code 30001
2021-12-28 16:12:27 info updater[17062]: src/lib/logging.c:206 (log_subproc_open): Running postinst of libc
2021-12-28 16:12:27 info kernel[]: [ 282.553791] libc.postinst[18263]: unhandled signal 11 at 00002b34 nip b7bcd05c lr b7bbc6b0 code 30001
2021-12-28 16:12:27 info updater[17062]: src/lib/logging.c:206 (log_subproc_open): Running postinst of tos3to4-earliest
2021-12-28 16:12:27 info kernel[]: [ 282.568037] tos3to4-earlies[18264]: unhandled signal 11 at ffff9b34 nip b7de405c lr b7dd36b0 code 30001
2021-12-28 16:12:27 info updater[17062]: src/lib/logging.c:206 (log_subproc_open): Running postinst of libjson-c
2021-12-28 16:12:27 info kernel[]: [ 282.583715] libjson-c.posti[18265]: unhandled signal 4 at b78b8060 nip b78b8060 lr b78a76b0 code 30001
2021-12-28 16:12:27 info updater[17062]: src/lib/logging.c:206 (log_subproc_open): Running postinst of libubox
2021-12-28 16:12:27 info kernel[]: [ 282.600724] libubox.postins[18266]: unhandled signal 11 at 00006b34 nip b7e3105c lr b7e206b0 code 30001
2021-12-28 16:12:27 info updater[17062]: src/lib/logging.c:206 (log_subproc_open): Running postinst of jsonfilter
2021-12-28 16:12:27 info kernel[]: [ 282.615858] jsonfilter.post[18268]: unhandled signal 11 at b7f0fbc8 nip b7f1505c lr b7f046b0 code 30002
2021-12-28 16:12:27 info updater[17062]: src/lib/logging.c:206 (log_subproc_open): Running postinst of busybox
2021-12-28 16:12:27 info kernel[]: [ 282.631217] busybox.postins[18269]: unhandled signal 11 at ffffab34 nip b7cd505c lr b7cc46b0 code 30001
2021-12-28 16:12:27 info updater[17062]: src/lib/logging.c:206 (log_subproc_open): Running postinst of ca-certificates
2021-12-28 16:12:27 info kernel[]: [ 282.646944] ca-certificates[18270]: unhandled signal 11 at 04008b34 nip b784105c lr b78306b0 code 30001
2021-12-28 16:12:27 info updater[17062]: src/lib/logging.c:206 (log_subproc_open): Running postinst of libopenssl
2021-12-28 16:12:28 info kernel[]: [ 282.662270] libopenssl.post[18271]: unhandled signal 11 at ffffcf50 nip b7d7705c lr b7d666b0 code 30001
2021-12-28 16:12:28 info updater[17062]: src/lib/logging.c:206 (log_subproc_open): Running postinst of libexpat
2021-12-28 16:12:28 info kernel[]: [ 282.678177] libexpat.postin[18272]: unhandled signal 4 at b7c79060 nip b7c79060 lr b7c686b0 code 30001
<output ommited>
2021-12-28 16:12:29 info updater-supervisor[]: pkgupdate exited with: -4
2021-12-28 16:12:29 info updater-supervisor[]: Notification creation failed.
2021-12-28 16:12:29 info updater-supervisor[5500]: Last message 'Notification creatio' repeated 1 times, suppressed by syslog-ng on turris
2021-12-28 16:12:29 info updater-supervisor[]: Notifier failed
2021-12-28 16:12:55 err foris-controller[16562]: ERROR:foris_controller_backends.uci:Uci transaction terminated.
2021-12-28 16:12:55 err foris-controller[16562]: ERROR:foris_controller.message_router:Internal error occured <class 'FileNotFoundError'>('[Errno 2] No such file or directory: 'uci''):
2021-12-28 16:12:55 warning kernel[]: [ 310.582492] _exception: 17 callbacks suppressed
2021-12-28 16:12:55 info kernel[]: [ 310.582506] list_notificati[18302]: unhandled signal 11 at 00001b34 nip b7fdc05c lr b7fcb6b0 code 30001
2021-12-28 16:12:55 err foris-controller[16562]: ERROR:foris_controller_backends.cmdline:Command ('/usr/bin/list_notifications', '-n') unexpected returncode (-11, expected 0).
2021-12-28 16:12:55 err foris-controller[16562]: ERROR:foris_controller.message_router:Internal error occured <class 'foris_controller.exceptions.BackendCommandFailed'>('Retval=-11 for ('/usr/bin/list_notifications', '-n')'):
```
which led to (after the reboot)
```
/etc/preinit: exec: line 5: /sbin/init: not found
[ 3.473140] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00007f00
[ 3.473140]
[ 3.482286] CPU: 1 PID: 1 Comm: sh Not tainted 4.4.199-f90a52a6230ecb072f657fce5aebd444-1 #1
[ 3.490724] Call Trace:
[ 3.493174] [da843e60] [c04ed1f8] dump_stack+0x84/0xb0 (unreliable)
[ 3.499446] [da843e70] [c04e8d94] panic+0xe0/0x21c
[ 3.504240] [da843ed0] [c002e778] do_exit+0x430/0x84c
[ 3.509291] [da843f10] [c002ec18] do_group_exit+0x48/0xac
[ 3.514690] [da843f30] [c002ec90] __wake_up_parent+0x0/0x18
[ 3.520267] [da843f40] [c000e18c] ret_from_syscall+0x0/0x3c
[ 3.525841] --- interrupt: c01 at 0xb79a9214
[ 3.525841] LR = 0xb7a005b0
[ 3.533244] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00007f00
[ 3.533244]
```
After the factory reset, I upgraded to 3.11.23 again and tried a manual btrfs migration, which was partly successful.
```
root@turris:/# btrfs_migrate
Are you sure you want to lose everything on mmcblk0? (yes/no)
yes
11+0 records in
11+0 records out
Welcome to fdisk (util-linux 2.29.2).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.
Device does not contain a recognized partition table.
Created a new DOS disklabel with disk identifier 0x24cb70dc.
Command (m for help): Created a new DOS disklabel with disk identifier 0x1f92cd7b.
Command (m for help): Partition type
p primary (0 primary, 0 extended, 4 free)
e extended (container for logical partitions)
Select (default p): Partition number (1-4, default 1): First sector (2048-31116287, default 2048): Last sector, +sectors or +size{K,M,G,T,P} (2048-31116287, default 31116287):
Created a new partition 1 of type 'Linux' and of size 100 MiB.
Command (m for help): Partition type
p primary (1 primary, 0 extended, 3 free)
e extended (container for logical partitions)
Select (default p): Partition number (2-4, default 2): First sector (206848-31116287, default 206848): Last sector, +sectors or +size{K,M,G,T,P} (206848-31116287, default 31116287):
Created a new partition 2 of type 'Linux' and of size 14.8 GiB.
Command (m for help): The partition table has been altered.
Calling ioctl() to re-read partition table.
Syncing disks.
mkfs.fat 3.0.28 (2015-05-16)
btrfs-progs v5.6
See http://btrfs.wiki.kernel.org for more information.
Detected a SSD, turning off metadata duplication. Mkfs with -m dup if you want to force metadata duplication.
Performing full device TRIM /dev/mmcblk0p2 (14.74GiB) ...
Warning, could not drop caches
Warning, could not drop caches
Label: (null)
UUID: 1aac0a75-1cf7-4ca6-9918-54d8379670fd
Node size: 16384
Sector size: 4096
Filesystem size: 14.74GiB
Block group profiles:
Data: single 8.00MiB
Metadata: single 8.00MiB
System: single 4.00MiB
SSD detected: yes
Incompat features: extref, skinny-metadata
Checksum: crc32c
Number of devices: 1
Devices:
ID SIZE PATH
1 14.74GiB /dev/mmcblk0p2
Warning, could not drop caches
Create subvolume '/tmp/btrfs-convert/target/@'
mount: unknown filesystem type 'vfat'
Can't mount fat
root@turris:/# reboot
root@turris:/# Stopping router Turris.
```
Next reboot was still from the NAND.
```
root@turris:/# mount
ubi0:rootfs on / type ubifs (rw,noatime,chk_data_crc)
```
The second attempt of btrfs migration was successful.
```
root@turris:/# btrfs_migrate
Are you sure you want to lose everything on mmcblk0? (yes/no)
yes
11+0 records in
11+0 records out
Welcome to fdisk (util-linux 2.29.2).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.
Device does not contain a recognized partition table.
Created a new DOS disklabel with disk identifier 0x4fcec8a8.
Command (m for help): Created a new DOS disklabel with disk identifier 0x2c3ea739.
Command (m for help): Partition type
p primary (0 primary, 0 extended, 4 free)
e extended (container for logical partitions)
Select (default p): Partition number (1-4, default 1): First sector (2048-31116287, default 2048): Last sector, +sectors or +size{K,M,G,T,P} (2048-31116287, default 31116287):
Created a new partition 1 of type 'Linux' and of size 100 MiB.
Command (m for help): Partition type
p primary (1 primary, 0 extended, 3 free)
e extended (container for logical partitions)
Select (default p): Partition number (2-4, default 2): First sector (206848-31116287, default 206848): Last sector, +sectors or +size{K,M,G,T,P} (206848-31116287, default 31116287):
Created a new partition 2 of type 'Linux' and of size 14.8 GiB.
Command (m for help): The partition table has been altered.
Calling ioctl() to re-read partition table.
Syncing disks.
mkfs.fat 3.0.28 (2015-05-16)
btrfs-progs v5.6
See http://btrfs.wiki.kernel.org for more information.
Detected a SSD, turning off metadata duplication. Mkfs with -m dup if you want to force metadata duplication.
Performing full device TRIM /dev/mmcblk0p2 (14.74GiB) ...
Label: (null)
UUID: 7d8378ba-6656-4b73-984f-db2c52f7b28b
Node size: 16384
Sector size: 4096
Filesystem size: 14.74GiB
Block group profiles:
Data: single 8.00MiB
Metadata: single 8.00MiB
System: single 4.00MiB
SSD detected: yes
Incompat features: extref, skinny-metadata
Checksum: crc32c
Number of devices: 1
Devices:
ID SIZE PATH
1 14.74GiB /dev/mmcblk0p2
Create subvolume '/tmp/btrfs-convert/target/@'
Warning: Bad CRC, using default environment
Migration successful, please reboot!
root@turris:/#
###
BusyBox v1.29.3 () built-in shell (ash)
_______ _ _ _____ _____ _____ _____
|__ __|| | | || __ \ | __ \ |_ _| / ____|
| | | | | || |__) || |__) | | | | (___
| | | | | || _ / | _ / | | \___ \
| | | |__| || | \ \ | | \ \ _| |_ ____) |
|_| \____/ |_| \_\|_| \_\|_____||_____/
root@turris:/# mount
/dev/mmcblk0p2 on / type btrfs (rw,noatime,ssd,space_cache,commit=5,subvolid=257,subvol=/@)
```https://gitlab.nic.cz/turris/os/packages/-/issues/779Freshly flashed system is sometimes corrupted2022-07-29T13:34:20+02:00Lukas JelinekFreshly flashed system is sometimes corruptedI've encountered some cases in which a freshly flashed Turris OS 5.2.x was corrupted. These cases occured with both flash ways (from USB drives and from the repository server) and on Omnias, MOXes and Shields. The corrupted systems had m...I've encountered some cases in which a freshly flashed Turris OS 5.2.x was corrupted. These cases occured with both flash ways (from USB drives and from the repository server) and on Omnias, MOXes and Shields. The corrupted systems had malformed initial setup guides (didn't started correctly and/or couldn't proceed) or even didn't start at all.
May be related to #778 and https://gitlab.nic.cz/turris/reforis/reforis/-/issues/340.
![mox-tos-5-2-3](/uploads/aa1558c7219cf984047c344b907c8fa9/mox-tos-5-2-3.mp4)Turris OS 6.0https://gitlab.nic.cz/turris/os/packages/-/issues/842[TurrisOS 6.0 HBL - Omnia] Egress traffic on second Omnia limited to circa 9,...2022-08-07T15:43:17+02:00Orest Worhacz[TurrisOS 6.0 HBL - Omnia] Egress traffic on second Omnia limited to circa 9,5Mbit/sHi,
I have really uncommon issue described on the forum here: https://forum.turris.cz/t/tos6-0-bottleneck-of-circa-10mbit-s-on-egress-traffic-only/17273
I am using two Omnias with TOS6.0 and was wondering if you could somehow reproduce...Hi,
I have really uncommon issue described on the forum here: https://forum.turris.cz/t/tos6-0-bottleneck-of-circa-10mbit-s-on-egress-traffic-only/17273
I am using two Omnias with TOS6.0 and was wondering if you could somehow reproduce the issue in your lab.https://gitlab.nic.cz/turris/os/packages/-/issues/846Turris 1.x Btrfs kernel install can not find boot.scr2022-08-11T19:44:31+02:00Josef SchlehoferTurris 1.x Btrfs kernel install can not find boot.scrPackage: turris1x-btrfs
```
root@turris:~# /usr/sbin/turris1x-btrfs-kernel-install
cmp: /boot/boot.scr: No such file or directory
cp: can't stat '/boot/boot.scr': No such file or directory
```
Caused by this https://gitlab.nic.cz/turri...Package: turris1x-btrfs
```
root@turris:~# /usr/sbin/turris1x-btrfs-kernel-install
cmp: /boot/boot.scr: No such file or directory
cp: can't stat '/boot/boot.scr': No such file or directory
```
Caused by this https://gitlab.nic.cz/turris/os/packages/-/merge_requests/921
Temporary workaround:
- remove this row ``deploy boot.scr`` from file: /usr/sbin/turris1x-btrfs-kernel-install
It's a thing, when boot.scr can not be found in folder /boot. See:
```
Package turris1x-support (5.4.203-1-f70e9c9745643e220f2338b431a1b5ff) is installed on root and has the following files:
/boot/turris1x.dtb
/boot/fdt
/boot.scr
```
**Because of that a new kernel version is not installed.**Turris OS 6.0https://gitlab.nic.cz/turris/os/packages/-/issues/741switch-branch: warn that downgrades are not supported2022-08-11T21:38:40+02:00Karel Kociswitch-branch: warn that downgrades are not supportedWe can't support downgrades and the only way to perform downgrade is by using switch-branch and switching to more stable branch. We don't have to essentially deny it but we should add big warning that user can experience unexpected issues.We can't support downgrades and the only way to perform downgrade is by using switch-branch and switching to more stable branch. We don't have to essentially deny it but we should add big warning that user can experience unexpected issues.Turris OS 5.3.11Karel KociKarel Kocihttps://gitlab.nic.cz/turris/os/packages/-/issues/847mox-a53-firmware: drop PROVIDES:=u-boot-mox2022-08-12T14:17:26+02:00Michal Vasilekmox-a53-firmware: drop PROVIDES:=u-boot-mox`PROVIDES:=u-boot-mox` is there only for backwards compatibility with packages that used this name, check which packages depend on u-boot-mox, make them refer to mox-a53-firmware directly (not through PROVIDES) and drop the PROVIDES line...`PROVIDES:=u-boot-mox` is there only for backwards compatibility with packages that used this name, check which packages depend on u-boot-mox, make them refer to mox-a53-firmware directly (not through PROVIDES) and drop the PROVIDES line from mox-a53-firmware.https://gitlab.nic.cz/turris/os/packages/-/issues/837Rescue system in rescue-image_3.6.1-1 does not work2022-08-13T09:44:13+02:00Jan BetikRescue system in rescue-image_3.6.1-1 does not workSSL wget does not work. Flash from the cloud not possible.
```
~ # ping -s 1500 nic.cz
PING nic.cz (217.31.205.50): 1500 data bytes
1508 bytes from 217.31.205.50: seq=0 ttl=61 time=2.074 ms
1508 bytes from 217.31.205.50: seq=1 ttl=61 tim...SSL wget does not work. Flash from the cloud not possible.
```
~ # ping -s 1500 nic.cz
PING nic.cz (217.31.205.50): 1500 data bytes
1508 bytes from 217.31.205.50: seq=0 ttl=61 time=2.074 ms
1508 bytes from 217.31.205.50: seq=1 ttl=61 time=1.694 ms
1508 bytes from 217.31.205.50: seq=2 ttl=61 time=1.843 ms
1508 bytes from 217.31.205.50: seq=3 ttl=61 time=1.750 ms
1508 bytes from 217.31.205.50: seq=4 ttl=61 time=1.828 ms
^C
--- nic.cz ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 1.694/1.837/2.074 ms
~ # wget https://repo.turris.cz/hbs/medkit/omnia-medkit-latest.tar.gz
--2022-04-28 14:26:03-- https://repo.turris.cz/hbs/medkit/omnia-medkit-latest.tar.gz
^C
~ # wget -c http://www.nic.cz/
--2022-04-28 14:26:56-- http://www.nic.cz/
Resolving www.nic.cz... 2001:1488:0:3::2, 217.31.205.50
Connecting to www.nic.cz|2001:1488:0:3::2|:80... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://www.nic.cz/ [following]
--2022-04-28 14:26:56-- https://www.nic.cz/
^C
~ # wget --version
GNU Wget 1.20.3 built on linux-gnu.
-cares +digest -gpgme +https +ipv6 -iri +large-file -metalink -nls
+ntlm +opie -psl +ssl/openssl
Wgetrc:
/etc/wgetrc (system)
Compile:
ccache_cc -DHAVE_CONFIG_H -DSYSTEM_WGETRC="/etc/wgetrc"
-DLOCALEDIR="/usr/share/locale" -I. -I../lib -I../lib
-I/home/beast/beast/workspace/turris-os-packages-lions-omnia/build/staging_dir/target-arm_cortex-a9+vfpv3-d16_musl_eabi/usr/include
-I/home/beast/beast/workspace/turris-os-packages-lions-omnia/build/staging_dir/target-arm_cortex-a9+vfpv3-d16_musl_eabi/include
-I/home/beast/beast/workspace/turris-os-packages-lions-omnia/build/staging_dir/toolchain-arm_cortex-a9+vfpv3-d16_gcc-7.5.0_musl_eabi/usr/include
-I/home/beast/beast/workspace/turris-os-packages-lions-omnia/build/staging_dir/toolchain-arm_cortex-a9+vfpv3-d16_gcc-7.5.0_musl_eabi/include/fortify
-I/home/beast/beast/workspace/turris-os-packages-lions-omnia/build/staging_dir/toolchain-arm_cortex-a9+vfpv3-d16_gcc-7.5.0_musl_eabi/include
-I/home/beast/beast/workspace/turris-os-packages-lions-omnia/build/staging_dir/target-arm_cortex-a9+vfpv3-d16_musl_eabi/usr/include
-I/home/beast/beast/workspace/turris-os-packages-lions-omnia/build/staging_dir/target-arm_cortex-a9+vfpv3-d16_musl_eabi/usr/include
-DNDEBUG -Os -pipe -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-lions-omnia/build/build_dir/target-arm_cortex-a9+vfpv3-d16_musl_eabi/wget-ssl/wget-1.20.3:wget-1.20.3
-Wformat -Werror=format-security -fpic -fstack-protector-strong
-D_FORTIFY_SOURCE=2 -Wl,-z,now -Wl,-z,relro
Link:
ccache_cc
-I/home/beast/beast/workspace/turris-os-packages-lions-omnia/build/staging_dir/target-arm_cortex-a9+vfpv3-d16_musl_eabi/usr/include
-I/home/beast/beast/workspace/turris-os-packages-lions-omnia/build/staging_dir/target-arm_cortex-a9+vfpv3-d16_musl_eabi/usr/include
-DNDEBUG -Os -pipe -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-lions-omnia/build/build_dir/target-arm_cortex-a9+vfpv3-d16_musl_eabi/wget-ssl/wget-1.20.3:wget-1.20.3
-Wformat -Werror=format-security -fpic -fstack-protector-strong
-D_FORTIFY_SOURCE=2 -Wl,-z,now -Wl,-z,relro
-L/home/beast/beast/workspace/turris-os-packages-lions-omnia/build/staging_dir/target-arm_cortex-a9+vfpv3-d16_musl_eabi/usr/lib
-L/home/beast/beast/workspace/turris-os-packages-lions-omnia/build/staging_dir/target-arm_cortex-a9+vfpv3-d16_musl_eabi/lib
-L/home/beast/beast/workspace/turris-os-packages-lions-omnia/build/staging_dir/toolchain-arm_cortex-a9+vfpv3-d16_gcc-7.5.0_musl_eabi/usr/lib
-L/home/beast/beast/workspace/turris-os-packages-lions-omnia/build/staging_dir/toolchain-arm_cortex-a9+vfpv3-d16_gcc-7.5.0_musl_eabi/lib
-fpic
-specs=/home/beast/beast/workspace/turris-os-packages-lions-omnia/build/include/hardened-ld-pie.specs
-znow -zrelro
-L/home/beast/beast/workspace/turris-os-packages-lions-omnia/build/staging_dir/target-arm_cortex-a9+vfpv3-d16_musl_eabi/usr/lib
-lpcre
/home/beast/beast/workspace/turris-os-packages-lions-omnia/build/staging_dir/target-arm_cortex-a9+vfpv3-d16_musl_eabi/usr/lib/libssl.so
/home/beast/beast/workspace/turris-os-packages-lions-omnia/build/staging_dir/target-arm_cortex-a9+vfpv3-d16_musl_eabi/usr/lib/libcrypto.so
-ldl
-L/home/beast/beast/workspace/turris-os-packages-lions-omnia/build/staging_dir/target-arm_cortex-a9+vfpv3-d16_musl_eabi/usr/lib
-lz ftp-opie.o openssl.o http-ntlm.o ../lib/libgnu.a
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://www.gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Originally written by Hrvoje Niksic <hniksic@xemacs.org>.
Please send bug reports and questions to <bug-wget@gnu.org>.
~ # wget -c http://repo.turris.cz/hbs/medkit/omnia-medkit-latest.tar.gz
--2022-04-28 14:30:50-- http://repo.turris.cz/hbs/medkit/omnia-medkit-latest.tar.gz
Resolving repo.turris.cz... 2001:1488:ac15:ff80::84, 217.31.192.84
Connecting to repo.turris.cz|2001:1488:ac15:ff80::84|:80... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://repo.turris.cz/hbs/medkit/omnia-medkit-latest.tar.gz [following]
--2022-04-28 14:30:50-- https://repo.turris.cz/hbs/medkit/omnia-medkit-latest.tar.gz
^C
```Michal HruseckyMichal Hruseckyhttps://gitlab.nic.cz/turris/os/packages/-/issues/838Turris-auth version 0.4.02022-08-15T13:30:31+02:00Karel KociTurris-auth version 0.4.0Turris-auth can be bumped to 0.4.0 to include the LuCI integration. It should also be enabled in the configuration using the new argument.
https://gitlab.nic.cz/turris/turris-auth/-/tags/v0.4.0Turris-auth can be bumped to 0.4.0 to include the LuCI integration. It should also be enabled in the configuration using the new argument.
https://gitlab.nic.cz/turris/turris-auth/-/tags/v0.4.0Turris OS 6.02022-08-17https://gitlab.nic.cz/turris/os/packages/-/issues/660No auth required for Foris and reForis2022-08-18T18:40:43+02:00kovariktomasNo auth required for Foris and reForis
After last update from 7. 9. 2020, I can access Foris/reForis without password. Logout button do not working. I tried to set a new password in the administration, but authentication is not required. Rebooting will not solve the problem....
After last update from 7. 9. 2020, I can access Foris/reForis without password. Logout button do not working. I tried to set a new password in the administration, but authentication is not required. Rebooting will not solve the problem.
Update from 2020/09/07 20:42:35
• Installed version 1-1 of package fix-config-foris-restore
| Turris OS version | 5.1.0 |
|-------------------|----------|
| Turris OS branch | hbk |
| Kernel version | 4.14.195 |
```
############## 08_os-release
== Current ==
~~ File: /etc/os-release ~~
NAME="TurrisOS"
VERSION="5.1.0"
ID="turrisos"
ID_LIKE="lede openwrt"
PRETTY_NAME="TurrisOS 5.1.0"
VERSION_ID="5.1.0"
HOME_URL="https://www.turris.cz/"
BUG_URL="https://gitlab.labs.nic.cz/groups/turris/-/issues/"
SUPPORT_URL="https://www.turris.cz/support/"
BUILD_ID="29b4104"
OPENWRT_BOARD="mvebu/cortexa9"
OPENWRT_ARCH="arm_cortex-a9_vfpv3-d16"
OPENWRT_TAINTS="busybox"
OPENWRT_DEVICE_MANUFACTURER="CZ.NIC"
OPENWRT_DEVICE_MANUFACTURER_URL="https://www.turris.cz/"
OPENWRT_DEVICE_PRODUCT="Turris Omnia"
OPENWRT_DEVICE_REVISION="v0"
OPENWRT_RELEASE="TurrisOS 5.1.0 29b4104d69bf91db17764dd885e9e111a373f08c"
== Factory ==
~~ File: /tmp/tmp.llkpdf/etc/turris-version ~~
4.0
~~ File: /tmp/tmp.llkpdf/etc/os-release ~~
NAME="TurrisOS"
VERSION="4.0-beta5"
ID="turrisos"
ID_LIKE="lede openwrt"
PRETTY_NAME="TurrisOS 4.0-beta5"
VERSION_ID="4.0-beta5"
HOME_URL="https://www.turris.cz/"
BUG_URL="https://gitlab.labs.nic.cz/groups/turris/-/issues"
SUPPORT_URL="https://www.turris.cz/support/"
BUILD_ID="65f9f42"
LEDE_BOARD="mvebu/cortexa9"
LEDE_ARCH="arm_cortex-a9_vfpv3"
LEDE_TAINTS="busybox"
LEDE_DEVICE_MANUFACTURER="CZ.NIC"
LEDE_DEVICE_MANUFACTURER_URL="https://www.turris.cz"
LEDE_DEVICE_PRODUCT="Turris Omnia"
LEDE_DEVICE_REVISION="v0"
LEDE_RELEASE="TurrisOS 4.0-beta5 65f9f42"
************** 08_os-release
```https://gitlab.nic.cz/turris/os/packages/-/issues/820Rescue mode does not see mSATA drives2022-08-18T18:41:22+02:00Jan BetikRescue mode does not see mSATA drivesWhile in rescue mode 5, the system does not see the installed mSATA drive so it is impossible to prepare the drive to boot from it.While in rescue mode 5, the system does not see the installed mSATA drive so it is impossible to prepare the drive to boot from it.Michal HruseckyMichal Hruseckyhttps://gitlab.nic.cz/turris/os/packages/-/issues/709The msata disk is not recognized in the rescue2022-08-18T18:41:23+02:00Jan HoracekThe msata disk is not recognized in the rescueThe current rescue system on the Omnia does not recognize the msata disk, so it is not possible to prepare the disk directly in the omnia in case the emmc memory is damaged.The current rescue system on the Omnia does not recognize the msata disk, so it is not possible to prepare the disk directly in the omnia in case the emmc memory is damaged.Michal HruseckyMichal Hruseckyhttps://gitlab.nic.cz/turris/os/packages/-/issues/843openpvn-client: Use VPN native DNS server to avoid DNS leaks2022-08-18T20:28:02+02:00Martin Matějekopenpvn-client: Use VPN native DNS server to avoid DNS leaksUpon activation, VPN client will successfully create it's own `resolv.conf.vpn.<my_vpn_connection>.conf` file with preferred DNS resolver.
DNS switching might work automatically on upstream OpenWrt with dnsmasq as default resolver, see ...Upon activation, VPN client will successfully create it's own `resolv.conf.vpn.<my_vpn_connection>.conf` file with preferred DNS resolver.
DNS switching might work automatically on upstream OpenWrt with dnsmasq as default resolver, see https://protonvpn.com/support/how-to-set-up-protonvpn-on-openwrt-routers/
However, unlike upstream OpenWrt, Turris OS is using Kresd as DNS resolver, so default resolv conf file (`/tmp/resolv.conf.d/resolv.conf.auto`) will be used instead of the vpn specific `resolf.conf`, which leads to DNS leaks.
We need to figure out how to switch the resolv files upon VPN client startup and shutdown. The `resolv.conf.vpn.<my_vpn_connection>.conf` file is created by the openvpn hotplug scripts, so perhaps we could adjust these scripts to switch DNS resolvers.
For example (crude idea):
```
# up
mv resolv.conf.auto resolv.conf.auto.bkp
ln -s resolv.conf.vpn.myvpn resolv.conf.auto
/etc/init.d/resolver restart
# down
rm resolv.conf.auto
/etc/init.d/resolver restart
```Turris OS 6.0https://gitlab.nic.cz/turris/os/packages/-/issues/311add support for odhcpd & ipv6 in dhcp_host_domain_ng.py2022-09-03T15:38:50+02:00Ghost Useradd support for odhcpd & ipv6 in dhcp_host_domain_ng.pyas apparent from the current code `ipv6` is not supported and `odhcpd` settings are neglected, such as
```
option leasefile
option/list domain
```
This may cause some grievance for users making the transition to ipv6.as apparent from the current code `ipv6` is not supported and `odhcpd` settings are neglected, such as
```
option leasefile
option/list domain
```
This may cause some grievance for users making the transition to ipv6.https://gitlab.nic.cz/turris/os/packages/-/issues/415fosquitto: investigate whether mosquitto is able to run using ECC2022-09-08T21:48:39+02:00Štěpán Henekfosquitto: investigate whether mosquitto is able to run using ECCŠtěpán HenekŠtěpán Henekhttps://gitlab.nic.cz/turris/os/packages/-/issues/850Rainbow: reconsider versioning for all three routers2022-09-16T14:03:23+02:00Josef SchlehoferRainbow: reconsider versioning for all three routersWhile reviewing https://gitlab.nic.cz/turris/os/packages/-/merge_requests/966, I noticed that we need to edit all three Makefiles if we bump rainbow-ng.
You should consider similar solution how it is done for shipping Turris u-boot pack...While reviewing https://gitlab.nic.cz/turris/os/packages/-/merge_requests/966, I noticed that we need to edit all three Makefiles if we bump rainbow-ng.
You should consider similar solution how it is done for shipping Turris u-boot packages in this repository or rather proposed solution, which I got on IRC #openwrt-devel:
```
20:23:24 <pepes> Guys, I am thinking. I would like to have dedicated U-boot package installable within opkg and I could copy the U-boot image from staging_dir and put it to whatever I want. Because right now, I compiling it twice. :-( Is there way, how can I use the same versioning from different package? So, I could know the version of U-boot by opkg. Any ideas?
20:24:05 <jow> pepes: there's no clean way
20:24:23 <jow> you could define a shared .mk file that just declares the version, then include that in both places
20:25:38 <jow> or you could use a construct like PKG_VERSION:=$(if $(DUMP),x,$(shell sed -ne 's#PKG_VERSION:=##p' $(topdir)/package/boot/u-boot-foo/Makefile))
20:28:04 <pepes> Thanks jow! I will try it, but it looks like it is going to help. THanks! I will let you know about it.
```
This means use shared .mk file.Turris OS 6.0.1https://gitlab.nic.cz/turris/os/packages/-/issues/830LEDs in sys are not found in rescue2022-10-17T21:28:55+02:00Josef SchlehoferLEDs in sys are not found in rescueRescue does not work with this:
```
/init: line 35: can't create /sys/class/leds/omnia-led:all/color: nonexistent directory
/init: line 37: can't create /sys/class/leds/omnia-led*/trigger: nonexistent directory
/init: line 39: can't crea...Rescue does not work with this:
```
/init: line 35: can't create /sys/class/leds/omnia-led:all/color: nonexistent directory
/init: line 37: can't create /sys/class/leds/omnia-led*/trigger: nonexistent directory
/init: line 39: can't create /sys/class/leds/omnia-led:power/trigger: nonexistent directory
2s left
cat: can't open '/sys/class/leds/omnia-led:all/device/global_brightness': No such file or directory
sh: out of range
```
In running system:
```
Feb 8 14:50:01 turris crond[5966]: (root) CMD (/usr/bin/rainbow_button_sync.sh)
Feb 8 14:50:01 turris crond[5964]: (root) CMDOUT (Failed to open file: No such file or directory)
Feb 8 14:50:01 turris crond[5964]: (root) CMDEND (/usr/bin/rainbow_button_sync.sh)
```Turris OS 6.1.02022-08-19