Follow up on my previous reply:
It seems like on my Ubuntu 18.04 system, something else reads this ominous one-time information that StephenWarren talked about.
I tried the auditctl monitoring, but it doesn’t write anything to the report (even when I keep it running for the flash script).
Syscall Report
=======================================
# date time syscall pid comm auid event
=======================================
<no events of interest were found>
I also tried uninstalling modemmanager but it doesn’t change the behavior. I then tried to relax the rules of auditctl a bit and found something potentially interesting:
Everytime I connect the tx2 in recovery mode I get about 500 “openat” calls from “colord-sane”
Your assumptions about how I did the last experiment are correct. I may have installed some stuff manually, but I besides Intel Realsense nothing with udev rules, I believe.
I doubt “apparmor” would be an issue, but there are cases where it can be. Mostly I would think this would cause some programs to not run at all, whereas running incorrectly wouldn’t happen. Did you install apparmor manually? If not, then I’d ignore this and leave apparmor alone, but if you did, then I’d try without apparmor.
I have reproduced the issue simply by installing most of the packages in your package list (I excluded all the CUDA, ROS, SDK Manager, etc. packages that aren’t in standard Ubuntu repos.) I filed NV bug 2750338 for this. I will see if I can track down the problem.
The problematic package is tlp. I’ve repro’d this problem on Ubuntu 18.04 and Ubuntu 16.04 now. Installing tlp causes it. Removing tlp fixes it (sudo apt purge tlp tlp-rdw). I’ll try to investigate a bit more why this is, and whether it can be worked around, and how/where to document it.
All, are you able to confirm that removing tlp, or editing its configuration file as described above and then restarting tlp or rebooting, resolves this issue? Thanks.
The L4T release notes for the next release describe the issue with tlp, so I’ve closed the associated NVIDIA bug report that’s associated with this thread; I assume that everyone was experiencing the same tlp-related issue.
I have the same problem. Could not detect target hardware. Please make sure the target hardware is connected and is in recovery mode, choose OK and RETRY.
I am having the exact same issue @Dakow mentioned in comment #27. When I run ./flash.sh script, it stucks at
tegrarcm_v2 --isapplet
If I wait for 15-20 minutes I get:
tegradevflash_v2 --iscpubl
CPU Bootloader is not running on device.
Then again the following is printed:
tegrarcm_v2 --isapplet
It goes on like this in a loop if you wait long enough.
My platform is Xavier NX, Host machine is Ubuntu. (Not a virtual machine).
What I tried:
Different USB ports (USB 2.0/3.0/3.1),
Setting USB device ID as blacklisted in /etc/default/tlp,
Uninstalling tlp package,
Using Ubuntu 16.04 and 18.04 host machines.
Python 2.7 is installed on my system.
In all trials, it ended up stucking as I described above. Could you help?