Hello everyone, I met the problem with installing cud 7.0 on my Jetson Board
I followed instruction from this website, and until the step 6, during the data copying, I think I moved my laptop an, which caused the micro-B disconnected to my laptop. After that, I tried to power on the TX1 board, and it did not show anything, no display, no use signals and anything, only the power light on.
If something failed during a flash you can always start a fresh flash. Despite cable removal causing software problems, it is unlikely to have done any permanent damage. I don’t know which temp files might get involved, but if flash breaks after that I’d think a temp file would need removal on host side.
Do verify first if ping works, perhaps the install worked but newer default video settings failed.
So how do I verify the “ping work”? micro-B connection to my laptop?
You have to use the wired ethernet. I’m assuming you have a router attached to it, or else your host was set up to work as the DHCP server. If not, then it may just be easier to flash anyway.
Ok, this time I did not use ethernet. I am trying to install again, but it also stop at step 6 , which is Copying APP into system.img part. It always show 000%.
I will try by using ethernet later
If you show the log of the last several lines near where it stalls, e.g., copy and paste via mouse, this would help.
Depending on where it is in the copy of APP it can take a very long time. First it creates and formats a 15GB loopback file, the it copies the sample rootfs with boot edits into that. This isn’t actually too bad for time. After that it moves system.img (the loopback file it just created) to new name system.img.raw; this raw file is used to create what is essentially a compressed version and becomes the new system.img. This latter step takes noticeable time, but isn’t too bad. Once this is done, flash can begin, and when it reaches the APP copy stage it is this sparse/compressed version it sends. Usually around the size of 2.5 to 3GB, this does take some time to complete, but it sounds like it may have stalled…do give this stage at least 15 minutes to be certain.
If this fails then it might be related to the image it created (system.img). Should loopback have problems the step might not ever complete since it couldn’t create the images. No image, then no APP copy. Check the exact size of the “bootloader/system.img.*” files.
If there is anything unusual about your host (e.g., VM or running on a Windows parittion) this could possibly have an effect as well.
Ethernet is not required for flash stage, but is useful for adding on packages after flash and reboot of the Jetson. Getting a ping from this indicates the Jetson works even if video does not.
As you said, I think probably the problem is cased from “boot loader/systm.img.*”. I tried again, and it stop at 15% of image copy, I waited around 3 hours and did not increase even 1%. I checked the boot folder, it only around 40 MB. Is that the problem?
Yes, even the compressed system.img would be around 2 or 3GB. The system.img.raw will be around 15GB. You could be running out of disk space. Or if you are running from a VM this tends to happen.
But I already set my VM’s Storage space around 128 GB, which should not cause the compress problem.
I’m just saying that if your compressed version is only 40MB, then you have a guaranteed failure. It isn’t possible to compress a 15GB image down to 40MB. The best you’d find is compressing down to 1.5 to 3GB. One reason this could fail is if your system didn’t have enough disk storage space (“df -H -T .” while in the bootloader directory would tell about available storage). If you have enough space, then the issue is something else.
I reinstalled my virtual machine again, and set the fixed storage. Downloaded the JetPack from Nvidia’s website. Installed again. The ping’s light was on (so probably the TX1 was not broken). However, everything was fine except to the system.img copy? Stopped at 11%, maybe I did not wait long enough? I waited around 2.5 hours for 11%.
The VM is often the culprit…VMs are known to cause problems. It isn’t that a VM can’t work, it’s that it is harder to make a VM work as a flash environment than it is for the VM to work just to run Linux and ordinary Linux apps. Many people have had issues with USB cutting out on a VM. Some people have found USB settings which get around this, other people have moved on to non-VM installs. I do not know have practical knowledge of VM setup, but apparently there may be ways to improve USB reliability with some settings…if anyone has a suggestion on this it would be useful.
I figured out, by using VirtualBox. You have to upgrade the USB connection drive. The default is USB 1.0 and you also have to download virtualbox extension pack then to move to USB 3.0. That’s works