Edit: Problem was caused by I3, use Unity for Jetpack.
A fresh installation of Jetpack 3.2 will only let you flash the board once. If you want to flash again you have to reinstall the driver and rootfs.
If you try to flash a second time it fails the sudo daemon
External Media
Then it fails to find the fifo
External Media
I’ve attached the debug log.
After uninstalling and reinstalling rootfs/driver everything seems to work again.
jetpack_debug.log (28.7 KB)
I’m not sure what mean “only once”. Do beware that you can only perform a single operation on the Jetson in recovery mode, and then you have to reset recovery mode to operate again on that Jetson (it isn’t a bug). Example: You cannot clone then flash without resetting recovery mode between clone and flash. You also cannot flash twice without resetting recovery mode between flashes. Is this what you mean by twice?
By only once I mean it will run through fine, and then if you try to flash again it will have those errors.
Yes it was put back into recovery mode.
I think it has something to do with switching from JetPack 3.1 to 3.2, a lot of stuff seems to fail when you try to use both
It should be able to flash more than once if put back into recovery mode between flashes. I know JetPack has had issues before when re-using it in a directory where a previous version was used, e.g., previously JetPack3.1 and now 3.2. You could validate using flash.sh manually. The following assumes rootfs is already populated by root user and apply_binaries.sh was also run as root:
sudo ./flash.sh -S 29318MiB jetson-tx2 mmcblk0p1 2>&1 | gawk '{gsub("[0-9][0-9]+[/][0-9[0-9]+ bytes sent..",".");print}' | tee flash_log.txt
…note that this logs to “flash_log.txt” for debugging, and cuts out some of the progress bar from the log file itself to reduce log file size. You could then post this log or just refer to it at a later time. If this fails then you can rule out JetPack itself while getting more details. I also assume it is not a VM host.
Yeah, to get around it I was using flash.sh, which always worked. Unfortunately something about installing with flash.sh instead of Jetpack caused USB not to work.
([url]https://devtalk.nvidia.com/default/topic/1035738/no-usb-power-with-devboard/[/url])
flash.sh should have no effect…this is more reliable and less complicated with fewer dependencies. Since the Jetson in recovery mode does not use power from USB one could completely cut power wires on the USB and have nothing but ground and data and it would work. When USB on a host changes (or on the Jetson) after using flash.sh I am suspicious of the install of rootfs and other steps. It is more or less close to impossible for flash.sh to change USB on the host end…JetPack changes host packages, flash.sh cannot. A clean driver package and rootfs download is a good way to debug because it simplifies.
Hi Atrer,
The sudo_deamon was not started when running JetPack. When JetPack starts to install, it will popup a dialog box asking root password to start up sudo_daemon. If you click cancel button or enter wrong password for 3 times, later installation will fail. Please enter correct password in the popup dialog box. In future releases, JetPack will not continue installation until correct password is provided.
Well it’s working now. I had to switch back and forth between 3.1 and 3.2 which involved a lot of uninstalling and reinstalling. I think I just got in an unclean state and things started acting screwy.
I haven’t seen the popup dialog to enter my root password in awhile, it always just asks within the terminal window now.
I discovered that all these strange issues are solved by using Unity for your user interface. I use I3 on my development computer which I think causes sudo-daemon not to work properly. That then causes a lot of strange install issues and prevents flashing.