I have also downloaded the .deb files from the location below and tried to upload and install via the APPS tab but the amd64.deb failed with a "architecture mismatch" message,
You must have an arm-based ReadyNAS. What model?
Did you apply the patches need to get apt-get to work? They are changes in
And did you do a apt-get update after making the changes? If you did, did you get any warnings other than the following:
W: GPG error: http://archive.kernel.org/debian-archive/debian jessie-backports InRelease: The following signatures were invalid: KEYEXPIRED 1587841717 KEYEXPIRED 1668891673
W: GPG error: http://archive.kernel.org/debian-archive/debian jessie Release: The following signatures were invalid: KEYEXPIRED 1587841717
Those warnings are why you need the apt.conf entries. If you got other warnings, or worse, errors, then go back and check your entries for typos.
As @tigerten mentioned in his post, 1.8.7 is now the latest that can be installed with firmware 6.9.10 on an Intel system. 1.8.4 is now the latest that can be installed on and ARM system (using the armhf release). They must be manually downloaded and installed locally, after obtaining them from https://download.zerotier.com/RELEASES/ and navigating to the appropriate release, debian, jessie, then downloading the .deb for the appropriate architecture. I tested these on a "fresh" 3220 and a 212 that had 1.6.0 already installed after having just upgraded to 6.10.9 and making the required changes to sources.list (and apt.conf if this is the first time you've made the source change), followed by an apt-get update.
AFAIK, the GUI package install will not work for anything where additional packages need to be updated. So, basically, unless you are re-installing something (same version), it's likely not going to work at all with anything.
Are you on OS 6.10.9, and did you see my most recent post summarizing the sources update thread?
Did you do an apt-get update after you made the changes to the sources? There is no need to re-boot. In fact, doing so does nothing. You must manually do the apt-get update. NOTE: Do not accidently do apt-get upgrade, you'll break stuff. Since on the ReadyNAS we are at the point that the sources will likely never change, it may not matter; but in general, you should always do an apt-get update before any install.
I'm not sure if this is also part of your problem, but for the benefit of all: when doing a local install, you must always preface the file name with ./ if it's in the current directory. Of course, if it's in a different directory, then it doesn't matter. So, the command is apt-get install ./zerotier-one_1.8.7_amd64.deb (for Intel-based NAS).
AFAIK, the GUI package install will not work for anything where additional packages need to be updated. So, basically, unless you are re-installing something (same version), it's likely not going to work at all with anything.
Are you on OS 6.10.9, and did you see my most recent post summarizing the sources update thread?
Did you do an apt-get update after you made the changes to the sources? There is no need to re-boot. In fact, doing so does nothing. You must manually do the apt-get update. NOTE: Do not accidently do apt-get upgrade, you'll break stuff. Since on the ReadyNAS we are at the point that the sources will likely never change, it may not matter; but in general, you should always do an apt-get update before any install.
I'm not sure if this is also part of your problem, but for the benefit of all: when doing a local install, you must always preface the file name with ./ if it's in the current directory. Of course, if it's in a different directory, then it doesn't matter. So, the command is apt-get install ./zerotier-one_1.8.7_amd64.deb (for Intel-based NAS).
Yes, I updated to OS 6.10.9 after making the edits to /etc/apt/sources.list and creating /etc/apt/apt.conf per your instructions (which is why the system rebooted).
I did not run apt-get update before I tried the manual install which failed. Did I need to run that after making your edits? Should I try running that and try manual installing again?
I have seen that, but it's usually because you mistyped the file name or something similar. What it's doing is seeing an entry in /etc/apt/sources.list.d/zerotier.list (which was put there when you installed the old version) for the ZeroTier repository and using it to determine the update, not what you put on the command line. So it's trying to install the latest version, which does have dependency issues on a ReadyNAS. If you are sure you aren't mis-typing the name, try commenting out "deb http://download.zerotier.com/debian/jessie jessie main" in /etc/apt/sources.list.d/zerotier.list by putting a hashtag (#) in front of it, then run apt-get update again and try the install again.
That did seem to work for me, at least after a restart. I still get Note, selecting 'zerotier-one' instead of './zerotier-one_1.8.7_amd64.deb', but it says that's the latest, so it's not looking at the repository. If it was looking at the repository, it would try to install 1.10.6, which would fail due to dependencies.
If that doesn't work, I think this should, but I can't test it 100% because I don't have another ReadyNAS that currently needs an update. But when I try to re-install the same version over itself, it behaves the same as with the repository commented out.
Anyway, create /etc/apt/preferences.d/zerotier with the following content:
root@mynas:/home/admin# apt-get install ./zerotier-one_1.8.4_armhf.deb Reading package lists... Done Building dependency tree Reading state information... Done Note, selecting 'zerotier-one:armhf' instead of './zerotier-one_1.8.4_armhf.deb' Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation:
The following packages have unmet dependencies: zerotier-one:armhf : Depends: libstdc++6:armhf but it is not going to be installed E: Unable to correct problems, you have held broken packages.
OK, so this is odd. I just downgraded my 212 from 1.8.4 to 1.8.3 and then upgraded back to 1.8.4 and, while it gave me that warning, it did what I asked without needing to do anything else. And apt list libstdc++6 says I only have the armel version, not the armhf one:
root@RN212A:/data/Documents# apt list libstdc++6
Listing... Done
libstdc++6/now 4.9.2-10+deb8u2 armel [installed,local]
It does seem to imply I installed it locally. I may have in my experiments to get the install to work before I discovered all (well, I guess not all) of the "secrets".
And if I try to install anything beyond 1.8.4, it complains about openssl:armhf, not libstdc++6:armhf.
At this point, I just can't be of any more help. The version you have still works, so you can stick with it until someone provides a solution.
I have seen one other possible solution through my Googling, but I'm reluctant to tell you to try it. That's to install the package with dpkg, which doesn't automatically get the dependencies, then fix the dependencies with apt-get install -f. I'm not sure where that will leave you if there are needed dependencies and apt-get doesn't fix them.
root@mynas:/home/admin/tmp# dpkg -i zerotier-one_1.8.4_armhf.deb dpkg: warning: files list file for package 'libclamav9:armel' missing; assuming package has no files currently installed (Reading database ... 20962 files and directories currently installed.) Preparing to unpack zerotier-one_1.8.4_armhf.deb ... Unpacking zerotier-one (1.8.4) over (1.4.0) ... dpkg: dependency problems prevent configuration of zerotier-one: zerotier-one depends on libstdc++6.
dpkg: error processing package zerotier-one (--install): dependency problems - leaving unconfigured Processing triggers for systemd (230-7~bpo8+2.netgear3) ... Errors were encountered while processing: zerotier-one
1.8.4 Web install and cli install behave differently. I don’t know why and how. I had better chance of success with web install. The dependencies it needs during cli install are not required if doing it via the gui.
You may have to reset your system. Or reinstall the OS.
@tigerten wrote: 1.8.4 Web install and cli install behave differently. I don’t know why and how. I had better chance of success with web install. The dependencies it needs during cli install are not required if doing it via the gui.
You may have to reset your system. Or reinstall the OS.
Hmmm, that's odd. 1.8.4 failed for me after a fresh install of OS 6.10.9. I'll try CLI again after running apt-get update. This definitely feels like voodoo...
