nvidia jetson tk1 gui keeps crashing

after i do startxfce4 upon login i notice that the gui crashes and i’m back to a command line interface with the following error (i am still logged in though)

Sorry for the poor quality, my phone’s camera isn’t the greatest.

I’m not sure if this is the same thing, but earlier versions of L4T had a similar issue which was fixed. Which version of L4T are you using?

“head -n 1 /etc/nv_tegra_release” should show version. If not R21.4 I’d recommend just updating to this.

Does that mean I have to flash my jetson again with the latest version of jetpack?

Depends on which version you have now. I think R21.3 was the first to completely fix the issue, although R21.4 has some important fixes for other things. If you have R19.x you may also lose graphical mode from package updates accidentally overwriting libglx.

What version do you have now?

Does everything check out ok with “sha1sum -c /etc/nv_tegra_release”? (works from serial console or ssh without graphics)

I have R21.1 but upon trying to flash the jetson (i wanted to do a complete reformat anyway) I got an error in the middle of flashing and now my jetson doesn’t boot normally… it boots to a black screen

The error I got was about running out of space!!! I am so confused and I’m trying to fix it now… did I just brick my jetson? T_T

Most likely the device that ran out of space is your host, not Jetson. Very likely the Jetson is fine if it is flashed again…Jetson should be ok once the host is able to run a complete flash.

The deal is that flash creates a file system for loopback mount, and that file system is the size of an entire Jetson root partition (most of the time just under 16GB). Creation of a compressed/sparse version of the same file system adds about another 50% to storage requirements while the compressed/sparse version is being created, so you might need as much as roughly 24GB for flash. Check with something like “df -H .” in the directory you flash from.

You can immediately get some space back on the host by deleting the generated files in the bootloader subdirectory “system.img” and “system.img.raw”, assuming flash got to that stage.

If this is not the issue, what is the exact command line you used during flash? The maximum size (because of using powers of 1024 and not 1000) is “-S 14580Mib” (or slightly smaller “-S 14GiB”). Setting too high of an image size would cause a failed flash. It isn’t possible to use 16GiB or what seems to be the full size of eMMC because there are other partitions being added (such as bootloader) which you simply don’t see.

After I tried it again I got the same out of space error, so I just started uninstalling the media programs that came with ubuntu by default. After I did that I resumed the installation and it seemed to flash without error.

What should I do to confirm everything installed correctly and how much space should the r21.4 take up by default once I log into the jetson for the first time?

Probably the best check of correct install (other than things “looking normal and working”) is to see if the “apply_binaries.sh” worked correctly. To do this (from Jetson):

sha1sum -c /etc/nv_tegra_release

When flashing a Jetson I personally use the “-S 14580MiB” in order to maximize use of the flash memory. Others might use less for the purpose of adding partitions for custom purposes, such as swap space.

So far as the size of disk usage on the flash host goes, you can reuse the bootloader/system.img, and delete both the rootfs and bootloader/system.img.raw if you desire (after this you can use the “-r” option to reuse the existing system.img). Basically flash customizes the boot directory of rootfs, builds system.img to a full uncompressed file system of roughly 15GB, moves this to system.img.raw, and then produces a compressed/sparse version from this to become the new system.img. Whatever is in system.img is used for actual flash, rebuilding this every time on a system without changes in customization is not required.

If you want to loopback mount your image, such as for use with some host side debugging, then system.img.raw is useful to keep around. If you don’t mind rebuilding things each time, you can also get rid of system.img and the rootfs after flash works. To flash again you’d unpack sample_rootfs and run apply_binaries.sh, followed by the flash procedure.

Use “df” or “df -H” to see your host file system usage status.

I see that ubuntu installed correctly on the jetson, however I don’t see anything related to opencv or cuda… is there a way to fix this without doing a complete reinstall?

Flash does not install extra packages such as for opencv or cuda. This is a separate step and does not use, nor require flash.

The gist is that you go to the R21.4 download page, get the .deb for the cuda repo, add this, and then use the internet with normal apt commands to put things in, e.g. what I do is uncomment various repos in /etc/apt/sources.list, then “sudo -s” and:

# ...download cuda-repo-l4t-r21.3-6-5-prod_6.5-42_armhf.deb...
dpkg -i cuda-repo-l4t-r21.3-6-5-prod_6.5-42_armhf.deb
apt update
# ...install cuda-toolkit-6-5 and others...
apt-get install cuda-toolkit-6-5 debian-keyring g++-multilib g++-4.8-multilib gcc-4.8-doc libstdc++6-4.8-dbg libice-doc libsm-doc libstdc++-4.8-doc libxcb-doc libxext-doc libxt-doc libsfstdc++6-4.8-dbg libsfstdc++6-4.8-dbg

usermod -a -G video <username>

dpkg -i libopencv4tegra-repo_l4t-r21_2.4.10.1_armhf.deb
apt update

apt-get install libopencv4tegra libopencv4tegra-dev
(apt-get autoremove ...unused...)

I’m not sure what JetPack does, I develop from Fedora.

oh… wow thanks! Will try this out and report back!

Just wondering what does

usermod -a -G video

do?

I believe this is for CUDA permissions, although I’m not exactly sure. It looks like it adds the given user name to group video which in turn makes GPU available to that user. No GPU permission implies no CUDA apps for that user.

Is it ok to uninstall unity and replace it with xfce? Or would that cause future errors?

I have not tried to do this. In theory the answer does not depend on Jetson so much as how Ubuntu 14.04LTS would behave. I’m sure many others have actual experience with this and might be able to comment…my gut feeling is that as long as the packages were built for this architecture and available on the public repositories, that this should work (but it is still a complicated thing sometimes to replace the GUI, there may be “hiccups” doing so).