Help identify what needs to remain on host after Jetpack flash install on Jetson

Autonomous Machines Jetson & Embedded Systems Jetson TX2
1

I’m brand new to Nvidia, GPU, Jetson, etc. so please excuse my ignorance. I just recently purchased a Jetson TX2 and was able to follow the quick start tutorial, as well as a YouTube video:

https://www.youtube.com/watch?v=D7lkth34rgM

Everything went smoothly…well sort of. For starters, I didn’t have enough free disk space on my host machine the first time I ran the installer (couldn’t believe how much space was required on the host…more than recommended 10GB). I had to move some things around and rerun everything. In the end, it all seems to have worked out. The Jetson runs fine and I tested some sample codes which appear to also run fine.

At the very end of the installation, there is a check box that asks to “remove downloaded files” as they’re no longer needed. I checked that, clicked OK, and install complete.

Unfortunately, I noticed the host directory, in which I performed the install (I named “Jetson”), is showing that it still occupies a massive amount of disk space. “Right-click, properties” shows 42GB. This isn’t even possible as I don’t have that much free disk space. A closer look using

du -sh ./Jetson

shows the directory is occupying 16GB. Why the heck do I need all this stuff on my host? I would think the installer would clean everything up? Isn’t it all suppose to be over on the Jetson? In what situation would it be advised to keep these files?

I want to remove all the unnecessary files off the host, as it takes up waaaayyy to much disk space and doesn’t even seem to serve a purpose (too me at least). That being said, seeing as how I don’t understand why they’re there in the first place, I don’t know if I can simply delete the files? Maybe they’re there because I had to restart the install in the beginning?

Anyway, here’s the host directory “Jetson” structure following install
11G 64_TX2
11M devtools_docs
105M _installer
4.8M jetpack_docs
3.9G jetpack_download
36M JetPack-L4T-3.2.1-linux-x64_b23.run
7.5M JetPack_Uninstaller
242M NVIDIA_System_Profiler
37M nvl4t_docs
4.0K README.txt
4.0K Start_L4T_Docs.html
408K Tegra_Linux_Driver_Package_Release_Notes_R28.2.1.pdf

Please help identify what I can remove.

2

Also, I’d like to ask why an “ubuntu” user account exists with the install? Is that necessary or can I remove that user account? For security reasons, I assume just have one administrator account i.e the default “nvidia”.

3

There is a temporary download area under JetPack on the host after an install. This is what gets deleted when you are asked if you want to keep those files (the content which would have ended up on the Jetson…some content is for the host). You don’t need any of that if you prefer. If you’ve added something to the host which is needed, then it ends up somewhere in “/var” or “/usr/local”.

Ubuntu has this philosophy to not have an admin user “root”. There must be a regular user account able to use “sudo” to become root. Numeric user ID 1000 does this…and is named “ubuntu”. The “nvidia” account is used for some things more specific to NVIDIA, and is numeric ID 1001. The system will not work without UID 1000, so deleting “ubuntu” would cause failure. You could delete ID 1001, but it isn’t really suggested unless you’ve experimented and know you won’t need it. On systems which don’t go to my Jetson and which Ubuntu is used I rename the “ubuntu” account, but it is still there and is UID 1000 (in case of working on files on that other system I have also created user “nvidia” with UID 1001…not necessary, but saves headaches). I’m not sure how many scripts assume on Ubuntu you can use user “ubuntu” and use it by name (on my other Ubuntu system it knew the correct name because the installer asks what to name it at install time…this isn’t the case with L4T because it is a clone of a sample rootfs, and not an active installer).

4

@linuxdev

OK, so the temporary files should have been deleted, as I chose the option to. Great I’m good with that.

With regards to what remains in my host directory “Jetson” (which I created to run the installer), you said “You don’t need any of that if you prefer”.

Here’s where I’m looking for clarity. I prefer not to have unnecessary files chewing up 15GB+ of disk space. At no time was I under the impression that I would need to forfeit 15GB+ of host disk space for the Jetson/Nvidia experience. Install, fine, other than that, no. Furthermore, I prefer to have the Jetson/Nvidia experience I paid for, hence I want the overall system to be installed correctly. This conflict is the root of my question…I want both :)

Yes, call me ignorant as I am the one who installed everything and I should know what I’m doing. As a new user, I simply chose the “full install” option with JetPack, not really knowing specifically what I wanted at the time. So maybe those files (listed above and shown in attachment) are the result of me choosing the “full install” option. I don’t know. If they are, then what part of the “full install” option do they belong to? Under what goals/tasks/developments would I choose to have those files reside on my host? If you can clarify this, then I can informatively decide if deleting them is a safe choice without compromising my Jetson/JetPack/Nvidia experience.

As far as the Ubuntu user on the Jetson. OK, so I’ll keep it on there for the sake of stability. Can I change it’s password though without compromising anything? If Nvidia is shipping these with default user/password, the I imagine there are people/bots out there sniffing for this vulnerability. That was my main concern.

5

You can recursively remove the entire directory from which JetPack was run. This will in no way have any effect on your host. If those files were still in place when you ran JetPack again, then possibly it could avoid the time to download the files again.

When you choose to flash you have to create a bit-for-bit exact image of the entire eMMC of the Jetson. Some of those partitions are pre-packaged binary files, but the rootfs is generated fresh each time…then a compressed/sparse version is generated. The “Linux_for_Tegra/rootfs/” directory contains most of what goes into this, and if you are not generating a flash image, you don’t need this at all. If you want to re-flash with the same exact image, then you only need this once (you could say to “reuse” the image which would be at “Linux_for_Tegra/system.img”). Unless you expect to flash again none of this will ever be used. Even if you expect to flash, if you expect a new release to come out before the next flash, then none of this would be used again. Some people would like this in place to study, but you could get the same thing by unpacking the driver package and sample rootfs.

When you choose to install tools and examples and such to the host PC, then you also get significant content on the host PC…but none of it is in the JetPack directory. Things like a cross-compile tool chain for building the example code will go in. CUDA for your host PC will go in (and perhaps even the NVIDIA video driver which is needed as a prerequisite to CUDA). Lots of this is in “/usr/local/”. Some will be a “local repository” existing as a subdirectory in “/var/” (such as the CUDA, VisionWorks, or other “.deb” format files intended for the desktop PC architecture).

I would go so far as to say that if your Jetson ever touches any network which is public in any way that it should never do so without first changing account ubuntu’s password. This is a standard login password on all Ubuntu installs…everyone knows it and every port scanner will attempt to log in to this. I’ve watched and logged firewall traffic before and I’d be surprised if a public connection starts without an attempt to blindly login through known passwords which did not occur within 20 minutes being exposed to a public interface. I’ve seen automated crack attempts using just standard and common passwords occur within 30 seconds. Most of the time I see it within 5 minutes.

The “nvidia” account is not standard among all Ubuntu systems, but it is publicly known and should also have the password changed. This wouldn’t get hacked nearly as fast as account “ubuntu”, but it is still risky to expose this to the outside world without a password change.

Note that most routers don’t allow incoming ssh or other logins which were not initiated as outbound traffic by the computer itself, so it may not be as bad as it seems. On the other hand, imagine if you are a university student and an entire dormitory is on the same router with several engineering students all using a Jetson for a project. In the past this actually became an accidental issue for at least one person I know of because each person flashing the Jetson was referring to network name “tegra-ubuntu”…whichever “tegra-ubuntu” the router currently pointed at was not the one expected by the end user…but the end user didn’t know this and gladly started working on someone else’s Jetson.

I have three networks on my host PC. One for development, one for other uses (e.g., IPP protocol printing), and a third going to the public router. My Jetsons only get to the outside world through my well-guarded host PC.