We released Turris OS 5.2.2 yesterday to the testing branch, after one RC version, we released it to you!
What’s has been improved in this release? reForis Added Turris 1.x basic support for Network Interfaces Added support for longer Honeypot as a Service tokens Other changes Updated kernel to version 4.14.236 Updated mac80211 to version 4.19.193-test1 Updated mosquitto to version 1.6.15
Your router will download and apply this update automatically. If you are using approvals or delayed updates, we suggest you check the Updates tab in reForis to proceed with this update.
The announcement leaked sooner on our Social Media than it was planned. But, it is released now and the update will be downloaded and installed ASAP on your router!
Yeah, I had the same suggestion as you in the past, but it would not be very clear for non-experienced users. Even now, it happens that they report to us kernel version or Foris/reForis version as the version of Turris OS.
ah great! indy omnia update went silent and smooth, only no ( reforis ) notification on top with the info it updated…
The MOX ( again ) needed a cold reboot ( dc unplugging ) before it worked again, Both are on auto update.
That mox issue also happened with the 5.2.0, and 5.2.1 update, so there might be a less optimal thingie with that model?
Same for me on my MOX which is on HBT. Mine is set up to self-update and reboot on the following night. This morning the MOX wasn’t working at all and I had to unplug / plug the power supply to get it to boot. Same symptoms as @DIKKEHENK really, also had it with the previous update 5.2.1.
Same as with 5.2.1 - my Omnia 2020 is still on 5.2.0 and the updates aren’t coming in automatically.
If I run opkg update followed by pkgupdate, it shows INFO:Target Turris OS: 5.2.2 as well as a long list of packages set to be updated. But the reforis interface does not show any updates when clicking ‘check updates’.
What could be happening here? What logs would you want to confirm what is happening? The 5.2.0 update did come in automatically, and the router had updated without me having to do anything, but looks like something has changed since.
pkgupdate says:
INFO:Target Turris OS: 5.2.2
line not found
line not found
line not found
line not found
line not found
ERROR:
inconsistent: Requested package python3-tornado that is not available.
opkg update; opkg list-upgradable
shows a huge list of packages.
Well, an update can not proceed as there is a missing package in your case, python3-tornado. Because of that, it can not proceed. This is expected behavior.
The question is why the python3-tornado is not compiled, but I will take a look.
Then the question is that you installed the package yourself, right? Because I’ve just checked it and there are no Turris packages, which depends on this package.
In the meantime, it would help if you let us know if this is Turris Omnia or Turris MOX and also, you can also remove the package if you don’t need it, so update can proceed or you can use localrepo.
//EDIT: python3-tornado package was removed as it was added in the past, and there are no dependencies related to it.
If you insist on this package, I suggest upstreaming it to OpenWrt packages feed. Currently, I don’t have any plans to submit it there because I am not using this package. It is expected that if you send the package to OpenWrt, then you will become a maintainer of that package and that you are using it.
When you are not familar with OpenWrt build system, etc then you can install python3-tornado via pip.
After manually removing offending packages: opkg remove python3-tornado opkg remove python3-websocket-server
updates have been restored.
I’ve had this issue before. I think it would be good if TurrisOS would remove packages that are no longer available. Obviously with proper warning…
If it is a resolver or any DNS/DHCP-related service will not be available, and the update will proceed because it is not available and remove them, then we are in a bad situation.
When user-installed something on his/her own, then he needs to sort it out. We can not remove it on our own.
Ubuntu does this and it just works. This doesn’t just work. Here, updates stop working and you have to dig in to find out what’s going on. It effectively breaks without me changing anything. That’s much worse than dropping support for a package and forcibly uninstalling it (with the user’s consent obviously! if the user doesn’t consent, then the whole update should be declined and at least you understand what’s going on)
No, it tells you that the package is not available. We didn’t install it for you in the first place, and we don’t depend on it. Every 4 hours, your router tries to check if there is any update available and install it. If an update can not proceed, notifications in reForis appear, and if you configured it to send it to your email box, it requires your attention to check what’s going on. If you are not sure, then there is technical support available for you.
I am not able to help you more as it seems you will be complaining even if we removed it and forced the update, which is not good as I told you. We can not uninstall packages how we want w/o user interaction when he installed it himself. Then we would be in the situation how you called in it was the word beginning with the letter f.
If we are talking about Ubuntu, if you installed something on your own, it tells you that these packages will be removed and if you agree on it. First, you need to be the administrator of your system to be able to install packages, and in the same way, you need to be an administrator to be able to remove packages. This is basically what we are doing. We say that the package is not available and we let you choose what you need to do. Keep it by using localrepo, as I said or you can remove it yourself.
Ubuntu just says that these packages are no longer available and you need to agree it and install it afterward if you need them. I am not saying that you could end up in bad situation, but you can.
I am not here to complain. Just trying to improve TurrisOS. It’s just an observation that updates break quite frequently and they seldom do on linux. Even on OpenBSD that does have issues like this, because pkg on OpenBSD is much more like opkg I believe, breakage without any user modification is rare. I am unsure why the python3 packages were installed in the first place. Maybe I did some experimenting 2 years ago, who knows. Everything was working smoothly and then suddenly updates break, apparently because of these completely irrelevant packages that I didn’t even know were installed and/or necessary. That seems undesirable to me. If you disagree, I am not here to argue. I’ll just accept it. No problem.
Added Turris 1.x basic support for Network Interfaces
But, it is released now and the update will be downloaded and installed ASAP on your router!
