Turris OS 7.0 is in rc!

Hi,

You have a PM.

Thank you!

I have disabled autoupdates for the time being. I will report back once I get to try it out again.
I got the Omnia in March 2019 (I checked my inbox and found that I got it from Turris Omnia 2 GB Wi-Fi / Dual-Band 3×3 MIMO 802.11ac / 2×2 802.1 | Mironet.cz).

U-Boot seems old:

root@omnia:~# strings /dev/mtd0 | grep "U-Boot"
U-Boot
U-Boot SPL 2015.10-rc2 (Aug 18 2016 - 20:43:35)
U-Boot 2015.10-rc2 for db-88f682
Warning: U-Boot configured device %s at address %llx,
U-Boot
** Invalid partition type "%.32s" (expect "U-Boot")
U-Boot BUG at %s:%d!
No valid device tree binary found - please append one to U-Boot binary, use u-boot-dtb.bin or define CONFIG_OF_EMBED. For sandbox, use -d <file.dtb>
U-Boot 2015.10-rc2 (Aug 18 2016 - 20:43:35 +0200)

@TomasZak @miska

Has there been any change to Ad Block in this latest RC?

I have updated the u-boot to the latest version via SSH (the MCU firm already had it updated before) → U-Boot SPL 2022.10-rc4-OpenWrt-r16653+119-44ce70f0e2 (Sep 15 2022 - 18:21:35 +0000)

With RC kernel 5.15.148 everything working without problems after this action (nothing new).

In this state I decided to update to the latest RC to test new U-Boot, and the connection and disconnection problems persisted… when it left me… I disabled the Adblock service via Luci, and bingo! → accessing Reforis no longer causes any problems.

Now I have no access to Internet (I would need to investigate it) but no problem with Reforis due “connections/dissconections”.

At the moment I have returned to the RC kernel 5.15.148 version in which everything works well for me.

Greetings.

Regarding Adblock we updated tcpdump package, because DNS Report was not functional (this was reported by user). Regarding Adblock package itself, there wasn’t any change.

Was this commit in the RC kernel 5.15.148 version?

Thanks.

I looked in history and this commit was pushed in the same date as update kernel version from .148 to 151. :slight_smile:

Hmmm, tried it and it works fine :frowning: But one thing we fixed was mentioned AdBlock - it actually gets started now and when it starts, it tries to download lists you have setup and then merges them which poses quite some load on Omnia, so your problem might not be that related to kernel as to AdBlock slowing your network and resolver down as well as Omnia itself. It should stabilize itself after some time.

I pushed into hbk variant with reverted kernel update (building now, should be ready in about an hour), can @webknjaz or @julien113 confirm that that version works for them? This is only temporally solution, we need to get to the bottom of this, but it is hard to fix something we can’t reproduce :frowning:

Hi,

I have removed Adblock packages via SSH in latest RC.

root@TO:~# /etc/init.d/adblock stop;/etc/init.d/adblock disable
root@TO:~# opkg remove adblock --force-removal-of-dependent-packages
Removing package luci-i18n-adblock-en from root...
Removing package luci-app-adblock from root...
Removing package adblock from root...
Not deleting modified conffile /etc/config/adblock.
WARNING: You probably just removed a package that was installed as part of a user list or the basic system.
This package will return durring the next updater run. We suggest you disable the user list instead.
root@TO:~# reboot

Note: not deleting modified conffile /etc/config/adblock.

And the problems with access to the Internet and Reforis persist. Without doing anything, sometimes it lets me surf the net and access Reforis/Luci, and other times it gives me an error like:

  • ERR_NETWORK_CHANGED
  • An error occurred while fetching data
  • Etc

And that’s how it works or it fails in what seems like a repetitive loop.

Not using nftables and no special configuration.

I don’t know what may be happening → Rollback to previous RC and all working like charm :man_shrugging:t2:

Thanks.

Good evening @miska,
I’ve switched to hbk branch and did the update just now.
after rebooting, no boot loop and no issue spotted with the kernel 5.15.148

Are you running Transmission? That has still been hogging 100% CPU in 7.0.

Also, can you check if you have enough disk space when you face the errors? Suricata logs got really silly with the latest RC and can eat up your disk/RAM quite easily.

Hi,

I’ve switched to hbk branch and did the update.

No problems and all working like charm → so we can forget about the new changes about Adblock, my problems with latest RC in HBT are due something related to the kernel update too.

Turris Omnia 2020, U-Boot SPL 2022.10-rc4, Adblock, Dynamic Firewall, New Devices Detection and the latest MCU Firmware.

Thanks.

Hi @miska,

perhaps it is a good idea, if colleagues confirm that with kernel 5.15.148 everything is going well (some of us are already confirming this), move it to HBT, and test kernel updates in HBK.

This commit fixes the problems for now.

Thank you.

Today my turris broke, all LEDs were off and it only “occasionally” reacted to pings…
I rolled back and all was fine… I guess the next update will break it again?

This is how the upgrade looks!

This is the crash after the update!

according to schnapps the last update was

  278 | pre       |    14.77MiB | 2024-02-29 13:39:06 +0100 | Automatic pre-update snapshot (TurrisOS 7.0.0 - hbt)
  279 | post      |     9.70MiB | 2024-02-29 13:39:45 +0100 | Automatic post-update snapshot (TurrisOS 7.0.0 - hbt)

my working version uses
Linux turris 5.15.148 #0 SMP Fri Feb 16 13:01:59 2024 armv7l GNU/Linux

I have rolled back and disabled auto-updates…

Now I’ve noticed iftop is broken and displays wrong (and negative) numbers:

# opkg info iftop
Package: iftop
Version: 2018-10-03-77901c8c-2
Depends: libc, libpcap, libncurses, libpthread
Status: install user installed
Architecture: arm_cortex-a9_vfpv3-d16
Installed-Time: 1665607041

Hi,

we just release a new RC which is basically reverting latest kernel updates till we are able to reproduce the issue and fix it.

Hi,

Hotfix is working in latest HBT.

Thanks.

1 Like

Updated to the current state with Linux turris 5.15.148 #0 SMP Tue Apr 2 01:04:13 2024 armv7l GNU/Linux and all is fine.

Edit: not all is fine, the iftop issue still exists and iftop shows all negative values for some reason.
LUCI’s counters seem to work fine though so maybe it’s not too serious.

Yeah, I’m not sure when this started happening. But it’s not happening on hbs.

After the last update RC I get this error when I try to WebGUI https://192.168.0.1/:
JSON.parse: unexpected character at line 1 column 1 of the JSON data
and
https://192.168.0.1/reforis/:
503 Service Unavailable

Workaround is OFF/ON method.

EDIT: After workaround with
root@home:~# /etc/init.d/lighttpd restart
2024-04-06 11:07:43: (…/src/mod_openssl.c.3137) SSL:openssl library version is outdated and has reached end-of-life. As of 11 Sep 2023, only openssl 3.0.0 and later continue to receive security patches from openssl.org
root@home:~#

Is that okay?

Hi @peci1,

looked closer to the iftop. I got similar behaviour like you have. As solution should be enought just reinstall the package with command:

opkg update && opkg install --force-reinstall iftop

For me after reinstall:

14h_02m_51s_05_Apr_2024

Let me know if it works for you.

4 Likes