Trying to install JetPack using live ubuntu

Hi,

I am trying to install JetPack using a live Ubuntu USB. Is this possible?

I cannot mount the hard drive because it is a work computer and the HD is encrypted. There is a persistent 4Gb partition with the live USB. That is not enough space to install the Jetpack

So what I tried next was to mount a separate 16Gb USB and install it there.

This is what I have - my second USB stick mounted to /media/it/USB

$ mount
/cow on / type overlay (rw)
proc on /proc type proc (rw,noexec,nosuid,nodev)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
udev on /dev type devtmpfs (rw,mode=0755)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620)
tmpfs on /run type tmpfs (rw,noexec,nosuid,size=10%,mode=0755)
/dev/sdb1 on /cdrom type vfat (rw,noatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)
/dev/loop1 on /rofs type squashfs (ro,noatime)
none on /sys/fs/cgroup type tmpfs (rw)
none on /sys/fs/fuse/connections type fusectl (rw)
none on /sys/kernel/debug type debugfs (rw)
none on /sys/kernel/security type securityfs (rw)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev)
none on /run/lock type tmpfs (rw,noexec,nosuid,nodev,size=5242880)
none on /run/shm type tmpfs (rw,nosuid,nodev)
none on /run/user type tmpfs (rw,noexec,nosuid,nodev,size=104857600,mode=0755)
none on /sys/fs/pstore type pstore (rw)
systemd on /sys/fs/cgroup/systemd type cgroup (rw,noexec,nosuid,nodev,none,name=systemd)
gvfsd-fuse on /run/user/999/gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,user=it)
/dev/sdc1 on /media/it/USB type vfat (rw,nosuid,nodev,uid=999,gid=999,shortname=mixed,dmask=0077,utf8=1,showexec,flush,uhelper=udisks2)

I then downloaded the .bin file and ran:

it@it:~/$  sudo ./JetPack-L4T-2.1-linux-x64.run --target /media/it/USB/Jetpack
Creating directory /media/it/USB/Jetpack
Verifying archive integrity... All good.
Uncompressing JetPack  100%  Extraction failed.
it@it:~/

I tried mounting the USB with different attributes but it still didn’t work. Does anyone know whether this is possible? Do I need to reformat the USB or something?

Thanks in advance

This isn’t enough space. Typically the file system on the root partition (and there are others which are smaller) is 14580 MiB. During flash a file of this exact size is created. Then while this is loopback mounted, a compressed version taking several gigabytes is also created. Plus the original sample rootfs from which the loopback mounted version exists…probably a couple more gigabytes. Then there is the flash software itself. So…if your flash software is already installed (the “driver” package) plus the sample rootfs already, the run time requirements will exceed your flash disk.

If you could get a 64GB flash key you will probably succeed. But be sure to format this as ext4 (not as vfat or NTFS).

FYI, the host does not need to do any kind of standard hard drive mount. What happens is a file on the hard drive is loopback mounted. If you have root authority, it won’t matter if the original disk is encrypted or not as the loopback mounted file is not encrypted. But you must have root administrative privileges or you cannot create and manipulate some of the files required during a flash.

Great. Thank you very much for the quick and informative reply. I will try to obtain a bigger USB drive and post back if it works so that it might be of use to others.

(The bit I mentioned about the HD being encrypted is that I have a work laptop running windows with BitLocker Encryption and I don’t have any kind of admin access to that machine. I figured that I would be unable to access it so I didn’t even try. I was also a little wary of maybe corrupting it! I will research the things you mentioned though for my own curiosity).

Thanks again. I really appreciate the help

One more quick question.

Seeing as how I might need to purchase a 64Gb+ USB key, I might use whatever temporary storage media I get now for installing jetpack, to later expand available storage with the TK1 itself

With that in mind, would I be better off getting a USB flash drive or an SD card? I googled a bit and found some issues about enabling USB 3.0 but the instructions seem pretty straightforward.

what would you guys recommend?

Thanks again

If you mean USB flash drive versus SD card for host, probably USB flash. Keep in mind that when the Jetson is flashed that the micro-B USB port is USB2. That port is not physically wired to be capable of USB3 speed.

If you mean what to flash to on Jetson, I always recommend u-boot flash to internal eMMC, and then edit the boot config to offer multi-boot to other devices (such as SD card) at a later date If you flash directly to SD card or SATA, then your Jetson will require that specific device to be present for boot (having the boot loader on eMMC but pointing to different root partitions is very handy).

Hi again

Just an update. I got a 64Gb key, formatted to ext4 and tried to run again. But it did not work. This time I got as far as

Error occurs during installation.
Return Code: 1
Error accessing /media/it/USB/_installer/sudo_daemon: No such file or directory
1
starting sudo daemon
sudo /media/it/USB/_installer/sudo_daemon -installer=6101 -d=/media/it/USB/_installer/tmp 
sudo: /media/it/USB/_installer/sudo_daemon: command not found

/media/it/USB/_installer/run_command  -c="pgrep -f nv_info_broker | xargs kill -9" -d=/media/it/USB/_installer/tmp
/bin/bash: /media/it/USB/_installer/run_command: No such file or directory
2016/04/13 03:11:45 dialing:dial tcp 127.0.0.1:33335: getsockopt: connection refused

The GUI starts up and gets as far as “Installing … Extracting resources”. I am starting to think that maybe I can’t install from the live CD

The location it could not find the file or extract to was on the mounted USB key. The key may have filled up. At the time the error occurs, you could cd to “/media/it/USB” and run command “df -H .” and see how much space is left. If space is an issue, I’m going to guess that temporary files from unpacking compressed media (which go away after decompress) caused the issue (normally this would go through “/tmp”, but your “/tmp” is not a hard disk so it can’t go there).

If you just want to flash Jetson, then you can greatly reduce host side disk requirements by using only the “driver” software and sample rootfs, versus using JetPack. JetPack bundles a lot of things together, the flash itself is only a small subset. Before you give up on live CD, try these steps (download page is https://developer.nvidia.com/linux-tegra-r214):

  1. Copy driver package to key. Unpack driver: "sudo tar -jxv Tegra124_Linux_R21.4.0_armhf.tbz2" rm compressed driver file.
  2. cd to the "Linux_for_tegra/rootfs" directory. Unpack sample rootfs: "sudo tar -jxv Tegra_Linux_Sample-Root-Filesystem_R21.4.0_armhf.tbz2" rm compressed driver file.
  3. cd .. (puts you in the "Linux_for_Tegra" directory) Run "sudo ./apply_binaries".
  4. Put Jetson in flash mode.
  5. sudo ./flash.sh -S 14580MiB jetson-tk1 mmcblk0p1

This will keep space requirements on host side to a minimum. You can keep the key and “re-use image” for future flashes to go faster. Hope this gives you enough space on the key.

Thanks again for the response.

I tried it again. The usb isn’t running out of space (in fact the installer only runs for maybe 20 seconds before popping up the error). This is the state of the disks just as that error pops up (before shutting down the installer)

df -h
Filesystem      Size  Used Avail Use% Mounted on
udev            3.8G  4.0K  3.8G   1% /dev
tmpfs           767M  1.4M  766M   1% /run
/dev/sdb1        29G   26G  3.8G  87% /cdrom
/dev/loop1      976M  976M     0 100% /rofs
/cow            3.9G  1.8G  2.0G  48% /
none            4.0K     0  4.0K   0% /sys/fs/cgroup
tmpfs           3.8G  1.3M  3.8G   1% /tmp
none            5.0M     0  5.0M   0% /run/lock
none            3.8G   76K  3.8G   1% /run/shm
none            100M   20K  100M   1% /run/user
/dev/sdc1        58G  416M   55G   1% /media/it/USB

I tried a few different things including setting TMPDIR to a third USB (16GB) that I had mounted. TI tried editing fstab to mount /tmp to the USB as well to see whether that would help but that didn’t work (The fstab file somehow “fixed” itself)

Anyway, I might just try to just flash as you stated above and then maybe try to install other packages/utilities as I need them. I just want to get it up and running to start playing with it :-)

If it is any use, when I just run it normally (without giving a target installation dir) I get further along the process. In that case I get as far as the “Jetpack L4T Component manager” before it tells me that I do not have enough space available.

I am going to try a few things first and will report back

Actually I just deleted everything from the USB and tried one more time and it seems to be running now!!

Fingers crossed!

Unfortunately still no luck.

I think that the difference between the first run was that I kept the trailing backslash on at the end of the target directory.

This time, when it was trying to install I got the same error about the sudo_daemon being missing from the _installer directory. The installer directory on the USB only had the logs and tmp dir in it. However I had an _installer directory from an earlier attempt to install in my home dir so I copied that over verbatim and I managed to get a bit further

All of the files appeared to unpack but when it got to the install stage, it tried to install the Tegra Graphics Debugger. It was appearing to install ok but returned

Installing Tegra Graphics Debugger 2.1.15341 failed.

Return Code: 29

The log file gives:

Verifying archive integrity... All good.
Uncompressing NVIDIA Tegra Graphics Debugger  100%  
‘pkg/CrashReporter’ -> ‘/usr/local/Tegra-Graphics-Debugger-2.1/CrashReporter’
‘pkg/EULA.txt’ -> ‘/usr/local/Tegra-Graphics-Debugger-2.1/EULA.txt’
‘pkg/Plugins/accessible/libqtaccessiblewidgets.so’ -> ‘/usr/local/Tegra-Graphics-Debugger-2.1/Plugins/accessible/libqtaccessiblewidgets.so’

‘pkg/Plugins/TGDPlugin/Ubuntu-R.ttf’ -> ‘/usr/local/Tegra-Graphics-Debugger-2.1/Plugins/TGDPlugin/Ubuntu-R.ttf’
‘pkg/Plugins/TGDPlugin/ShowShaderUsages.png’ -> ‘/usr/local/Tegra-Graphics-Debugger-2.1/Plugins/TGDPlugin/ShowShaderUsages.png’
‘pkg/Plugins/TGDPlugin/default.layout’ -> ‘/usr/local/Tegra-Graphics-Debugger-2.1/Plugins/TGDPlugin/default.layout’
‘pkg/Plugins/TGDPlugin/CloneWindow.png’ -> ‘/usr/local/Tegra-Graphics-Debugger-2.1/Plugins/TGDPlugin/CloneWindow.png’
‘pkg/Plugins/TGDPlugin/EditStateBuckets.png’ -> ‘/usr/local/Tegra-Graphics-Debugger-2.1/Plugins/TGDPlugin/EditStateBuckets.png’
‘pkg/Plugins/TGDPlugin/EnableRed.png’ -> ‘/usr/local/Tegra-Graphics-Debugger-2.1/Plugins/TGDPlugin/EnableRed.png’
‘pkg/Plugins/TGDPlugin/ToggleWireframe.png’ -> ‘/usr/local/Tegra-Graphics-Debugger-2.1/Plugins/TGDPlugin/ToggleWireframe.png’
‘pkg/Plugins/TGDPlugin/LockWindow.png’ -> ‘/usr/local/Tegra-Graphics-Debugger-2.1/Plugins/TGDPlugin/LockWindow.png’
‘pkg/Plugins/TGDPlugin/Disconnect.png’ -> ‘/usr/local/Tegra-Graphics-Debugger-2.1/Plugins/TGDPlugin/Disconnect.png’
‘pkg/Plugins/TGDPlugin/ActivateOriginalShaders.png’ -> ‘/usr/local/Tegra-Graphics-Debugger-2.1/Plugins/TGDPlugin/ActivateOriginalShaders.png’
‘pkg/Plugins/TGDPlugin/CollapseAll.png’ -> ‘/usr/local/Tegra-Graphics-Debugger-2.1/Plugins/TGDPlugin/CollapseAll.png’
‘pkg/Plugins/TGDPlugin/EnableAlpha.png’ -> ‘/usr/local/Tegra-Graphics-Debugger-2.1/Plugins/TGDPlugin/EnableAlpha.png’
‘pkg/Plugins/TGDPlugin/libTGDPlugin.so’ -> ‘/usr/local/Tegra-Graphics-Debugger-2.1/Plugins/TGDPlugin/libTGDPlugin.so’
‘pkg/Plugins/TGDPlugin/Empty.layout’ -> ‘/usr/local/Tegra-Graphics-Debugger-2.1/Plugins/TGDPlugin/Empty.layout’
‘pkg/Plugins/TGDPlugin/ActivateEditedShaders.png’ -> ‘/usr/local/Tegra-Graphics-Debugger-2.1/Plugins/TGDPlugin/ActivateEditedShaders.png’
‘pkg/Plugins/TGDPlugin/SelectPerfMarkers.png’ -> ‘/usr/local/Tegra-Graphics-Debugger-2.1/Plugins/TGDPlugin/SelectPerfMarkers.png’
‘pkg/Plugins/TGDPlugin/DefaultSignals.js’ -> ‘/usr/local/Tegra-Graphics-Debugger-2.1/Plugins/TGDPlugin/DefaultSignals.js’
‘pkg/Plugins/TGDPlugin/Save.png’ -> ‘/usr/local/Tegra-Graphics-Debugger-2.1/Plugins/TGDPlugin/Save.png’
‘pkg/Plugins/TGDPlugin/EnableGreen.png’ -> ‘/usr/local/Tegra-Graphics-Debugger-2.1/Plugins/TGDPlugin/EnableGreen.png’
‘pkg/Plugins/TGDPlugin/FlipImageVertical.png’ -> ‘/usr/local/Tegra-Graphics-Debugger-2.1/Plugins/TGDPlugin/FlipImageVertical.png’
‘pkg/Plugins/TGDPlugin/CaptureNextFrame.png’ -> ‘/usr/local/Tegra-Graphics-Debugger-2.1/Plugins/TGDPlugin/CaptureNextFrame.png’
‘pkg/Plugins/TGDPlugin/Connect.png’ -> ‘/usr/local/Tegra-Graphics-Debugger-2.1/Plugins/TGDPlugin/Connect.png’
‘pkg/Plugins/TGDPlugin/FrameDebugging.layout’ -> ‘/usr/local/Tegra-Graphics-Debugger-2.1/Plugins/TGDPlugin/FrameDebugging.layout’
‘pkg/Plugins/TGDPlugin/ShaderPromote.png’ -> ‘/usr/local/Tegra-Graphics-Debugger-2.1/Plugins/TGDPlugin/ShaderPromote.png’
‘pkg/Plugins/TGDPlugin/Connected.layout’ -> ‘/usr/local/Tegra-Graphics-Debugger-2.1/Plugins/TGDPlugin/Connected.layout’
‘pkg/Plugins/TGDPlugin/default_SSH.layout’ -> ‘/usr/local/Tegra-Graphics-Debugger-2.1/Plugins/TGDPlugin/default_SSH.layout’
‘pkg/Plugins/TGDPlugin/Manifest.js’ -> ‘/usr/local/Tegra-Graphics-Debugger-2.1/Plugins/TGDPlugin/Manifest.js’
‘pkg/Plugins/TGDPlugin/ShaderEdit.png’ -> ‘/usr/local/Tegra-Graphics-Debugger-2.1/Plugins/TGDPlugin/ShaderEdit.png’
‘pkg/Plugins/TGDPlugin/Refresh.png’ -> ‘/usr/local/Tegra-Graphics-Debugger-2.1/Plugins/TGDPlugin/Refresh.png’
‘pkg/Plugins/TGDPlugin/ExpandAll.png’ -> ‘/usr/local/Tegra-Graphics-Debugger-2.1/Plugins/TGDPlugin/ExpandAll.png’
‘pkg/Plugins/TGDPlugin/CaptureFrame.png’ -> ‘/usr/local/Tegra-Graphics-Debugger-2.1/Plugins/TGDPlugin/CaptureFrame.png’
‘pkg/Plugins/TGDPlugin/EnableBlue.png’ -> ‘/usr/local/Tegra-Graphics-Debugger-2.1/Plugins/TGDPlugin/EnableBlue.png’
‘pkg/Plugins/TGDPlugin/ShaderCompile.png’ -> ‘/usr/local/Tegra-Graphics-Debugger-2.1/Plugins/TGDPlugin/ShaderCompile.png’
‘pkg/Plugins/TGDPlugin/Resume.png’ -> ‘/usr/local/Tegra-Graphics-Debugger-2.1/Plugins/TGDPlugin/Resume.png’
‘pkg/Plugins/CorePlugin/LogIcon_Warning.png’ -> ‘/usr/local/Tegra-Graphics-Debugger-2.1/Plugins/CorePlugin/LogIcon_Warning.png’
‘pkg/Plugins/CorePlugin/libCorePlugin.so’ -> ‘/usr/local/Tegra-Graphics--Debugger-2.1/Plugins/CorePlugin/LogIcon_Error.png’
‘pkg/Plugins/CorePlugin/Manifest.js’ -> ‘/usr/local/Tegra-Graphics-Debugger-2.1/Plugins/CorePlugin/Manifest.js’
‘pkg/Plugins/CorePlugin/LogIcon_Info.png’ -> ‘/usr/local/Tegra-Graphics-Debugger-2.1/Plugins/CorePlugin/LogIcon_Info.png’
‘pkg/Plugins/imageformats/libqtiff.so’ -> ‘/usr/local/Tegra-Graphics-Debugger-2.1/Plugins/imageformats/libqtiff.so’
‘pkg/Plugins/imageformats/libqjpeg.so’ -> ‘/usr/local/Tegra-Graphics-Debugger-2.1/Plugins/imageformats/libqjpeg.so’
‘pkg/Plugins/imageformats/libqmng.so’ -> ‘/usr/local/Tegra-Graphics-Debugger-2.1/Plugins/imageformats/libqmng.so’
‘pkg/Plugins/imageformats/libqico.so’ -> ‘/usr/local/Tegra-Graphics-Debugger-2.1/Plugins/imageformats/libqico.so’
‘pkg/Plugins/imageformats/libqsvg.so’ -> ‘/usr/local/Tegra-Graphics-Debugger-2.1/Plugins/imageformats/libqsvg.so’
‘pkg/Plugins/imageformats/libqwbmp.so’ -> ‘/usr/local/Tegra-Graphics-Debugger-2.1/Plugins/imageformats/libqwbmp.so’
‘pkg/Plugins/imageformats/libqtga.so’ -> ‘/usr/local/Tegra-Graphics-Debugger-2.1/Plugins/imageformats/libqtga.so’
‘pkg/Plugins/imageformats/libqgif.so’ -> ‘/usr/local/Tegra-Graphics-Debugger-2.1/Plugins/imageformats/libqgif.so’
‘pkg/Plugins/platforms/libqxcb.so’ -> ‘/usr/local/Tegra-Graphics-Debugger-2.1/Plugins/platforms/libqxcb.so’
‘pkg/libAppLib.so’ -> ‘/usr/local/Tegra-Graphics-Debugger-2.1/libAppLib.so’
‘pkg/libNvLogShared.so’ -> ‘/usr/local/Tegra-Graphics-Debugger-2.1/libNvLogShared.so’
‘pkg/libQt5CLucene.so.5’ -> ‘/usr/local/Tegra-Graphics-Debugger-2.1/libQt5CLucene.so.5’
‘pkg/libQt5Concurrent.so.5’ -> ‘/usr/local/Tegra-Graphics-Debugger-2.1/libQt5Concurrent.so.5’
‘pkg/libQt5Core.so.5’ -> ‘/usr/local/Tegra-Graphics-Debugger-2.1/libQt5Core.so.5’
‘pkg/libQt5DBus.so.5’ -> ‘/usr/local/Tegra-Graphics-Debugger-2.1/libQt5DBus.so.5’
‘pkg/libQt5Declarative.so.5’ -> ‘/usr/local/Tegra-Graphics-Debugger-2.1/libQt5Declarative.so.5’
‘pkg/libQt5Designer.so.5’ -> ‘/usr/local/Tegra-Graphics-Debugger-2.1/libQt5Designer.so.5’
‘pkg/libQt5DesignerComponents.so.5’ -> ‘/usr/local/Tegra-Graphics-Debugger-2.1/libQt5DesignerComponents.so.5’
‘pkg/libQt5Gui.so.5’ -> ‘/usr/local/Tegra-Graphics-Debugger-2.1/libQt5Gui.so.5’
‘pkg/libQt5Help.so.5’ -> ‘/usr/local/Tegra-Graphics-Debugger-2.1/libQt5Help.so.5’
‘pkg/libQt5Multimedia.so.5’ -> ‘/usr/local/Tegra-Graphics-Debugger-2.1/libQt5Multimedia.so.5’
‘pkg/libQt5MultimediaQuick_p.so.5’ -> ‘/usr/local/Tegra-Graphics-Debugger-2.1/libQt5MultimediaQuick_p.so.5’
‘pkg/libQt5MultimediaWidgets.so.5’ -> ‘/usr/local/Tegra-Graphics-Debugger-2.1/libQt5MultimediaWidgets.so.5’
‘pkg/libQt5Network.so.5’ -> ‘/usr/local/Tegra-Graphics-Debugger-2.1/libQt5Network.so.5’
‘pkg/libQt5OpenGL.so.5’ -> ‘/usr/local/Tegra-Graphics-Debugger-2.1/libQt5OpenGL.so.5’
‘pkg/libQt5Positioning.so.5’ -> ‘/usr/local/Tegra-Graphics-Debugger-2.1/libQt5Positioning.so.5’
‘pkg/libQt5PrintSupport.so.5’ -> ‘/usr/local/Tegra-Graphics-Debugger-2.1/libQt5PrintSupport.so.5’
‘pkg/libQt5Qml.so.5’ -> ‘/usr/local/Tegra-Graphics-Debugger-2.1/libQt5Qml.so.5’
‘pkg/libQt5Quick.so.5’ -> ‘/usr/local/Tegra-Graphics-Debugger-2.1/libQt5Quick.so.5’
‘pkg/libQt5QuickParticles.so.5’ -> ‘/usr/local/Tegra-Graphics-Debugger-2.1/libQt5QuickParticles.so.5’
‘pkg/libQt5QuickTest.so.5’ -> ‘/usr/local/Tegra-Graphics-Debugger-2.1/libQt5QuickTest.so.5’
‘pkg/libQt5Script.so.5’ -> ‘/usr/local/Tegra-Graphics-Debugger-2.1/libQt5Script.so.5’
‘pkg/libQt5ScriptTools.so.5’ -> ‘/usr/local/Tegra-Graphics-Debugger-2.1/libQt5ScriptTools.so.5’
‘pkg/libQt5Sensors.so.5’ -> ‘/usr/local/Tegra-Graphics-Debugger-2.1/libQt5Sensors.so.5’
‘pkg/libQt5Sql.so.5’ -> ‘/usr/local/Tegra-Graphics-Debugger-2.1/libQt5Sql.so.5’
‘pkg/libQt5Svg.so.5’ -> ‘/usr/local/Tegra-Graphics-Debugger-2.1/libQt5Svg.so.5’
‘pkg/libQt5Test.so.5’ -> ‘/usr/local/Tegra-Graphics-Debugger-2.1/libQt5Test.so.5’
‘pkg/libQt5WebKit.so.5’ -> ‘/usr/local/Tegra-Graphics-Debugger-2.1/libQt5WebKit.so.5’
‘pkg/libQt5WebKitWidgets.so.5’ -> ‘/usr/local/Tegra-Graphics-Debugger-2.1/libQt5WebKitWidgets.so.5’
‘pkg/libQt5Widgets.so.5’ -> ‘/usr/local/Tegra-Graphics-Debugger-2.1/libQt5Widgets.so.5’
‘pkg/libQt5Xml.so.5’ -> ‘/usr/local/Tegra-Graphics-Debugger-2.1/libQt5Xml.so.5’
‘pkg/libQt5XmlPatterns.so.5’ -> ‘/usr/local/Tegra-Graphics-Debugger-2.1/libQt5XmlPatterns.so.5’
‘pkg/libQtCharts.so’ -> ‘/usr/local/Tegra-Graphics-Debugger-2.1/libQtCharts.so’
‘pkg/libQtPropertyBrowser.so’ -> ‘/usr/local/Tegra-Graphics-Debugger-2.1/libQtPropertyBrowser.so’
‘pkg/libcrypto.so.1.0.0’ -> ‘/usr/local/Tegra-Graphics-Debugger-2.1/libcrypto.so.1.0.0’
‘pkg/libicudata.so.42’ -> ‘/usr/local/Tegra-Graphics-Debugger-2.1/libicudata.so.42’
‘pkg/libicui18n.so.42’ -> ‘/usr/local/Tegra-Graphics-Debugger-2.1/libicui18n.so.42’
‘pkg/libicuuc.so.42’ -> ‘/usr/local/Tegra-Graphics-Debugger-2.1/libicuuc.so.42’
‘pkg/libssl.so.1.0.0’ -> ‘/usr/local/Tegra-Graphics-Debugger-2.1/libssl.so.1.0.0’
‘pkg/libudev.so.0’ -> ‘/usr/local/Tegra-Graphics-Debugger-2.1/libudev.so.0’
‘pkg/nvidia-gfx-debugger’ -> ‘/usr/local/Tegra-Graphics-Debugger-2.1/nvidia-gfx-debugger’
‘pkg/nvidia-gfx-debugger.bin’ -> ‘/usr/local/Tegra-Graphics-Debugger-2.1/nvidia-gfx-debugger.bin’
‘pkg/target/linux-v3l_l4t-glx-t124-a32/Stripped_libNvidia_gfx_debugger.so’ -> ‘/usr/local/Tegra-Graphics-Debugger-2.1/target/linux-v3l_l4t-glx-t124-a32/Stripped_libNvidia_gfx_debugger.so’
‘pkg/target/linux-v3l_l4t-glx-t124-a32/Stripped_libNvPmApi.Core.so’ -> ‘/usr/local/Tegra-Graphics-Debugger-2.1/target/linux-v3l_l4t-glx-t124-a32/Stripped_libNvPmApi.Core.so’
‘pkg/target/linux-v3l_l4t-egl-t124-a32/Stripped_libNvidia_gfx_debugger.so’ -> ‘/usr/local/Tegra-Graphics-Debugger-2.1/target/linux-v3l_l4t-egl-t124-a32/Stripped_libNvidia_gfx_debugger.so’
‘pkg/target/linux-v3l_l4t-egl-t124-a32/Stripped_libNvPmApi.Core.so’ -> ‘/usr/local/Tegra-Graphics-Debugger-2.1/target/linux-v3l_l4t-egl-t124-a32/Stripped_libNvPmApi.Core.so’

========================================

To uninstall the NVIDIA Tegra Graphics Debugger, please delete "/usr/local/Tegra-Graphics-Debugger-2.1"
Installation Complete

Noticing again that it seemed to be installing to /usr/local/Tegra-Graphics-Debugger-2.1 , I created a soft link there of the same name back to another dir on the USB so that any space would be used up on the USB . I ran the installer again. The files appear to be there

CrashReporter          libQt5Declarative.so.5         libQt5Qml.so.5             libQt5Widgets.so.5
EULA.txt               libQt5DesignerComponents.so.5  libQt5QuickParticles.so.5  libQt5XmlPatterns.so.5
libAppLib.so           libQt5Designer.so.5            libQt5Quick.so.5           libQt5Xml.so.5
libcrypto.so.1.0.0     libQt5Gui.so.5                 libQt5QuickTest.so.5       libQtCharts.so
libicudata.so.42       libQt5Help.so.5                libQt5Script.so.5          libQtPropertyBrowser.so
libicui18n.so.42       libQt5MultimediaQuick_p.so.5   libQt5ScriptTools.so.5     libssl.so.1.0.0
libicuuc.so.42         libQt5Multimedia.so.5          libQt5Sensors.so.5         libudev.so.0
libNvLogShared.so      libQt5MultimediaWidgets.so.5   libQt5Sql.so.5             nvidia-gfx-debugger
libQt5CLucene.so.5     libQt5Network.so.5             libQt5Svg.so.5             nvidia-gfx-debugger.bin
libQt5Concurrent.so.5  libQt5OpenGL.so.5              libQt5Test.so.5            Plugins
libQt5Core.so.5        libQt5Positioning.so.5         libQt5WebKit.so.5          target
libQt5DBus.so.5        libQt5PrintSupport.so.5        libQt5WebKitWidgets.so.5

but the gui still came back with the error box and error code from above, even though the log file says installation complete.

I might try an older version of the Jetpack too to see. Or maybe even just try to install a minimal install to see if I can get it working

Make sure to try just flash without using JetPack (just use the driver package…this greatly simplifies requirements).

One thing I do notice from some of the “df” listings, is the use of one loopback device. Normally a root user (sudo) could run the driver flash.sh program (versus full JetPack) and if not enough loopback devices exist, one would be created (non-root cannot create loopback files, although non-root can use them). It’s quite possible that a live CD never installed the infrastructure for multiple loopback devices to be created on-the-fly as requested. I’m not near my Linux machines at the moment, so I’ll see if I can look up commands to manually create loopback devices tomorrow.

The command to test is “losetup -f”. That command finds the first unused loop device. If run as root, this also can create the device if it doesn’t exist. Since the live distribution seems to already have loop0, running the command via sudo should result in reporting and creating loop1.

Before running the command as sudo, see what exists (should be loop0 and maybe loop-control):

ls /dev/loop*
sudo losetup -f
ls /dev/loop*

This should give a good idea as to whether a purely flash (non-JetPack) install should succeed when run as sudo.

Just to prevent any confusion I might have caused, I am using an image installed on a USB with a 4Gb persistent disk file. I re-installed again to the USB from the original iso today

this is what I have

root@it:/home/it# mount
/cow on / type overlay (rw)
proc on /proc type proc (rw,noexec,nosuid,nodev)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
udev on /dev type devtmpfs (rw,mode=0755)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620)
tmpfs on /run type tmpfs (rw,noexec,nosuid,size=10%,mode=0755)
/dev/sdb1 on /cdrom type vfat (rw,noatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)
/dev/loop1 on /rofs type squashfs (ro,noatime)
none on /sys/fs/cgroup type tmpfs (rw)
none on /sys/fs/fuse/connections type fusectl (rw)
none on /sys/kernel/debug type debugfs (rw)
none on /sys/kernel/security type securityfs (rw)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev)
none on /run/lock type tmpfs (rw,noexec,nosuid,nodev,size=5242880)
none on /run/shm type tmpfs (rw,nosuid,nodev)
none on /run/user type tmpfs (rw,noexec,nosuid,nodev,size=104857600,mode=0755)
none on /sys/fs/pstore type pstore (rw)
systemd on /sys/fs/cgroup/systemd type cgroup (rw,noexec,nosuid,nodev,none,name=systemd)
gvfsd-fuse on /run/user/999/gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,user=it)
/dev/sdc1 on /media/it/186d3b71-f44a-44a6-9935-028696241bac type ext4 (rw,nosuid,nodev,uhelper=udisks2)
root@it:/home/it# ls /dev/loop*
/dev/loop0  /dev/loop2  /dev/loop4  /dev/loop6  /dev/loop-control
/dev/loop1  /dev/loop3  /dev/loop5  /dev/loop7
root@it:/home/it# sudo losetup -f
/dev/loop2
root@it:/home/it# ls /dev/loop*
/dev/loop0  /dev/loop2  /dev/loop4  /dev/loop6  /dev/loop-control
/dev/loop1  /dev/loop3  /dev/loop5  /dev/loop7
root@it:/home/it#
root@it:/home/it# df -h
Filesystem      Size  Used Avail Use% Mounted on
udev            3.8G  4.0K  3.8G   1% /dev
tmpfs           767M  1.3M  766M   1% /run
/dev/sdb1        29G   26G  3.8G  87% /cdrom
/dev/loop1      976M  976M     0 100% /rofs
/cow            3.9G  255M  3.5G   7% /
none            4.0K     0  4.0K   0% /sys/fs/cgroup
tmpfs           3.8G  1.5M  3.8G   1% /tmp
none            5.0M     0  5.0M   0% /run/lock
none            3.8G  112K  3.8G   1% /run/shm
none            100M   68K  100M   1% /run/user
/dev/sdc1        58G  3.8G   51G   7% /media/it/186d3b71-f44a-44a6-9935-028696241bac
root@it:/home/it#

I have extracted the drivers and image as you suggested about and am about to try flashing the jetson. I will keep you updated. Thanks again for all your help. I am learning a lot

Ok, final update.

I tried flashing the jetson but I got error. I connected my laptop from the USB to the micro-USB on the jetson. Started the board. Held down the recovery button and pressed the reset button once. Then ran the command above.

sudo ./flash.sh -S 14580MiB jetson-tk1 mmcblk0p1
copying bctfile(/media/it/186d3b71-f44a-44a6-9935-028696241bac/Jetpack_Drivers/Linux_for_Tegra/bootloader/ardbeg/BCT/PM375_Hynix_2GB_H5TC4G63AFR_RDA_924MHz.cfg)... done.
copying bootloader(/media/it/186d3b71-f44a-44a6-9935-028696241bac/Jetpack_Drivers/Linux_for_Tegra/bootloader/ardbeg/u-boot.bin)... done.
        populating kernel to rootfs... done.
        populating jetson-tk1_extlinux.conf.emmc to rootfs... done.
done.
Making system.img... 
mapping system.img to loop device failed.

Some information about the connected devices: (I am using a powered USB hub as I only have two USB slots on my laptop)

lsusb
Bus 002 Device 004: ID 0951:1666 Kingston Technology 
Bus 002 Device 003: ID 2109:8110  
Bus 002 Device 002: ID 054c:09c2 Sony Corp. 
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 005: ID 04f2:b45d Chicony Electronics Co., Ltd 
Bus 001 Device 004: ID 8087:0a2a Intel Corp. 
Bus 001 Device 003: ID 138a:0017 Validity Sensors, Inc. 
Bus 001 Device 007: ID 0955:7140 NVidia Corp. 
Bus 001 Device 002: ID 2109:2811  
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

I think I might need to borrow or buy a cheap laptop/desktop that I can do a HD install of Ubunutu on to try flashing the Jetson :-(

Bingo:

mapping system.img to loop device failed.

I suppose “bingo” traditionally means not just finding the problem, but knowing why it occurred. The issue is indeed one of not being able to cover the root partition file with a loopback device. The very odd issue is that your “losetup -f” test shows “/dev/loop2” is the next open loop device, and that the file itself was pre-created (not a devfs thing, but statically exists). Also, you used sudo…there is no reason why the loopback should have failed unless for some reason the kernel in the flash/live disk image was never set up or configured to cover a file with an ext4 loopback device.

Basically I can confirm that you did everything right, and that in general the flash should have worked, but this one ability regarding loopback is what is failing. Perhaps the live Linux image you are using was kept small in size by not including features which a live distro would not expect (although the feature is typically one for rescue).

A “real” install would probably work, but there is also a chance a different “live” distro would also work. You’re on the right track.

Thanks again for your prompt and helpful response. It’s much appreciated.

I thought that I needed to use Ubuntu 14.04 or is that restriction only for Jetpack? I actually have a USB with multiple flavours of Linux installed (Courtesy of YUMI). I could try the same thing with them. I think that I originally tried with lubuntu or Xubuntu and it had complained that I needed Ubuntu!

I might be able to get my hands on an old work laptop that they are replacing for one of that staff and “borrow” it temporarily to put linux on it…either that or try to put it on my own work laptop and then send it to IT with a wiped disk telling them I don’t know what could have happened to it :-)

Ubuntu 14.04 is only required because of JetPack packages. Flash (the driver package plus sample rootfs) is very simple after you’ve done it once.

I use Fedora, and am unable to use JetPack. I do install (by hand) of many packages which are finicky about install order. Some packages are not available at all in binary format, so those packages do require Ubuntu 14.04 on the x86_64 host. The thing is that I’m more interested in development on Tegra products, and except for some display interaction with my desktop, everything can be installed by hand to Jetson.

Ok,

So in the end up I used a simple method to “solve” my problem with the live distro. I installed the Ubuntu to the USB and made it bootable.

After that the Jetpack worked ok and it looks like it has successfully installed.

I thought I should come back to post it in case anyone else has the same issue. This might save them some time

While SDK Manager may be the way going forward with the latest Jetpack installed, I think some developers might find value is using the Ubuntu Live USB with persistence approach to flashing devices like the TX1/TX2 for example.

I am going to try to use this method to update to the latest Jetpack (Cuda 10/Ubuntu 18) on the TX1 (currently Cuda 8/Ubuntu 16).

Live distributions may have some issues, or might work well. It depends on how the live distribution is built. If the following holds true, then there should be no issue with that particular live distribution:

  • The kernel supports loopback (not all live distributions do, and short of rebuilding your live distribution with more kernel support, then this would fail to do the job).
  • The filesystem type supports and preserves all Linux filesystem attributes, including sticky bits, group ID, setuid, and setgid. Not all live distributions will support this, at least not by default on the live rootfs, but if you have an ext4 partition as well, then this is perhaps trivial to solve.

Probably the easiest way to see if a particular live distribution will work is to try it.