tx2-4GB r32.3.1 how to remove nv-l4t-usb-device-mode.service

Robotics & Edge Computing Jetson Systems Jetson TX2
1

My product does not need this, how do I remove it

2

The actual files controlling this are at:
/opt/nvidia/l4t-usb-device-mode

Those files are part of package “nvidia-l4t-init”, which unfortunately provides a lot of other files for init, and not just those device mode files. However, it is easy to simply disable the service.

To see its status:
systemctl status nv-l4t-usb-device-mode.service

To one-time stop the service:
systemctl stop nv-l4t-usb-device-mode.service

To start when stopped:
systemctl start nv-l4t-usb-device-mode.service

To completely disable the service when the service is stopped:
systemctl disable nv-l4t-usb-device-mode.service

The file which the package installs which actually triggers this, and which should go away upon service disable, is:
/etc/systemd/system/multi-user.target.wants/nv-l4t-usb-device-mode.service

These /etc/systemd files are usually symbolic links to the real file. In this case:

/etc/systemd/system/multi-user.target.wants# ls -l nv-l4t-usb-device-mode.service 
lrwxrwxrwx. 1 root root 62 Apr  8 19:31 nv-l4t-usb-device-mode.service -> /opt/nvidia/l4t-usb-device-mode/nv-l4t-usb-device-mode.service

In theory you could bzip2 or rm “/opt/nvidia/l4t-usb-device-mode/nv-l4t-usb-device-mode.service”, but as soon as there is a package update it is possible the service will be restored, so YMMV. I think a correct use of “systemctl disable nv-l4t-usb-device-mode.service” may do what you want even after a package upgrade, but I would advise testing it once.

1 Like
3

real good info, have you done any work on making the system boot faster. systemd-analyze blame lead me to disable nv-l4t-usb-device-mode.service

4

I just go by boot logs from serial console since it includes timestamps. There is a lot which cannot go faster, but the primary slowing tends to be from timeouts or searching for options.

As an examples:

  • Someone setting a static IP address will wait less than someone using DHCP.

  • The bootloader often examines for different boot media, and if the environment variable looks strictly at eMMC, and does not examine SD, USB, SATA, so on, then this is a significant increase in speed.

  • Among those things which take significant time, but are probably needed by most people, is systemd transitioning from multi-user.target to graphical.target. Graphical.target itself may be going through configuration files to test for multiple options to the login manager, despite only one being used. WiFi and other per-user setup may also take significant time (image if WiFi is instead enabled in multi-user.target, and does not need to be checked per-user during a GUI login). What one does with the GUI varies drastically by how the GUI is used. Customizing GUI to use only one login manager and only one desktop with a minimal config should be a significant time reduction, but what is acceptable depends on the individual user.

  • Sometimes disabling serial console, or reducing logging output to serial console, can improve boot speed. The serial UART is set to 115200 baud, and if there is less to print, then this would boot faster, but I wouldn’t expect large gains. I’ve never tried, but I have often wondered what would happen if the default serial console were set to around double its current speed…would that reduce boot time? But I have not been willing to actually test this (the speed would have to be increased in U-Boot as well, and not just in Linux).

I suspect removing device mode emulation of a network over the micro-B USB, and not having to loopback mount the partition used in the emulation of mass storage, would be a significant time saver, although perhaps not a huge savings. Every time you make a change you have to get a new serial console boot log and check again.