@tonyquan Thanks for the tipp. I tried and the error in „Sentinel“ - „License Agreement“ disappeared but still persists in „Region and Time“ in „Administration“.
lxc broken by update here as well - but make sure you don’t depend on it like I did (remote upgrade via ssh tunnel running in lxc)
container restart fixes it though
ah! thxs! the only thing i noticed that the syslog is full of the rainbow crond.d clutter…so that is apperantly reset…
Solution is to go to /etc/cron.d/rainbow and modify the update freq with a txt editor, ( i explain this for nOObs like myself ) to this :
MAILTO=""
-
-
- 8 * root /usr/bin/rainbow_button_sync.sh
-
ah, and this update solved the endless phyton HAAS errors… Nice!
You are adding content to the file (/etc/ssl/certs/ca-certificates.crt), which is not marked as the configuration file. It is provided by package ca-bundle. When the file is not marked as the configuration file, it will be overwritten by each package update. Also, this file can not be marked as a configuration file. If you make any changes to do it once it is marked, then your modified version stays there, and you will not have renewed and new certificates, but in the file with suffix -opkg.
Live example from some different package:
* resolve_conffiles: Existing conffile /etc/config/tor is different from the conffile in the new package. The new conffile will be placed at /etc/config/tor-opkg.
Not many users will take a look at the previous file and add new rows into new files, but the system administrator of the router is responsible for taking a look at applying those changes if he manually edited the file to ensure that it works with a new version.
TL;DR: This is not our fault, and there is not much to do on our end. You should create a new file instead of appending the existing file (in this case: system certificates; dangerous itself for most users) and include the new file from config.
Many software developers avoids doing compatibility changes in fixup/minor releases and if they do, Many software developers avoid doing compatibility changes in fixup/minor releases, and if they do, they try to communicate it as much as possible. Even if you don’t bump the version, the syslog-ng runs in compatibility mode.
[2021-11-05T09:50:55.278697] WARNING: Configuration file format is too old, syslog-ng is running in compatibility mode. Please update it to use the syslog-ng 3.34 format at your time of convenience. To upgrade the configuration, please review the warnings about incompatible changes printed by syslog-ng, and once completed change the @version header at the top of the configuration file; config-version='3.31'
So, I think there is a different issue. Perhaps in the custom config file, but I can only guess what is happening in this case without providing details.
Hey, thanks for letting us know. This seems to be related to the Turris MOX router, those not successful reboots. May I know which version of our SW workaround are you using? I should mention that those are still happening in the known bugs list as I did in some past release announcements threads.
Could you please reach our technical support department? They will be able to gather as many details as possible to reproduce it on our end to see what is happening. Also, you can send them details with your configuration. It would be good to know if:
- we know if the time was correctly set
- you said that the Internet connection does not work.
Did you mean DNS resolving? Did you try to ping some IP addresses? Was unbound (in case of Turris 1.x) running?
Hello @DannyPM,
I will take it from the other side. How did you manage to install the package tcpdump-mini? I can see that the package - tcpdump by default has been provided for a long time, so this is not a regression in this update. I could not install the mini variant. Well, I can, but I need to try harder. 
See my output:
root@turris:~# opkg update
root@turris:~# opkg install tcpdump-mini
Installing tcpdump-mini (4.9.3-2) to root...
Downloading https://repo.turris.cz/hbs/omnia/packages/base/tcpdump-mini_4.9.3-2_arm_cortex-a9_vfpv3-d16.ipk
Collected errors:
* check_data_file_clashes: Package tcpdump-mini wants to install file /usr/sbin/tcpdump
But that file is already provided by package * tcpdump
* opkg_install_cmd: Cannot install package tcpdump-mini.
root@turris:~# opkg remove tcpdump
Removing package tcpdump from root...
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.
Well, if you don’t need to use the minimal variant explicitly, I suggest removing it and using the full-featured variant.
1 Like
I was not sure, thus checked on forum: it was version 4 of workaround, as @hagrid wrote in his comment on topic Turris OS 5.2.6 is now in the Testing branch
and I tested and answered to it
Neither version 4 of workaround for MOX boot problem was successful (at least for me) - sw reboots (via CLI) mostly hang, hard reboots via power off/on are mostly OK.
hi there, the MOX classic here does not want to update.
Updater failed:
inconsistent: Requested package sentinel-nikola-src that is not available.
and
Nov 5 10:31:55 turrisMOX updater[11741]: repository.lua.lua:58 (Globals): Target Turris OS: 5.3.0
Nov 5 10:32:15 turrisMOX updater[11741]: src/pkgupdate/main.c:154 (main):
inconsistent: Requested package sentinel-nikola-src that is not available.
Nov 5 10:32:16 turrisMOX updater-supervisor: pkgupdate exited with: 1
ok, removed that sentinel-nikola-src pakkage, now it is updating
Hi!
Hmm. Package sentinel-nikola and all its related packages, including source files, were removed in this update. It was replaced by sentinel-fwlogs. The solution is to remove the package by running opkg remove sentinel-nikola-src. We are not downloading and installing the source package (thus the src suffix) by default. It is possible that you installed it manually.
1 Like
As good news as it is this new release did not come as smooth as before.
After reboot with 5.3.0 /srv mount point was blank. Which before reboot had about 70% of 1TB btrfs partition occupied.
I had to disable manual option for a mount point to get the content back to be visible.
Where do I find the the settings which are actually used to mount internal SSD drive? If the settings on ‘Mount Points’ are in fact not used?
If your router is still under warranty, please proceed with RMA. If not, I think I might be able to find a way in your case.
When it was bought directly from was on Indiegogo, contact our support department and they will gladly assist you. Otherwise, if it was bought in retail, then proceed through the seller.
Our support department is already notified regarding mounting posts, and we are trying to reproduce it on our end. Thank you for letting us know about this issue. If there is anything new, we will let you know.
2 Likes
nu clue either. Must have done that myself me think. Removed that package, and now it is updating and get the tcpmini warning.
That is used for DNS lookup with adblock… Removed it.
Edit : removed tcp mini, and apperantly adblock DNS report still works, so it seems safe to remove it 
I don’t know if it’s related to the TOS version, the netmeter works properly, but its debug netmeter --debug only reports at the end some error
x
x
x
dl_throughput_mbps = 91.193490
ul_throughput_mbps = 93.396623
Exiting.
uci: Entry not found
uci: Parse error (invalid command) at line 1, byte 0
Your Sync code is: ab7c391xxxxx
root @ Turris_Omnia: ~ #I had some minor issues with this update. I kept getting
Error notifications
===================
Updater failed:
inconsistent: Requested package python3-usb that is not available.
Which, of course it didn’t seem to be available. I was concerned it was used for something which might break if I removed it. Being the wild man that I am I removed it anyway and the update appeared, but I may still try to find out what it was used for or what installed it as a dependency.
I also had to restart collectd by hand even though the router rebooted. I haven’t found anything else yet.
Package netmetr was updated lastly in Turris OS 5.1.4. Thus it is not related to this version. Would it be possible to send us output from uci show netmetr? This will help us to know if the content of /etc/config/netmetr is correct or there is some error, which should not be.
This issue is on me. I was doing a minor cleanup and threw it away. Because no packages depend on this package in our repository. We did not actively maintain it, so I took the opportunity and drop it.
2 Likes
I had exactly the same issue after updating to 5.3.0 and rebooting the device. Unmounting in LuCI didn’t work, reformatting the mSATA drive in reForis didn’t change anything, several reboots of the Omnia didn’t change this.
I solved this by removing the mount point in the “Mount Points” section in LuCI (go to the “Mount Points” page, scroll to “Mount Points”, delete the mount point (e.g., /dev/sda/)). I then rebooted the device, and could access /srv again. Interestingly, formatting the mSATA drive in reForis didn’t work (the web UI said it was formatted, but all the files were still there).
root@Turris_Omnia:~# uci show netmetr
netmetr.settings=settings
netmetr.settings.control_server='control.netmetr.cz'
netmetr.settings.max_history_logs='50'
netmetr.settings.client='HW-PROBE'
netmetr.settings.uuid='5d8b8a67-7ec8-4b45-aecf-xxxxxxxxxxxx'
netmetr.settings.sync_code='hidden'
netmetr.settings.autostart_enabled='0'
netmetr.settings.hours_to_run='4' '10' '16' '22'
root@Turris_Omnia:~#This update was bad luck on Turris 1X. After update WIFI not starting (I have 6 SSID for internet, guest and tor network for both frequencies) broken LXC - containers does not start and after rollback I did not prevented another update so it run out of space on SDCARD and rendered it read only. Now system boot into read only mode bude not sure if SDCARD is completely damaged or just filesystem.
Unfortunatelly I don’t have time this weekend to fiddle with it. New omnia wainting next to turris1x but only hafl of setup on it.