Turris OS: Which branch/tag to check out to get current stable release?

Which branch or tag would I have to check out of the Turris OS repository to get the current stable release (deploy branch as running on my router) and how would I find that information myself.

I tried tag v3.9.3 but ended up with a slightly different kernel version (4.4.110-a0482dbd2b5f7e2ee0ce33a570fef03d-0 instead of 4.4.110-1e4a549d177ab3da12b2052fba6a4dd5-0 running on my Omnia). Would deploy-2017-01-12 or, more generally, the latest deploy-XXX tag correspond to the current stable release?

It corresponds. You ended up with just different magic number of kernel not with different version of kernel per say.

The correct one is exact version. As you can see latest deploy-* is from beginning of last year. We switched from dates to exact versions around a year ago.

You can also use git-hash file on repo.turris.cz. That file contains exact hash of commit used.

1 Like

Thanks! Having just received my Omnia three days ago I wasn’t aware from when the last stable version dated.

EDIT And I read 01-12 as December 1st, so not being familiar with the release cycle that seemed at least possible for me… :blush:

Is there a way to force the magic number to be the same as in release? Otherwise, kmod packages give dependency errors when I try to install them.

Magic number is basically hash of kernel options and is there to make sure you don’t mix modules that might depend on feature that is disabled in kernel you are running - to prevent you from running into dependency errors :slight_smile: It can be changed but you would have to edit some makefiles that are actually producing it.

2 Likes

I see, thanks for the clarification. That basically means I can’t use the Turris OS/OpenWRT build system to build opkg’s of additional modules for the current release kernel, at least not without modifying the opkg’s, right?

Yes you can build additional modules but you have to use precompiled sdk not the one you compile your self. In that case you can compile any additional modules. But if you need change in kernel it self (enable/disable some option) then you are out of luck. Magic number is there right because you shouldn’t be doing that.

Correct solution for doing changes to kernel is to recompile whole kernel and all kmods and completely use your own version instead of ours. Of course in such case we provide no support, you are on your own.

1 Like

Thank you, where would I find that and is this documented somewhere? A way to compile additional modules while maintaining the kernel configuration is exactly what I’m looking for, so this sounds like good news indeed.

No it’s not documented unfortunately. At least not by us. I have some documentation on way but only for common packages (not specifically for kmods) but it’s way away from publishing.

Anyway you can found precompiled sdk here: https://repo.turris.cz/omnia/
And you might found some information on OpenWRT wiki or I have some piece of code here that uses it: https://git.cynerd.cz/turris-myrepo/tree/build_repo.sh

1 Like