Regarding JetPack installation problem: Error: JetPack must be run on x86_64 HOST platform. Detected

Autonomous Machines Jetson & Embedded Systems Jetson TK1
1

Hi guys,

First time poster although being a mild lurker of the forum, I wish to report an issue that has troubled my colleagues and I at work for several weeks with the JetPack version 2.1 and Jetson TK1 board.

We were trying to figure out how to have Vision Works with CUDA 7.5 in a HOST x86_64 machine as it is said that in CUDA 7.5 you could work both with Jetson TK1 and TX1 boards, but after several installations trying to solve dependencies with cuDDn, CUDA 7.5 and Vision Works packages (extracted from the JetPack 2.0 _install/jetson.download folder), we gave up on the idea and switched to install either JetPack 2.0 or JetPack 2.1 in Ubuntu Mate 14.04 (unofficial flavour of Ubuntu 14.04 yet supported by the Mate project, as the official flavour of Mate is supported in Ubuntu 15.04 which is not officially supported by JetPack versions).

Therefore, after reading the terminal messages, we saw that Ubuntu Mate 14.04 doesn’t have xterm natively -terminal which nVidia JetPack uses to install its programs/packages once downloaded (please, could you add this tip in your plain text installation guide?). Then we installed xterm, and JetPack 2.0 was installed without any additional effort BUT JetPack 2.1 was returning launch after launch “Error: JetPack must be run on x86_64 HOST platform. Detected platform.”.

Hence, we searched through the forums suggesting tips as executing:

sudo ./JetPack-L4T-2.1-linux-x64.run --noexec

in order to extract the JetPack 2.1 files and then, on EdwardZhou’s suggestion, entering in the newly created folder _installation/ and executing:

./start_up.sh

…but the message “Error: JetPack must be run on x86_64 HOST platform. Detected platform.” was again reaching our displays but in one system with a relatively old installation of Ubuntu 14.04. Then we wondered what was going on with JetPacks, trying to figure out if it would be related with the USB installation and more what-ifs.

However, we decided to make a leap of faith and try JetPack 2.1 in a fresh Ubuntu 14.04.04 installation…with similar consequences, but still, did not give in. So we extracted the installation files of the JetPack 2.1 with the --noexec option and looked at the files that were extracted. In these files there is a Launcher, which will execute properly BUT don’t proceed with the installation of the packages once they were downloaded…so we were cornering the problem bit by bit (no pun intended).

Culprit: we decided to take a look at start_up.sh and, please, read the first lines of if:

arch=`lscpu | grep Architecture | awk '{ printf \$2 }'`

What if you have natively installed Ubuntu in another language which is not English (i.e. Spanish)? That when executing the instruction lscpu on a terminal you will find this output (notice that Architecture in Spanish is ‘Arquitectura’):

Arquitectura:          x86_64

Patch: as you MUST have English as your native installation language (although you can change the language that is used in your keyboard and display later on, for non-English users), you MUST change it (how to do it, over here, thanks in advance!):

  1. Verify/install English language package in your machine
sudo apt-get install language-pack-en
  1. Go to /etc/default/locale with super-user privileges with your favourite text editor, i.e, nano
sudo nano /etc/default/locale

and whichever the language you have in this file i.e. LANG=“es_ES.UTF-8” for Spanish, you have to insert your favourite English language. In this case, we will use i.e. British English. Remember to put the ‘#’ character before the line you want to comment and then, render it ineffective to the OS.

#LANG="es_ES.UTF-8"
LANG="en_GB.UTF-8"
  1. Restart your machine and launch JetPack 2.1 as specified by the nVidia installation instructions
sudo ./JetPack-L4T-2.1-linux-x64.run

…et voilà! it nicely worked out :D

Solution: please, whoever is in charge of the JetPack and VisionWorks project, please, change the first instruction to uname -i to verify that the architecture of the installation is x86_64. Some proof of this statement is found in uname --help

-i, --hardware-platform  print the hardware platform or "unknown"

Also, I haven’t checked neither tried to modify the file start_up.sh with this solution as I cannot foresee neither have the original code of the Launcher file or the rest of the packages that are uncompressed on the _installation folder, as I won’t spend more time trying to solve probably broken dependencies, etc.

Hope I have been helpful and please, nVidia, professional devs will be glad to have a trusted and tested dev tools without having troublesome-but-stupid errors like this, hence doubting on recommending VisionWorks and your embedded chips TK1 and TX1 for embedded projects because of these issues.

Kindly,
Yueh.

2

I like the patch, but thought of something less complicated and more reliable for detecting x86_64. Just pipe lscpu through grep looking only for “x86_64”. If the string was empty, it isn’t x86_64; if the string is non-empty, you have x86_64 (and x86_64 is language independent). In that case it won’t matter what language packs are installed. Example (assumes bash syntax):

arch="$(lscpu | grep 'x86_64')";
if [[ !  -z  $arch  ]] && echo "is x86_64";
3

Thanks for your input linuxdev, but as you might see the patch is intended to not to modify nVidia’s original code (JetPack 2.1) and is something that nVidia devs should manage to resolve in JetPack 2.1.1 or next JetPack versions at the start.sh file.

By the way, I cannot see why looking in lscpu for the string ‘x86_64’ will be useful as it gives information about your CPU not your OS version (which is that you are verifying, that you really have a 64-bit OS), whilst if I am not mistaken uname -i actually provides you with the OS version in your host machine. By writing and executing man uname in a terminal, the feedback provided says: ‘uname - print system information’. Maybe to double check they should compare uname -p to check if the processor is a x86_64 capable CPU, and uname -i to check that the hardware platform is also x86_64.

However as I have said in my previous post, I am not in charge of fixing it neither of modifying nVidia original code.

Kindly,
Yueh.

4

I’m just suggesting for future changes to JetPack, rather than as a workaround to current issues. I can’t personally use JetPack since my host is Fedora. I would hope that eventually JetPack becomes more generic which might mean newer versions of Ubuntu (beyond 14.04…which is a serious limitation) and other Linux flavors (such as my Fedora 23) eventually become easier to port to on host side. Packaging has always been a big issue in the Linux world, and I’m sure Jetsons would benefit from easier host side install if popular platforms were available…although that might require third party maintainers, some changes would make that packaging practical.

I consider validation of the host platform to be a mix of requirements. The CPU architecture seems to be what “arch” was meant for, rather than what flavor of Linux is installed. The use of “lscpu” is independent of Linux distribution. The use of “x86_64” rather than other details to find architecture is language independent. It works on my Fedora, and my Fedora has CUDA compatible with programs from JetPack, but I had to manually install everything.

It’s best to have a current workaround to issues (such as what you gave) as well as a future change to make workarounds a non-issue.

5

Yes, it would be nice if the JetPack with its packages will be supported in host machines with different popular distributions of Linux as Fedora, Red Hat, Ubuntu and Debian (though .deb could be manually installed in Debian too as far as I know), but it would be nicer if they would have their packages in an open repository as they had as far as I found when I was trying to figure out how to install CUDA + OpenCV4Tegra + Vision Works/OpenVX. Also, I cannot fully comprehend why they wrap it up in an easy-friendly auto-installer but omit the somewhat open repositories, when the JetPack if you read the logs at xterm carefully use the same repositories.

By the way, how did you manage to install the .deb files with their proper dependencies on Fedora? Do you have any thread explaining it / with a how to? (libopencv4tegra depending on cuda-cudart-7.0, cuda-npp-7.0 and cuda-cufft-7.0, libvisionworks depending on cuda-cudart-7.0). Have you tried to install xterm and started the Launcher file to make JetPack run on your Fedora machine, trying to mimic what JetPack does based on xterm?

Regarding lscpu and uname, I have done a quick search and checked that the uname command is also available on Fedora if I am not mistaken. Anyhow, I have extracted JetPack 2.0 and have not found any start_up.sh file, so probably they should revert to what was done in JetPack 2.0 when checking for a x86_64 capable CPU and a 64-bit OS -providing they did this check, cannot recall it right now for the xterm messages- or just do it with uname command (I cannot remember for a better way to do it as far as I little know about Linux).

Kindly,
Yueh.

6

I’ve never installed the .deb versions. I’ve used binary tarball releases. In some cases those are not available, so I cannot install those packages. The real trick is that Fedora 23 does not yet have available an akmod-nvidia package suitable for current nVidia hardware accelerated video driver (replacing nouveau). Since the nVidia video driver is mandatory for CUDA (and I’d use the nVidia replacement to nouveau anyway, it just works better outside of text-mode) I install the driver first before anything else and blacklist nouveau. This is a bit of work since each kernel update I have to go to text mode and install the modules again…and each Xorg update I have to install every linked file again (e.g., libGL).

uname is indeed a standardized command and available across all of Linux. This could also be used similar to lscpu for architecture detection, but I don’t know what the advantages or disadvantages would be. Just in terms of architecture detect though, the command would have to be language/locale independent. The one part of most of the strings used for detection which would be consistent among all languages is “x86_64”…no other part could be relied upon. lscpu is probably as good of a method as any other. It’s a bit like algebra…so many ways to do the same thing.

One experiment I tried in the past was to modify the package tools for use of .deb files on Fedora. Basically the original tools were for the purpose of trying to make use of .deb files on x86_64 desktop Fedora. My modification attempts were at getting the packages to work directly on a loopback mounted Jetson clone partition. I wanted to be able to update packages for future flash without involving the Jetson itself. I discovered that the entire system was so complicated and had so many places where major overhaul would be required that I never even came close to getting it to work. I think a multi-platform set of .deb cross-maintenance tools could be created, but the effort would be intense.

7

Hi yueh,

Thank you for reporting this issue and sharing the cool suggestion.
We’re doing the investigation, and will have an incremental improvement on JetPack in coming release.

Thanks

8

jetpack is so basic it should work on majority of ubuntu based platforms.

Run the command mentioned above

Please change the start_up.sh to be less retarted:

#!/bin/bash
# These don't matter much 

arch="x86_64"
distribution="Ubuntu"
language="en"

# Avoid to overwrite local.cfg file
if [ -f ./local.cfg ] ; then
    # To use current application_version field
    grep application_version ./local.cfg.tmp >> ./local.cfg
    rm -f ./local.cfg.tmp
else
    mv ./local.cfg.tmp ./local.cfg
fi

# iddo just paste somehing in
os_version="18.04" 
mv JetPack_Uninstaller ../
./Launcher

Next you can start JetPack with:

./start_up.sh