Jetson Tk1: Ubuntu 14.04 - non working packages and applications

Ubuntu 14.04 offers many software packages, but not all of them work. It might be useful to
create a list of applications which do not work as expected and pass this list to the Ubuntu project.

gnome-sound-recoder 3.4.0 #Applications->Sound & Video->Sound Recorder, Recording does not start - Bug #1347938
audacity #application can’t be started (does not find Mhz in /proc/cpuinfo) - Bug #1347914
compiz-plugins-extra conflicts with compiz-plugins-default #compiz-plugins extra can’t be installed - Bug #1347925
minitube 2.0.1 does not display any video output - Bug #1348042
blender 2.69 (closes with segmentation fault) - Bug #1348045
package pepperflashplugin-nonfree is missing in Ubuntu armhf repo - Bug #1348035
Firefox 31.0 crashes on every save of an element(link,image) from a web page - Bug #1348268
kdbg 2.5.4-1 crashes on start with segfault- Bug #1311893
ddd 3.3.12 shows hourglass on start for ever - Bug #1348936
redeclipse 1.4-5 crashes with SIGBUS on game start - Bug #1349063
eclipse 3.8.1 graphical cursor representation broken in editor window view - Bug #1349084
geany-plugin-debugger 1.23 crashes with segmentation fault when used - Bug #1354747

FATAL: cannot locate cpu MHz in /proc/cpuinfo #general problem with current 3.10.24 kernel, causes
some applications to refuse to start

Hi Peba,
What exactly do you mean by “#Recording does not start” ?
Do you see any error or the recording is blank?
Most likely, you will need to use some amixer settings to enable audio capture though.

Its a known bug and there are for sure more of this bugs:

root@tegra-ubuntu:~# audacity
ALSA lib pcm_dsnoop.c:618:(snd_pcm_dsnoop_open) unable to open slave
ALSA lib pcm_dmix.c:1022:(snd_pcm_dmix_open) unable to open slave
ALSA lib pcm.c:2239:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.rear
ALSA lib pcm.c:2239:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.center_lfe
ALSA lib pcm.c:2239:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.side
bt_audio_service_open: connect() failed: Connection refused (111)
bt_audio_service_open: connect() failed: Connection refused (111)
bt_audio_service_open: connect() failed: Connection refused (111)
bt_audio_service_open: connect() failed: Connection refused (111)
ALSA lib pcm_dmix.c:961:(snd_pcm_dmix_open) The dmix plugin supports only playback stream
ALSA lib pcm_dmix.c:1022:(snd_pcm_dmix_open) unable to open slave
FATAL: cannot locate cpu MHz in /proc/cpuinfo

I found that compiz-plugins-extra conflicts with compiz-plugins-default!

I believe the latest update to Firefox continuously crashes the application.

I have experienced challenges installing Wolfram Mathematica 10 on TK1. Since I don’t have enough space on my eMMC, I thought I’d try installing it on my SD card:

Enter the installation directory, or press ENTER to select


Now installing…


Type the directory path in which the Wolfram Mathematica script(s) will be
created, or press ENTER to select /usr/local/bin:

Installation failed. See /media/ubuntu/32GB/Wolfram/Mathematica/InstallErrors.

A copy of the previous contents of the directory
“/media/ubuntu/32GB/Wolfram/Mathematica” can be found at

//It failed when I used the suggested directory. Then I tried installing it onto the same SD card directory as Mathematica:

Now installing…


Type the directory path in which the Wolfram Mathematica script(s) will be
created, or press ENTER to select /usr/local/bin:


Installation failed. See /media/ubuntu/32GB/Wolfram/Mathematica/InstallErrors.

A copy of the previous contents of the directory
“/media/ubuntu/32GB/Wolfram/Mathematica” can be found at

So the installation failed with the scripts location. If there is a correct way to install these scripts?

Referenced InstallError file:
InstallErrors 4.0 MB!AcMCBbbT!X0bfc_cR4V0qJrNKsi7CNYT0-azYdARGPQqymJIB2A4

I did read a thread of someone else experiencing challenges towards the end of installing Mathematica 6: - apparently libstdc++5 was a required prerequisite.

Mathematica is a commercial application which does not release source code. Thus their software builds for different machine types are the only thing you get…if you need a new cpu architecture, you can’t just rebuild it, wolfram must do this. Since ARMv7 is what Jetson is, and since Mathematica is probably x86 or x86_64, installation will not matter…x86 cannot run on ARMv7.

I could see the possibility that they would release an Android version, but nVidia has stated they have no intent to release Android on Jetson…Jetson itself is a restricted development platform not used for resale.

I assumed Mathematica would run on ARMv7 since it runs on the Raspberry Pi which is ARMv6.

ARMv6 is entirely different. There might be some compatibility options for running older binaries, but otherwise ARMv6 is as different from ARMv7 as is x86_64.

NOTE: There are a lot of ARMv7 architecture CPUs, e.g., ARM Cortex A9 and ARM Cortex A15. Basically a lot of Cortex series. These are the “modern” series a lot of modern devices are built from. The CPUs of older architecture are basically outdated but very useful in lower cost systems. Raspberry Pi in part chose the chip it has because it isn’t really current tech and thus the cost is low. CPUs of the same architecture work together, but when you run alternative architectures it breaks.

How would I determine what binary a source code or program is compatible with? Because I tried to install Mathics as an alternative and got an error.

Generally speaking, documentation is the best place to start. If the software says it works on ARM v7, expect other architectures to fail…architecture is a rather important deal breaker. x86_64 is similar to 32 bit x86, but x86_64 won’t work on x86; i386 code might work on i686 as a subset, but it might not (depends what was done to build the program…and i686 will crash and burn on i386). Sometimes you will get scriptable languages which do not care, but the interpreter for that script works on one architecture.

Reverse engineering what a binary works with could get complicated. Linux uses ELF format, but there is 32 bit and 64 bit; and then there is the instruction set used…ARMv6 and ARMv7 will differ, but unless you program those you probably wouldn’t know that.

You could run readelf on an executable and get information about it. E.G., I have /usr/bin/showfont on my Jetson, and if I cd to /usr/bin/, I can run this:

readelf -a showfont | egrep Tag_

Of great interest is the Tag_CPU_arch “v7”. Even if you have this, your program might use optional features, so Tag_THUMB_ISA_use answering “Thumb-2” could matter. Do the docs say it requires thumb2? Does YOUR cpu have thumb2? Comparison of features required and features provided gets rather long. If it were x86, there were feature additions over time for multimedia extensions…maybe it will run slower with a prior version, maybe it will crash and burn. Reading documentation is the way to go.

If you have the source code, you might be able to simply recompile and have it work.

So I would be looking in the doc folder of a tarball? I’m checking there and with online documentation for Pov-ray and don’t see anything regarding armhf v7. Maybe I’m missing it since I’m relatively new to compiling from source code. I tried anyways and got this error:

Configure POV-Ray version 3.7.0


checking build system type… armv7l-unknown-linux-gnueabi
checking host system type… armv7l-unknown-linux-gnueabi
checking for a BSD-compatible install… /usr/bin/install -c
checking whether build environment is sane… yes
/home/ubuntu/Desktop/povray-3.7-stable/unix/config/missing: Unknown --is-lightweight' option Try /home/ubuntu/Desktop/povray-3.7-stable/unix/config/missing --help’ for more information
configure: WARNING: ‘missing’ script is too old or missing
checking for a thread-safe mkdir -p… /bin/mkdir -p
checking for gawk… no
checking for mawk… mawk
checking whether make sets $(MAKE)… yes
checking whether make supports nested variables… yes
checking whether to enable maintainer-specific portions of Makefiles… no
checking whether $C_INCLUDE_PATH contains the “.” path… no
checking whether $CPLUS_INCLUDE_PATH contains the “.” path… no


checking for gcc… gcc
checking whether the C compiler works… yes
checking for C compiler default output file name… a.out
checking for suffix of executables…
checking whether we are cross compiling… no
checking for suffix of object files… o
checking whether we are using the GNU C compiler… yes
checking whether gcc accepts -g… yes
checking for gcc option to accept ISO C89… none needed
checking whether gcc understands -c and -o together… yes
checking for style of include used by make… GNU
checking dependency style of gcc… gcc3
checking how to run the C preprocessor… gcc -E
checking for grep that handles long lines and -e… /bin/grep
checking for egrep… /bin/grep -E
checking for ANSI C header files… yes
checking for sys/types.h… yes
checking for sys/stat.h… yes
checking for stdlib.h… yes
checking for string.h… yes
checking for memory.h… yes
checking for strings.h… yes
checking for inttypes.h… yes
checking for stdint.h… yes
checking for unistd.h… yes
checking for stdlib.h… (cached) yes
checking for g++… g++
checking whether we are using the GNU C++ compiler… yes
checking whether g++ accepts -g… yes
checking dependency style of g++… gcc3
checking whether the g++ compiler works… yes
checking how to run the C++ preprocessor… g++ -E
checking for C++ compiler vendor… gnu
checking for g++ version… 4.8
checking for ranlib… ranlib


checking whether to link with cygwin DLL… no
checking whether to enable static linking… no
checking for the pthreads library -lpthreads… no
checking whether pthreads work without any flags… no
checking whether pthreads work with -Kthread… no
checking whether pthreads work with -kthread… no
checking for the pthreads library -llthread… no
checking whether pthreads work with -pthread… yes
checking for joinable pthread attribute… PTHREAD_CREATE_JOINABLE
checking if more special flags are required for pthreads… no
checking for boostlib >= 1.37… yes
checking whether the Boost::Thread library is available… yes
checking whether the boost thread library is usable… no
configure: error: in /home/ubuntu/Desktop/povray-3.7-stable': configure: error: cannot link with the boost thread library See config.log’ for more details

Referenced config log:

config.log 41 KB!1ZN0xJKR!OxEfEcEP3lXErGCma2vEdZUC_iNB5DNFS4UEWobobMo

If building from source you have to find all of the dependencies…it isn’t automatic, and install them. Sometimes alternatives are found, e.g., I saw mawk was there but not gawk. Looks like boost library is not optional though, so you can probably use apt to install the boost libraries it requires (it’s a big library, you’ll have to figure out which packages have the parts you need…probably libboost and libboost-dev to start).

If the code itself is portable, and the configuration and build system is flexible, you should be able to build after installing missing dependencies. Sometimes code will include platform-specific items which are not portable, e.g., it might contain x86 assembler…in which case you’d have to be a programmer and make a version for your architecture, and then compile it. It’s called porting to a new platform…if you have dependencies and still can’t build, you then need to get on the developer list of the specific software, e.g., find the povray developers email list.

So anywhere it says “no” I need to install that package?

Povray seems to be available in the Archlinux ARM Distribution for armv7:

You could try to just copy the hole thing.

Or you could talk with the developer who is bringing Archlinux to the Jetson Tk1:

Yes, I got pov-ray to work. yay

I realised that many kernel modules are missing or not compiled in.
For example I attached a parallel port mini PCIe (full size but it fits well) with a
Moschip MCS9901. It seems to be recogized properly but I believe parport_pc and lp are missing.
Can this be confirmed and corrected?

Desktop distributions often throw in just about every module…they don’t care so much about space used by a useless feature. Embedded systems use only what the basic install needs…there are few expansion possibilities, and disk space is at a premium. It isn’t something to correct in the distribution, it is a personal tweak.

Simply compile the kernel/modules…linux provides for this. Just download the kernel source:
…check out the kernel compile threads, make oldconfig, then use make menuconfig at the kernel directory to find and enable your camera.

I did notice CONFIG_PARPORT is available if built, but it is in the firmware section…meaning you might need to install a firmware package before compile. I’m not sure which lp you refer to, lots of features with “lp” in them. This is the hard part…finding out what you need, and if you need something from the outside, where to get it. Perhaps a web search on linux support for your camera will show what is needed.

I want to access an oldish EPROM burner. USB-Parport adapters in general fail as either their timing is bad, or some lines are not controlled properly. I think its timing. This is a known issues for ALL usb-parport dongles. Not even all usb-serial work for hardware relying on certain timings.
I managed to compile relevant modules (parport_pc, lp, ppdev) and I think it worked (cant get to run the drivers for other reasons).
Compiling modules via make menuconfig etc. worked well though!
(only draw back it compiled them for 3.10.24 (I think) instead of 3.10.24-g6…

If you are affected by the Ubuntu 14.04 bug reports I wrote and your are a launchpad member please do
the following:

-visit the bug’s web page and note that you are also affected by this bug(s)
-> click with mouse on “This bug affects you”

This will help to get the bug analysed and resolved. If only one user is affected by a bug
the Ubuntu guys might not think about repairing this bug.