OpenWrt 19.07 - rc2 (Turris OS 5.0 dev) is released!

Thanks for reporting this issue to us. We have been able to reproduce it, and the fix is on its way to you.

Thank you!

My two 2,5" HDDs are still running because of hdparm bug, which is present since moment when I have started to use NAS (present TOS3.x -> TOS4.x -> TOS5) - hdparm loose its values after power loss (most of time) or after regular reboot (occasionally).
So it would be fine to give them some rest after 24 hours :slightly_smiling_face:

EDIT 18.2.2020 20:42: LuCI and SSH are working after update.

Today, whole day there is error in updater:

Updater failed: 

inconsistent: Package crypto-wrapper requires package turris-otp that is not available.
1 Like

There were some changes related to it, but currently I’m not able to reproduce your issue as it was fixed on build servers 3 hours ago.

1 Like

I also can’t reproduce it anymore.

Well, it seems to be working now:

March 12, 2020 8:34 PM

 • Installed version 1.10.0-2.0 of package libunbound
 • Installed version 29.2-2.0 of package libatsha204
 • Installed version 65.0-2.0 of package updater-ng
 • Installed version 204.2-b32129d.1 of package base-files

INFO:Target Turris OS: 5.0.0
ERROR:
inconsistent: Requested package madplay that is not available.
inconsistent: Requested package python3-libatsha204 that is not available.
inconsistent: Requested package python3-pydispatcher that is not available.
inconsistent: Requested package zip that is not available.
inconsistent: Requested package fix-updater-v65.0-alternatives-update that is not available.
root@turris:~# opkg remove fix-updater-v65.0-alternatives-update
No packages removed.
root@turris:~# opkg remove fix-updater-v66.0
No packages removed.
root@turris:~# opkg remove alternative-update
No packages removed.

Branches Here Be Kittens (hbk) :cat:, Here Be Lions (hbl) :lion:, Here be Dragons (hbd) :dragon: are for experienced users.

Packages:

  • zip was removed from packages feed.
    More details in this commit:
    https://github.com/openwrt/packages/commit/e9ea875a1bd9c54f837f9706d5cefdf4eb8209e6

  • python3-pydispatcher was only packaged in Turris OS 3.x, Turris OS 4.x. The latest version 2.0.5 is from 2015 and they claim according to their website that Python 2.x is still the primary development target for them and that’s why it was removed. Python 2.x is going to be EoL soon. There are no packages which depend on it and it is not installed by default.

  • madplay is currently not compiled on OpenWrt 19.07. Needs to be investigated. We don’t have it installed by default and we don’t provide it through our Package lists in Foris. Madplay comes from packages feed.

The rest packages like python3-libatsha204 and fix-updater-v65.0-alternatives-update should be there already. There were not there since yesterday as those three branches are development branches and some occasional bugs are expected. Details about our branches can be found in our documentation.

Mmmh, one switch-branch hbk and one reboot later it seems have worked well. I guess I only need to remember monitoring the forum to not miss when I can down-branch to hbt/hbs again :wink:

Quite smooth, but I have very little outside of the default packages installed, so this is not saying too much…

1 Like

Omnia - Foris - HBL

## Remote Exception: Internal error 'en'('<class 'KeyError'>')

### Remote request

{"module": "router_notifications", "action": "list", "kind": "request", "data": {"lang": "en"}}

### Stack trace

Traceback (most recent call last): File "/message_router.py", line 117, in process_message File "/module_base.py", line 61, in perform_action File "/__init__.py", line 37, in action_list File "/utils.py", line 113, in inner File "/openwrt.py", line 64, in list KeyError: 'en'

Hi @viktor,

In our documentation How to try future releases of Turris OS and also in switch-branch utility, you can see that you are using branch Here be Lions. It is suggested for experienced users as from to time, there might be occasional bugs, but you should be able to recover from it. I think you are watching changes and bug reports on our Gitlab and you know that the fixes for empty notifications are on review. If anything happens, we need detailed bug reports, which is reported by proper way.


Next time, I’d like to suggest you follow, what you can find in unexpected error from Foris.

An unexpected error has occurred

We are sorry, but your request raised an unexpected error. More information about this error may be found below.

If you are willing to help us with fixing of the problem, download the following error protocol and send it to us with a short description of the steps that led to the error to our email address tech.support@turris.cz (the protocol contains only a copy of the following informations).

There are no environment details in your post and there is just stack trace. We would appreciate more details about it. How we can reproduce it, how it happened? Did you go to some tab?

Default configuration, error after login to Foris (tab independent), reForis works. Error protocol via PM.

There’s an e-mail address, where it should be reported. You shouldn’t use PM.

And reports from other users via forum are allowed?

I have Foris error right after login (HBL). I have sent error log to tech support.

1 Like

And nobody will answer.

I am not aware that anyone else is just posting links/outputs without providing any word. Forum is not a bug tracker. In unexpected errors from web interface Foris, there are instructions that needs to be followed. If you have enough knowledge, you can report bugs to us directly on our Gitlab.

Thanks!

It seems to me that you are sure about it. We don’t provide support for 24/7. You can not expect reply from us two hours before midnight or after midnight and I’m sure that my colleagues will reply to the bug report as soon as possible.

Meanwhile in other thread. Let the honorable reader assessing.

They answered via e-mail.

2 Likes

Solved after last update (and restart).