We just released a final version of Turris OS 3.11.5 for Turris 1.x and Turris Omnia routers. Mostly it contains security updates including a fix for recently found kernel CVEs, also there are package updates and some of them were requested by our community on the forum.
root@turris:~# pkgupdate
line not found
line not found
line not found
ERROR:
unreachable: https://repo.turris.cz/omnia/lists/base.lua: Operation timed out after 30000 milliseconds with 0 out of 0 bytes received
root@turris:~#
Now that is failing again might be a good time if you repeat the last debugging steps from Unreachable: https://repo.turris.cz/omnia/lists/base.lua and perhaps to post in that thread again - to see what is happening now that it is failing?
“Suricata” nor “Pakon” are not installed, but some files from “suricata” are installed in version 3.11.5:
/usr/bin/suricata_update_rules.sh
/usr/bin/suricatasc
/usr/bin/suricata
/lib/upgrade/keep.d/suricata
/etc/config/suricata
/etc/cron.d/suricata
/etc/init.d/suricata
/etc/suricata
/etc/suricata/suricata.yaml
The btrfs-transaction process now consumes 50% of my CPU on Omnia after the upgrade and the processes are randomly freezing.
No strict evidence it is related to upgrade though. Probably, the file system got corrupted on its own.
EDIT: The filesystem is almost fine:
root@shulyaka:~# btrfs check --readonly --force /dev/mmcblk0p1
Opening filesystem to check...
WARNING: filesystem mounted, continuing because of --force
Checking filesystem on /dev/mmcblk0p1
UUID: 707706b6-22e0-4afa-8f8f-db0f229d097f
[1/7] checking root items
[2/7] checking extents
[3/7] checking free space cache
[4/7] checking fs roots
[5/7] checking only csums items (without verifying data)
[6/7] checking root refs
[7/7] checking quota groups
Counts for qgroup id: 0/256 are different
our: referenced 3263700992 referenced compressed 3263700992
disk: referenced 3263692800 referenced compressed 3263692800
diff: referenced 8192 referenced compressed 8192
our: exclusive 42131456 exclusive compressed 42131456
disk: exclusive 42135552 exclusive compressed 42135552
diff: exclusive -4096 exclusive compressed -4096
Counts for qgroup id: 0/907 are different
our: referenced 3260805120 referenced compressed 3260805120
disk: referenced 3260796928 referenced compressed 3260796928
diff: referenced 8192 referenced compressed 8192
our: exclusive 1613824 exclusive compressed 1613824
disk: exclusive 1617920 exclusive compressed 1617920
diff: exclusive -4096 exclusive compressed -4096
found 5347246080 bytes used, error(s) found
total csum bytes: 4200896
total tree bytes: 1144393728
total fs tree bytes: 1037725696
total extent tree bytes: 94375936
btree space waste bytes: 263368371
file data blocks allocated: 28907012096
referenced 21673910272
observed one oddity after 3.11.5, after updating to 3.11.5 and rebooting, lost network connectivity to the router over both wired and wireless. Used the reset button to go back to the prior snapshot. However, the updater takes two snapshots, one before the update and one post the update, so reset button technique actually moved the router to the snapshot post the update. One wouldn’t expect this to fix anything but surprisingly the router was working again and was on 3.11.5. My only guess is that the router got into some bad state just after the post update snapshot, but before the reboot, so restoring to the post update snapshot fixed things?
Unclear how to even file a bug on this one, but putting this out here in case anyone sees the same.
That is exactly what I experienced!
After the first reboot I was connected but experienced some problems (zombie processes). I decided not to investigate them and just rebooted. After the reboot I had no connection (wired or wireless), however after some time searching for unbrick instructions it just came up by itself (first wireless, then wired).
I can notice that many processes are freezing (blocked) for significant amount of time (measured in minutes) on some disk operations. At the same time the btrfs-transaction process consumes 50% CPU (which is 100% of one core).
...
INFO:Queue install of libmosquitto-nossl/turris/1.5.8-1
INFO:Queue install of mosquitto-client-nossl/turris/1.5.8-1
INFO:Queue removal of libunistring
Press return to continue, CTRL+C to abort
INFO:Executing preupdate hook: 05_schnapps.sh
Snapshot number 12 created
INFO:Unpacking download packages
INFO:Checking for file collisions between packages
line not found
line not found
line not found
line not found
line not found
line not found
DIE:
[string "transaction"]:334: [string "transaction"]:158: Collisions:
• /usr/bin/mosquitto_pub: mosquitto-client-ssl (new-file), mosquitto-client-nossl (new-file)
• /usr/bin/mosquitto_sub: mosquitto-client-ssl (new-file), mosquitto-client-nossl (new-file)
• /usr/lib/libmosquitto.so: libmosquitto-nossl (new-file), libmosquitto-ssl (new-file)
• /usr/lib/libmosquitto.so.1: libmosquitto-nossl (new-file), libmosquitto-ssl (new-file)
Aborted
root@turris:~#
I’ve uninstalled nossl packages using Luci, but pkgupdate wants to install it back
EDIT: find it:
root@turris:/etc# grep -ir mosquitto-client *
grep: fstab: No such file or directory
grep: ppp/resolv.conf: No such file or directory
updater/conf.d/opkg-auto.lua:Install("mosquitto-client-nossl")
updater/conf.d/opkg-auto.lua:Install("mosquitto-client-ssl")
Tak po updatu u mně nefunkční Pakon. Po nějakých machinacích (reinstalace) začal zobrazovat, ale poslední den-dva zobrazí sice neprázdný koláčový graf, ale pod ním žádná data.
Poslední data jsou zapsaná 2019-06-19 19:48:27 00:01:15
