OK -- I'm sure it's been done but, what is the procedure to UPGRADE active ZeroTier on Linux

I’m sure everyone else has figured it out but… I’ve got a running Zerotier 1.4.6 node on Linux nodes. How do I upgrade to 1.6? I could certainly remove the code and do a fresh install, but there must be some means to do an inplace upgrade right?

I used sudo apt upgrade zerotier-one

and that worked for me. I am on 1.6.0 now, but something seems to be broken, for me at least. zerotier-cli now gives me a ‘Segmentation fault’ any time I call it.

@wolf_0xff Do you have AppArmor or SELinux enabled/enforcing by any chance?

@zt-grant: It looks like it. I wasn’t even aware of that. Pop_OS seem to have that installed/enabled by default.
‘sudo apparmor_status’ returns me this:
apparmor module is loaded.
32 profiles are loaded.
30 profiles are in enforce mode.

I can provide more details on the profiles if needed.

Just for fun, can you try disabling AppArmor and see if that solves the segfault by any chance? If so, it’ll give me a better hint on where to look.

Sorry Grant, I’m not a Linux guru and this laptop is just two months in my possession and really don’t want to mess with boot procedures just yet. I rather not touch that. But I will try to bring up a VM, using Pop_OS as client and fiddle with that. I will do that this evening, I’m at work right now. I’ll get back to you.

No worries. Just got a Pop OS 20.04 VM installed. Unfortunately, I’m not seeing the same behavior. Anything else special about your install? Running inside LXC perhaps? (There’s another known issue there that’s on the list to take care of)

Nope, I installed zerotier-one on the native OS, no containers.

Ok. Just asking to see if it was the same issue as a different one that we’d already discovered.

Also, disabling app armor temporarily is a pretty easy process.

sudo systemctl disable apparmor

Then reboot.

To re-enable:

sudo systemctl enable apparmor

And reboot again.

If you could try this tonight once you’re off work it would be much appreciated! If you’re still getting the segfault with apparmor disabled then we’ll at least know what it’s not and strike that off the list.

I wasn’t aware of that. A quick google search told me that the boot record had to be modified. If it’s as easy as disabling via systemctl, I will sure do that for you when I get a spare moment, latest this evening.

@zt-grant, I spend my lunch time to look into this, because I find it interesting. Here is what I found:

You didn’t know that I had rolled back to zt 1.4.6 after I found 1.6.0 not working for me. So, to run your suggested test, I had to upgrade to 1.6.0 again which I tried the ‘normal’ way via the package manager (sudo apt upgrade zerotier-one). The upgrade seemed to be successful, but instead of showing the segfault, it now showed still the previous version (1.4.6).
I decided to compile the version 1.6.0 from source code and installed that. After installation, I expected to see the segfault coming up, but to my surprise a ‘zerotier-cli -v’ show’s me now version 1.6.0 !
Nice, seems to work now.
I inspected the upgrade console output in more detail and noticed that the package ‘apparmor’ did get messed with. Could that be the reason for the segfault during my 1st attempt?
I’m not an expert on this and you might get some inside if you look at all the console output during my tests. I don’t want to flood the forum with all this (about 170 lines), but if you’re interested I can send all this to you via mail or upload it to some place where you can get it from.
Let me know.

Hmm… well the apt upgrade route should have worked. Might have needed to issue a sudo systemctl restart zerotier-one for it to fully take effect.

With what I’m seeing thus far, compiling directly on the system should indeed result in a fully working binary. The issue we’ve located thus far has to do with our build process.

I tried several times to restart/stop/start:

wolf@s76w:~$ zerotier-cli -v
1.4.6
wolf@s76w:~$ sudo systemctl restart zerotier-one
wolf@s76w:~$ zerotier-cli -v
1.4.6
wolf@s76w:~$ sudo systemctl stop zerotier-one
wolf@s76w:~$ sudo apt upgrade zerotier-one
Reading package lists… Done
Building dependency tree
Reading state information… Done
zerotier-one is already the newest version (1.6.0).
Calculating upgrade… Done
The following packages were automatically installed and are no longer required:

0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.
wolf@s76w:~$ zerotier-cli -v
1.4.6

Here are a few lines related to the apparmor package:
Preparing to unpack …/libapparmor1_2.13.3-7ubuntu5.1_i386.deb …
Unpacking libapparmor1:i386 (2.13.3-7ubuntu5.1) …

1 Like

I’m having very similar results in that I can’t upgrade 1.4.6 at all

1 Like

Exact same problem on the exact same version 1.4.6. Can’t upgrade via apt Maybe there was a problem with my install procedure?

Same here, can’t upgrade from 1.4.6.

Had to first uninstall with: sudo apt remove zerotier-one
Then do a fresh install. Now I am on 1.8.4 :slight_smile: