Try clearing your browser cache. It happened to me after the update to 5.3.0 and I got the advice to do so here in the forum. It worked fine!
I don’t see a tag for this new version in Turris / Turris OS / Turris Build · GitLab
Sorry! I’ve just pushed the tags.
Mox A+D updared from 5.3 everything ok.
No reboot needed
Thank you team!
EDIT: This note is not related to testing branch, but unfortunately for the stable one.
as after most of updates, i have problem with re-connection of the two Turrises again.
The Omnia which is openvpn server and sits in my flat seems to be ok in current particular case, I can connect to it from my windows PC at work and even from my android phone.
But the Mox, which is unfortunately 40 km away, didn’t reconnect and I have no information what went wrong.
Unfortunately there is only mobile network connection, so as the vpn is dead I’m unable to do anything about it, but get in the car and drive. I am also ill at the time, so it’s much more complicated (!@#$%^&*!!!).
I know you can’t do anything for me right now, but please, try to improve the update&restart process for the upcoming future.
Thank you very much.
Update from 5.2.7 did not go smoothly on IGG Omnia with NAS.
After 3 approvals, one unexpected restart and one expected, the device is now broken.
My /srv is gone. Well, shit.
On top of that Transmission webapp now asks for basic auth password, and does not load. I used to have 2 transmission apps there, now there’s only one - the broken one.
I’m fairly sure that the new kernel is the culprit. Before that everything worked just fine.
Edit: so here’s my setup: 1 HDD - that hosts samba and is mounted via fstab using UUID mounted to /mnt/sda, 1 SSD - that is a Foris storage drive (no Raid), mounted to /srv
After removing the UUID mount for the HDD from fstab, /srv is now up.
This has worked before @Pepe…
I am thinking that this does not have anything to do with our update process. It could be related to our HW specific issue for rebooting on Turris MOX device. May I know if unplugging and plugging back power cord helps? If yes, then you can reach our technical support department and they will provide you workaround, which could help with reboots, but unfortunately, it does not it solve completely or try to help you as much as they can. In the meantime, we are still working with SoC manufacturer, in this case Marvell, to investigate and try to fix it.
We are sorry for any inconvience caused by this. I understand that this could be quite annoying , but thanks for letting us know.
Would it be possible to open a web developer console in your browser and see if there is some stack trace from the backend? It could be helpful. I appreciate your cooperation.
This should be fixed in this update, but it seems it is not. Can you please reach our support department? They will gather more details, reproduce it once again, and pass it to the responsible developer to fix it.
Unfortunately, I can’t go there until Tuesday afternoon.
I will try to prepare for the firmware flash, but I hope pleadingly, that at the time at which I’ll go back home, it will be running and not bricked.
I have plan B also. There is PLC for home automation, i will try to connect the power supply via relay and program it to cycle the Mox, when the network is unavailable, but there is also a risk of creating endless reboot loop.
Any ideas what could have caused the tun_turris device entering and leaving promisc mode every second? I haven’t seen any relevant package updated in this update…
Got some weird stuff in logs, too:
sentinel-dynfw-client: ipset v7.3: Error in line 1: Element cannot be deleted from the set: it’s not added
Nov 27 17:57:17 turris sentinel-dynfw-client: 2021-11-27 18:57:17,184 - WARNING - Error running ipset command: return code 1.
Nov 27 17:58:52 turris haas-proxy-start: 2021-11-27T18:58:52 CRITICAL twisted ‘channel open failed, direct-tcpip is not allowed’
With both errors/warnings, there is nothing wrong. It works. That’s important.
You can verify new sessions on HaaS and by running command:
ipset list for DynFW
Everything went fine for me, I have an omnia and a mox. The mox needed a reset by unplugging and plugging it back in though.
MOX A(SDIO), simple AP-configuration (disabled firewall, dnsmasq and odhcp). Update went without problems from 5.3 to 5.3.1, but reboot failed. I had one more time to un- and replug the powerplug.
When will this problem finally be solved by Turris team?
edit/remark: normal reboots work really smooth - but the critical ones have been and continue to be the ones from updates. Without this working automatical updates cannot be activated without update approvals…
I have had the same issue. The reboot after update failed in my Mox classic, similar to the updates before. I have applied the patch, v4. But it does not help for reboot after upgrade. The reboot otherwise works fine.
Does it affect all Moxes, or only a particular batch? Can one fix it by single part replacement? My Mox is not covered by warranty anymore, I bought it in Indiegogo campaign.
I own one MOX from Indiegogo (came with TOS v4.0b preinstalled) and one bought ~2 weeks ago (yet delivered with TOS v.4.0, so I believe there has only 1-2 batches been produced after Indiegogo campaign).
Both behave just alike, so I think there has not been any hardware revision.
i still get the shadow updates - although I updated last week today I got a
Update notifications ==================== Your approval is required to apply pending updates. You can grant it in the Foris administrative interface in the 'Updater' menu. • Install kmod-nls-base 4.14.254-1-0aa8592c358fc69d822976d971570430 • Install kmod-usb-core 4.14.254-1-0aa8592c358fc69d822976d971570430 • Install kmod-scsi-core 4.14.254-1-0aa8592c358fc69d822976d971570430 ... • Install kmod-ip6-tunnel 4.14.254-1-0aa8592c358fc69d822976d971570430
I downloaded and flashed the experimental firmware and the router was restarted twice, once from console, right after flashing, once from reforis web interface.
No action was needed after any of the particular reboots.
Let’s see after next upgrade …
I think this is related to the issue I brought up:
If you install anything extra using
opkg at least, maybe from LuCI, you will likely get this. But I’ve also gotten it after every update for a while.