Linux TBB should better detect wrong 32-bit vs 64-bit choice
I ran the 686 TBB (1.1.14-dev) on my 64-bit wheezy/sid, and got
arma@last-request:/tmp/tor-browser_en-US$ ./start-tor-browser
Launching Tor Browser Bundle for Linux in /tmp/tor-browser_en-US
./App/vidalia: error while loading shared libraries: libXext.so.6: cannot open shared object file: No such file or directory
Vidalia exited abnormally. Exit code: 127It seems we should do some sort of detection if somebody has picked the wrong arch, and tell them that rather than a cryptic lib failure?
(A short-term bandaid might be to add a "Are you sure you're not on a 64-bit platform?" hint when Vidalia exits abnormally.)
Activity
Replying to arma:
I ran the 686 TBB (1.1.14-dev) on my 64-bit wheezy/sid, and got {{{ arma@last-request:/tmp/tor-browser_en-US$ ./start-tor-browser
Launching Tor Browser Bundle for Linux in /tmp/tor-browser_en-US ./App/vidalia: error while loading shared libraries: libXext.so.6: cannot open shared object file: No such file or directory Vidalia exited abnormally. Exit code: 127 }}}
It seems we should do some sort of detection if somebody has picked the wrong arch, and tell them that rather than a cryptic lib failure?
The easy way to do this is to:
- ship two copies of a tiny C program, one compiled for IA-32 and the other for AMD64, which simply
dlopens a shared library name specified on the command line and returns an exit code indicating success or failure; - ship a complete list of the libraries that each architecture's TBB requires;
- in the launcher script, check whether the shared library test-loader for its bundle's architecture can load its bundle's required libraries;
- if the required libraries are not available, check whether the shared library test-loader for the other architecture can load (more of) that architecture's required libraries, and if so, tell the user to try the other TBB;
- otherwise, complain to the user that TBB needs some libraries installed, and list them.
The even easier way to do this is to check the output of
uname -m, but that would do the wrong thing on a system with a 64-bit kernel and 32-bit userland.- ship two copies of a tiny C program, one compiled for IA-32 and the other for AMD64, which simply
See the attached screenshot for what happens if someone tries to run the 64-bit TBB on 32-bit Linux. Someone reported possibly similar misbehaviour (it appeared that the shell was trying to interpret
App/vidaliaas a shell script) with an older version of TBB in #tor once, and we had no clue what the problem was.TBB 32bit with Pyobfsproxy fails even "worse". Tor and Vidalia start, but it cannot bootstrap:
[...] Mar 17 01:15:43.182 [Warning] The communication stream of managed proxy './App/pyobfsproxy' is 'closed'. Most probably the managed proxy stopped running. This might be a bug of the managed proxy, a bug of Tor, or a misconfiguration. Please enable logging on your managed proxy and check the logs for errors. Mar 17 01:15:43.183 [Notice] Failed to terminate process with PID '5854' ('No such process'). Mar 17 01:15:44.190 [Notice] Bootstrapped 5%: Connecting to directory server. Mar 17 01:15:44.191 [Warning] We were supposed to connect to bridge 'xxx.xxx.xxx.xxx:yyyy' using pluggable transport 'obfs2', but we can't find a pluggable transport proxy supporting 'obfs2'. This can happen if you haven't provided a ClientTransportPlugin line, or if your pluggable transport proxy stopped running. [...]
I think erinn's strategy, of a little bash stuff to look at uname, would be way better than the nothing we have now. I think if we wait for rransom's "easy way", we'll be waiting a while more, and we'll probably get it wrong the first time.
This looks like a great ticket to get some volunteer help on.
"Be careful, in a chrooted 32-bit env, the uname is still answering like the 64-bit host system. getconf LONG_BIT works fine."
% diff 3841/start-tor-browser original/start-tor-browser 119,126d118 < SYSARCHITECTURE=$(getconf LONG_BIT) < TORARCHITECTURE=$(expr "$(file App/tor)" : '.*ELF \([[:digit:]]*\)') < < if [ $SYSARCHITECTURE -ne $TORARCHITECTURE ]; then < complain "Wrong architecture? 32-bit vs. 64-bit." < exit 1 < fi <"works for me"
"getconf LONG-BIT" is supported on MacOS, too. the "file" output is obviously different though.
Should I open new tickets (and patches) for the MacOS and the Windows launcher?
Trac:
Status: new to needs_revisionThe patch is the diff in https://trac.torproject.org/projects/tor/ticket/3841#comment:7 . I will attach it as git patch now for your convenience. Feel free to pick a better error message.
mentioned in issue #9563 (closed)
mentioned in issue #10049 (closed)
