Thanks for the reply. The board starts in recovery. I’m not sure it would make it this far if it wasn’t. Maybe it is getting kicked out somehow. I will tail the logs to see if disconnect occurs during the backup. Is a disconnect expected at this step?
It appears there is a disconnect happening at the point of failure (there are actually several disconnects during the initial stages of this process). Maybe things are moving too fast for the Ubuntu vbox to grab the USB device from the host.
Apr 12 09:04:52 ubuntu kernel: [930357.056310] usb 3-2: USB disconnect, device number 9
Apr 12 09:04:56 ubuntu kernel: [930360.584495] usb 3-2: new high-speed USB device number 10 using xhci_hcd
Apr 12 09:04:56 ubuntu kernel: [930360.735198] usb 3-2: New USB device found, idVendor=0955, idProduct=7f21, bcdDevice= 1.02
Apr 12 09:04:56 ubuntu kernel: [930360.735212] usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Apr 12 09:04:56 ubuntu kernel: [930360.735221] usb 3-2: Product: APX
Apr 12 09:04:56 ubuntu kernel: [930360.735228] usb 3-2: Manufacturer: NVIDIA Corp.
Maybe it’s working? I hung around for about 5 minutes and didn’t see any file creation happening. Disk space doesn’t budge either. I will give it another 5 minutes.
[UPDATE] Left it hanging for about 45 minutes. No movement.
I see “APX”. Is this a VM? If so, then it is the VMs fault for not reconnecting after disconnect. USB will disconnect and reconnect during flash, this is normal. A non-VM though will reconnect.
Thanks for the reply. I’m not convinced its anyones “fault”. I have flashed several Jetson boards from this VM without issue. This failure only occurs when I try to read back a partition. I would be curious to see what delay is being used after a disconnect in Tegraflash. Seems to me that a few extra milliseconds would probably do the trick. Unfortunately as you know, the app is closed source.
VMs have to be told to pass USB through. Depending on setup, they might not reacquire USB if it disconnects and reconnects. This is completely out of the control of the software running within the VM (the flash software cannot tell the VM to reconfigure, it has no idea USB was lost due to the VM setup).
Again, I realize the limitations of a VM. The box is told to automatically use the VID and PID of APX when it plugs in. Please recall that the device disconnects several times during a flash and is able to continue under normal conditions. The problem is specific to reading a partition.
Perhaps the host PC ran out of space? During a clone it is the .img.raw which is created first. This file is the exact same byte size as the rootfs partition. If the partition is 28 GB, then so is that file. Then the sparse file is generated based on that, and this file is slightly larger than the actual content stored on the partition (on a freshly flashed Jetson that’d be around 3.5 GB).
Yeah. I considered the space issue as well. The image file never gets created. Disk space does not budge during the process. I do have enough space to cover the APP partition however, should the flash utility create the img and img.raw file. I also verified the path the utility is using actually exists.
Since you are using sudo there shouldn’t be a permissions problem, but for debugging purposes, what do you get without sudo if you:
cd /where/ever/it/is/Linux_for_Tegra
touch bootloader/backup.img
ls -l bootloader/backup.img
Then, if that fails, try using sudo. If it does not fail, don’t bother using sudo. However, I’m also interested in which filesystem type is involved. From that Linux_for_Tegra/ directory, what do you see from: df -H -T .
(the “.” is important, it is an alias for “the current directory”)
I suspected something similar but I am not able to run the script without sudo. Unless there is a workaround I am unaware of. Regardless, here is the info you wanted to see.
jason@ubuntu:~/nvidia/L4T32.7.1/Linux_for_Tegra$ touch bootloader/backup.img
jason@ubuntu:~/nvidia/L4T32.7.1/Linux_for_Tegra$ ls -l bootloader/backup.img
-rw-rw-r-- 1 jason jason 0 Apr 12 14:25 bootloader/backup.img
jason@ubuntu:~/nvidia/L4T32.7.1/Linux_for_Tegra$ df -H -T .
Filesystem Type Size Used Avail Use% Mounted on
/dev/sda5 ext4 169G 118G 45G 73% /
Well, you do have permissions, and have proven that location is writable by your user. You have 45 GB available there (actual storage might be slightly less). I don’t know what the inode usage is, and I doubt that’s a problem, but what do you see from that location via: df -H -i .
(this displays inodes, which are basically metadata consumed when storing content; if inodes run out, then a nearly empty filesystem will actually be filled without ever coming close to filling the space)
The more likely answer depends on the partition size. On the Jetson, what is the partition you are backing up? What is the actual partition size (the total, not just the amount currently stored)?