I can only speculate.
What this code is for is to allow the micro-B USB to emulate various devices. For example, the mass storage part is just a demo with a read-only file. The network part is how the Jetson pretends to be a network adapter and provides DHCP to give the host PC address 192.168.55.1 when the micro-B USB is connected (the Jetson gets address 192.168.55.100).
As this is brought up or dropped as a service temporary files are added or deleted. If the service is still running, then the files are locked. Stopping the service normally removes the temporary content. My speculation is that if something causes the Jetson to shut down too quickly, then the stale files never have a chance to be removed. When it comes time to boot the current code has no way to remove locked files since it may not understand they are stale from a previous boot.
If the Jetson was ever shut down abnormally, e.g., power being pulled, then this is definitely high on the list of why this would happen. On the other hand, the micro-OTG connector has an ID pin to know if the connected cable is type-A (host mode) or type-B (device mode)…perhaps there is a weakness in the code if the cable unplugged or replugged under some circumstances, e.g., rapidly or perhaps when under load and unable to respond fast enough to a rapid change.
When this occurs, what cable type do you have connected (if any)? Has there been any sort of unexpected fast power down?
You might experiment with this to cycle on and off:
-
sudo systemctl start nv-l4t-usb-device-mode.service
sudo systemctl status nv-l4t-usb-device-mode.service -
sudo systemctl stop nv-l4t-usb-device-mode.service
sudo systemctl status nv-l4t-usb-device-mode.service
The “status” is for knowing if active or not. Note that there might be unrelated network warnings which are not really errors. It is the “active” (or not) which counts.