Linux for Tegra 21.1 fails to install on my Jetson board

Has anybody else had this problem?
I just tried installing L4T “Jetson TK1 Development Pack (JetPack TK1)” ( I accepted the defaults for everything, except that, rather than an “Express Install”, I chose the “Full Install” option.

I am now at the “Input Device Information” menu, but cannot determine the IP address of my device because it shows the following in the console:

Ubuntu 14.04.1 LTS tegra-ubuntu ttyS0

tegra-ubuntu login: ubuntu (automatic login)

Welcome to Ubuntu 14.04.1 LTS (GNU/Linux 3.10.40-g8c4516e armv7l)

 * Documentation:
sh: 1: /usr/bin/env: not found
Cannot execute /bin/bash: Permission denied

I have tried this twice with identical results. Can anybody help me?



I tried the full install today and didn’t see that problem.

So, you see that over the serial cable?

Do you have a monitor and an usb keyboard connected to the Jetson? Could you try logging in to the text console and check the IP from there?

Yes, that is what I see on the serial console. I did not thing to add a monitor & keyboard, as I will not be using them in my final configuration.

Did you do the full installation or the express?

Is there any way to perform the installation over ethernet instead of the slow USB cable?

I would comment that I was able to successfully install the rel19 version L4T.


I used the full installation and not the express option.

You can install the rel-21.1 using the same traditional mechanism as was used with rel-19 as well.

Since you have it booting and there “just” seems to be some issues with the rootfs, it is also possible to interrupt the boot process to u-boot’s prompt and mount the rootfs on SD card, SATA or NFS. They do need some setup though.

Where should I look to find documentation on setting up a (Linux 4 Tegra) rootfs on an SD card? Should I reverse engineer the installation script? Or is there something more formal written down.

Is it possible that there are different versions of the TK1 board and that I might have one with less flash memory than you?

The documentation package in the release page has quite a lot of information:

That page also has a Quick Start Guide that installs the rootfs without the Cuda stuff (you can install it later). I recommend you try that approach as the Jetpack is still in beta.

All Jetson TK1 boards have the same amount of flash.

Hi wpd,
The issue generally happens if the permissions are not preserved in the rootfs.
and that would happen if inodes are broken in the rootfs, or if the rootfs is made on windows filesystems like Vfat/fat/NTFS, as they are incapable of preserving x(execute) permission.

Or your rootfs got gobbled up during flash or corrupted.
Can you try the same “flashing”? and check if this happens over a fresh flash through Jetpack “Full Install” option?

Other possibility being,
you have sdcard containing old filesystem or stale content, try to disconnect/unplug the sdcard and reboot the board to see if it works.
Rationale: R21.1 comes with u-boot as default, which detects and boots from mmc1[sdcard] first, even though the new rootfs is written to mmcblk0p1[internal eMMC card], where as old R19.3 builds boots with fastboot, which only picks internal Flash memory, even though other rootfs locations are available :)

Hello sundeep471,
Thank you for your reply.

I downloaded the Jetson TK1 Development Pack from, and followed the guide from, accepting the defaults for everything except, at step 4, I selected a “Complete” installation. I ran this on a Ubuntu64 14.04 machine.

I don’t see how the permissions would have been corrupted on my ext4 filesystem.

I have tried this twice with identical results.

I have tried installing rel19, and that installed fine.

I don’t believe that the board has an sdcard installed on it – I tried the installation straight out of the box (literally – I took the board out of the box in which it was shipped, attached the cables, and started the installation). But I can check to see if it was shipped with an SDCard on Monday.

I noticed that, with rel19, the board booted up with an 8GB flash filesystem, which makes sense, given the

$ sudo ./ -S 8GiB jetson-tk1 mmcblk0p1

command I executed while following the (rel19) instructions given at But the specs for the board indicate that it should have 16 GB of eMMC flash. Is it possible that some boards have only 8GB of eMMC, that I have one of those boards, and that rel21 requires 16 GB?

It would be relatively easy for me to retry the rel19 flash command on Monday, specify 16 GB, and see what happens there.

Hmmm… do you require/assume that the installation script is run as root? I was more than a little shocked (and put off) when the script prompted me for my password. There should be no reason to require root access when building an embedded image in 2014. I had assumed that the script prompted me for my password because it ran out and did a bunch of apt-gets for me (another thing that shocked, and later came to cause problems for me).

There you go :)
Yes, you need to be at-least a sudoer(though not a super/root user) to flash the board, as the filesystem it creates will contain rootfs and rootfs contains system files which need to preserve permissions for respective users

Though your Jetpack Installer doesn’t block you from running Jetpack, being a non-sudo user, it prompts for sudoer password, when necessary, for the kind of operations it does to untar the rootfs with root user’s permissions preserved.

If not a sudo user, the untar of rootfs will force non-sudo user’s permission to respective files, which means the super-privileged files didn’t get the correct permissions, it is expecting.
Hence expected to the permissions issue.

Remember that, on R19, you have prefixed “sudo” while flashing the board with image.
It is not root access, but a sudo is required to install Jetpack components, download debian packages, untar/create rootfs, flash the board :)

To Add a User to sudoers list:

Happy Jetson’ing

I have this problem as well …
I have root access…
And I was able to complete step 2

  1. Untar the files and assemble the rootfs:

    sudo tar xpf ${RELEASE_NAME}
    cd Linux_for_Tegra/rootfs/
    sudo tar xpf …/…/Tegra_Linux_Sample-Root-Filesystem_R21.1.0_armhf.tbz2
    cd …/
    sudo ./

Successfully entered the “reset recovery mode”.

And did

sudo ./ jetson-tk1 mmcblk0p1


I later tried

sudo ./ -S 14GiB jetson-tk1 mmcblk0p1

both resulting in the below response:

BCT sent successfully
sending file: tegra124-jetson_tk1-pm375-000-c00-00.dtb

Basically after this i does not show anything and After keeping the system on overnight I reset it before trying again.

What do you see in the UART?

Let’s discuss system flashing in another thread, as this is related more to permissions not being preserved,
else it would confuse the entire thread, also it would help other users in identifying their issue/fix.

Pls start thread thread with the flash time problem.
We like to hear from you and fix your issue

First of all, my apologies for how long it takes me to respond to posts & questions on this board.

Is there any way I could receive an email when somebody updates the thread? Otherwise, I only respond when I think to check the forum (which, given my busy schedule and tight timeline, isn’t that often.)

Anyway, I am a sudoer, I did enter my password when prompted and the sudo did execute as expected.

My question should have been phrased as, “Should I run the installation script as a sudo command?”

Regardless, it doesn’t matter. I tried it twice, with identical results. It didn’t work for me, I rolled back to rel19 and am going forward with this. I haven’t bothered trying to configure the rel19 image for a 16Gb filesystem… it takes long enough to download the 8GB image that I’m not interested in pushing the envelope on this.

Don’t forget to unpack files on the host as sudo (you can’t preserve permissions if you don’t). And don’t use a non-linux file system under it (e.g., using vmware on NTFS is a guaranteed fail), they don’t support device special files. It’s best if you use sudo on every single step.

Last login: Tue Apr 11 22:28:58 2017 from
echo PWD'>' /bin/sh -c "cd \"/home/ubuntu\";export LD_LIBRARY_PATH=\"/usr/local/cuda-8.0/lib64\":\${LD_LIBRARY_PATH};\"/home/ubuntu/Templates\"";exit ubuntu@tegra-ubuntu:~ echo PWD'>' /home/ubuntu> ubuntu@tegra-ubuntu:~ /bin/sh -c “cd “/home/ubuntu”;export LD_LIBRARY_PATH=”/usr/local/cuda-8.0/lib64":${LD_LIBRARY_PATH};"/home/ubuntu/Templates"";exitt
/bin/sh: 1: /home/ubuntu/Templates: Permission denied

Could you help me solve “Permission denied”?

This too sounds like a permissions problem. What steps did you follow to flash? If not flash, what steps prior to the failure?

Sometimes login fails when going to a graphical environment if disk space is full and no temp files can be written, but you got far enough it looks like this isn’t the case.

FYI, R21.5 is now the current version, and is much improved over earlier versions. You might want to flash R21.5.