Dear Turris users,
we are releasing Turris OS 3.7.5 for all users of Omnia and Turris 1.x. It‘s a small update aimed at making the transit to the soon upcoming Turris OS 3.8 as smooth as possible.
Have a great day!
Nora
Hello,
should we expect some troubles with future updates, if we skip this one?
3.7.1 here, planned update propably 3.8, maybe later 
1 Like
Hi,
it’s not really an issue of skipping this particular update. Generally, if you intentionally stay in one OS version and haven’t turned automatic updates on, problems may arrise when you try to install the updates later. Not having automatic updates turned on is generally not recommended.
Sorry, but I dont understand you, @Nora.
When I factory reset my Turris 1.x router, he has older version TurrisOS (in my NOR memory is 3.6.5 version).
My situation for update to 3.8 is worse then @Jirka 's example.
Can I expect some problems with future updates?
Potentially yes. We can’t ensure smooth update from every version as that would be too time demanding. I know about issues in updater 58.4 that prevents it to update it self with all changes done with userlists in 3.8 Turris OS version. Specifically it’s that before version 58.4.4 it fails with error about missing string definition and before 58.4.7 it resets its own configuration. But that is just a special case of me having it in fresh memory now. But in general there is no way I can check if feature I am using in userlist is not broken on some old version of updater and even if I knew it and fix would be possible, I wouldn’t be probably even considering it for just not making userlists too cluttered.
Don’t understand me wrong, we want to give you ability to do what ever you want but that comes with cost. If you for example disable automatic updates then you have to expect problems, we warn you about it in message I think. If you reflash factory image then we expect you to be able to do the same again. Nothing is perfect and flawless.
Anyway there is a way to fix it most of the times. In case of for example updater failing you can just download new version and update it by hand (opkg-trans -a updater-ng.ipk -a opkg-trans.ipk).
Also I am not saying that we are bailing out on all old versions, there are just some more supported versions and less supported ones. I am testing userlists with following setup: https://gitlab.labs.nic.cz/turris/userlist-checker/tree/master. But as you can see I am just testing compatibility with chosen versions. Currently that is updater in Turris OS 3.2, 3.7.3 and current deploy on top of the version in target branch.
Also Turris OS fixups are released to fix problems. I can see why you would like to stay away from minor or major update for some time but not updating to fixups is just calling for problems. Fixups contain just security fixes, fixes of major problems (reported after release) and hotfixes to make next version of Turris OS possible.
3 Likes
OK, thank you for your explanation.
Could it be that updater checks itself TurrisOS version? If there are some major problems with specific combination current/updated versions one, it could be that updater first update routers OS to mandatory lower version than actual stable branch (which is tested and doesnt causes conflicts), and after that do another update?
For me reasons are obvious - major updates are enough for me, so 3.6, 3.7, 3.8 (depending on changes, I dont use Foris at all, so…). So far I didnt have problem with that manual updates (I added openvpn one between as I considered it as high important update)
1 Like
Yest it can and it does. See section “Predefined variables” https://turris.pages.labs.nic.cz/updater/docs/language.html
This is kind of sensible idea except that it’s not. Yes it some what ensures that update should work for every version, because we can ensure that downgrade works and in future versions that upgrade from factory version works. But that some what defeats factory version update as every advantage of doing so is lost and new disadvantages are added. For example it prolongs first setup and you won’t bypass errors in factory as you must go trough it.
But that once again expects that we know about versions having those problems. Commonly we don’t and if we do than easier than adding additional pathway that have to be tested and can potentially break is just cut losses and with reasonable expectation let user just update factory image (he did it once so he can do it again).
I guess the idea to start from the existing version and simply iterate over all versions until the most recent seems reasonable, no? The rationale being, if a user that refrained from automatic updates for a time (accidentally or by choice) enables automatic updates again, he/she would probably be happy if that would simply work, maybe with a pop-up informing about the issue and the attempted remedy of iteratively updating. But then instead of informing about the iterated updates, that pop-up could also instruct to do a factory update…
Best Regards
So for better user experience you would drag user trough every bug in every release we did since then? No that’s not a good idea. This is just too big cannon. And we already have too big cannon, it’s called updater-ng and it sometimes breaks. I would rather go with simple but effective huge pile of dynamite. I am for some time dreaming about factory reset that would, instead of flashing it self to primary flash, just prompted user for network configuration and flashed directly the newest root file system. But that is far future project. For time being current state is here to stay. Unless of course there is somebody keen to help me with it.
1 Like
I am somewhat concerned about this. While I do understand that it is not feasible to test every combination, I am currently in the situation where I will have 2 months of the router not being turned, that will in effect be the same as having automatic updates turned off - right?
Will I run into issues if I do not manage to update between 3.7.5 and 3.8?
I do have automatic updates setup, but as the router will be turned off I will have some time before it being setup again.
I don’t think that you have to be concerned. I am just overall cautious and I am openly informing about even potential problems. I am not saying that older versions can’t be updated. I am just explaining that they might not be and that is just because I know that there will be problems if you try to update from 3.7.{0…4} to 3.8. Yes in Turris OS 3.7.{0…3} had updater critical bug causing it to exit with error so those can’t be updated (will be fixed with 3.8.1 and that is because fix is causing router restart during update for every version before 3.8). Updater in version 3.7.4 just had bug that caused in some situations (like one happening during 3.8 update) overwrite of package’s configuration. If you have no additional packages installed on top of userlists than this has no effect for you.
Generally you don’t have to be afraid to powering off you router for some duration of time. True is that prolonged power down is not recommended as security certificates (ex. DNSSEC) can potentially get old but that is let’s say year or more of down time. But these problems have solutions and if you contact us trough support then we can help you fix it in just few steps.
Well, I would prefer that you actually have a valid upgrade path for each point release that is actually tested, but since this can be a lot of work I would accept a fast-forward through all sequential releases up to the current. Now, you say there were bugs in the updater that make that infeasible, and in that case I agree directing users to a manual update to the newest version by re-flashing seems reasonable (assuming the user can save her/his configuration before and re-apply it to the re-flashed router). But the default IMHO should be simply to play catch-up until the current release is reached, if that means temporarily accepting known bugs, so be it, the idea is that this update fast-forward is performed in one go so there should only be a minimal window for these bugs to be exploited (so the router might actually refrain from routing for hosts on the LAN, and only accept ssh/web-gui access from the LAN and use WAN only for downloading the installation packages, you get the idea). By going though the releases in sequence you would leverage all the testing you already do to assure that updates actually will work. On the other hand if non-sequential updates typically just work,and failure can be automatically detected, it might be easier to simply try to update from whatever to the newest version and on failure inform the user and give pointers how to manually do a “factory” update, including instructions how to keep/migrate the configuration. Anyway, this is pretty theoretical on my part, I am a happy omnia user and simply always keep up with the automatic updates (after all that was one of the features that made me go for the omnia in the first place).
Please keep up the good work!
I always wonder whether it would not be nice to allow to initiate factory resets/ medkit reflashes from the running router (maybe requesting to press a button or press sequence, like 3 short 3 long 3 short, to make sure the user requesting a reflash has physical control over the unit). Or have a way for the user to request boot into one of the documented reset modes (https://www.turris.cz/doc/en/howto/omnia_factory_reset) via the GUI. On the other hand the existing method is not to tedious and rarely required, so this seems like a luxury feature to think about once everything else is perfect 
Best Regards