Skip to content

Obsolete software

kwrodarmer edited this page Nov 2, 2018 · 1 revision

I'm getting this error

If you are here, you may be getting a response from your software such as

2018-11-02T10:11:19 prefetch.2.3.5 err: error unexpected while resolving tree within virtual file system module -
 failed to resolve accession 'SRR123456' - Obsolete software. See https://github.com/ncbi/sra-tools/wiki ( 406 )

Redirected!!!

2018-11-02T10:11:20 prefetch.2.3.5 err: name incorrect while evaluating path within network system module -
 Scheme is 'https'
2018-11-02T10:11:20 prefetch.2.3.5 err: path not found while resolving tree within virtual file system module -
 'SRR123456' cannot be found.

The error actually tells you that you are using old, out-of-date and obsolete software that only speaks HTTP and doesn't support HTTPS which is required for all US Federal servers. The amount of text here can visually overwhelm, so let's deconstruct it to understand what is happening.

First

2018-11-02T10:11:19 prefetch.2.3.5 - all error messages should start with a timestamp of when they occurred, what tool was running, and (importantly) what version of the tool was running. In this case, we see version 2.3.5 that happens to be the most common version we see encountering this error (for reasons to be explained).

Second

error unexpected while resolving tree within virtual file system module - this is a machine translation of a 32-bit error code into a language that vaguely resembles English without the benefit of a working grammar. With a little effort, we can discern that there was an unexpected error within the file system code, meaning that the tool does not know how to respond to or work around the error, and cannot continue. The exact wording is of great interest to our engineers, who can use it to track down the location of the error without difficulty.

Third

failed to resolve accession 'SRR123456' - the text is clear enough, but many if not most users are unfamiliar with the process that SRA tools use to discover the location of a run just by its accession. The process is quite elaborate, and fundamental to our operation. It should be seen that the accession or run id (which was arbitrarily called SRR123456 here) means absolutely nothing to your file system. Instead, it is used by the underlying database engine VDB to locate the run either wholly in your local file system, partially cached, on some shared file system, or remotely in a networked archive (NCBI's SRA). The point is that our tools have to convert the simple accession into a file system path or URL. See https://github.com/ncbi/ncbi-vdb/wiki/Name-Resolution-Process for greater details.

Fourth

Obsolete software. See https://github.com/ncbi/sra-tools/wiki ( 406 ) - This part gives the clue that your software is no longer operable and points you to this very Wiki for an explanation. That explanation will be repeated here:

ATTENTION:

sra-tools has transitioned to all HTTPS access as of October 7, 2016 with release 2.8.0. It is critically important that you update all of your binaries and your configuration files.

This is in response to OMB memorandum M-15-13 issued on June 8, 2015, requiring all Federal HTTP servers to stop using (simple) HTTP and switch to HTTPS.

Please update your software as soon possible to give some time to ensure continued operation.

The 406 in parenthesis is a response code from our HTTP server which may not be obvious to our users, but means

Not acceptable!

Fifth

Redirected!!!, etc. - at this point, the tool has been redirected from an HTTP scheme URL to an HTTPS scheme. The old VDB then complains that it does not support HTTPS, after which the old tool then complains that it can't open the run, and finally exits.

The Most Common Cause and Remedy

We see this error most often with release 2.3.5 of the toolkit from years ago, on Ubuntu or Debian systems. This is because for a while there was a team that was associated with Debian that was building our software and packaging it as DEB files to support installation via apt. After version 2.3.5, they stopped building our packages, but they remain available and many people (naturally) try to get their tools via this mechanism. As a result, Ubuntu users who installed bio-informatics packages using apt will be stuck in time with regard to the SRA Toolkit.

The remedy is to uninstall the old SRA Toolkit tools from your system and download the latest tools from https://github.com/ncbi/sra-tools/wiki/Downloads .

Why do you use tar instead of proper packages?

We've toyed with the idea for years, but there are a few characteristics of our code that complicate the issue.

  1. almost all of our customers lack admin privileges for a proper host installation
  2. it's a major effort to build and test packages for all of the major distros in all of their myriad flavors
  3. asking the major distros to build the packages themselves is difficult because the SRA itself requires frequent code updates and unusually fresh software to guarantee access to all of its contents.
  4. by now our customers have grown accustomed to gzipped tar files (or zip files on Windows) for better or for worse.

Our tools are designed under the assumption that they will have to operate without a formal installation process and operate out of users' home directories, in many cases.

So that's it - uninstall 2.3.5 and install the latest tools, add them to your $PATH as desired, and you should be good to go.