Can't use keyboard and mouse after flashing device

Hi,

I have the Jetson Orin Developer Kit which I have flashed with Jetpack 6.2 using the sdkmanager and I cannot use the keyboard and mouse. I can use a keyboard to enter boot mode on initial startup, and the keyboard functions properly in boot mode. However, once Ubuntu starts I cannot use the keyboard or mouse. I cannot get through the ubuntu quick start process because I can’t use the keyboard and mouse.

How do I get this to work? Am I missing something?

Thanks!

Hi,

Please try to hot plug the keyboard or mouse to check whether the message show in the dmesg.
Also provide log for us to review.

Thanks

Is the carrier board from an NVIDIA developer’s kit, or is it from a third party? A third party carrier board would need a different device tree, and this could cause keyboard/mouse to fail. You might also add the log from “/var/log/Xorg.0.log” (the GUI has to load the input driver and could fail).

Hi,
I plugged a micro-usb cable in to view the debug output. Here is the log from that, it includes one single startup. I cannot login through the micro-usb serial console because I do not have the username and passaword (I haven’t set them up). Is this what you are talking about with dmesg or log? How do I get the dmesg without accessing the terminal on the device?

putty.log (133.2 KB)
?
dmesg_dump.txt (60.7 KB)

The carrier board is from the developer kit. How do I check the log you mentioned?

Hi,

Please refer to Flashing Support — NVIDIA Jetson Linux Developer Guide 1 documentation to create default user in your host and flash again.

After flash, please check whether the issue exists.

Thanks

Likely you will need to flash again anyway, but keep in mind there is a way to add the user prior to flash (this is why @DavidDDD mentions the flashing support doc). However, if you cannot use mouse or keyboard in the GUI, then it means you will use a text console which is not part of the GUI. The serial console can log in if there is a user name/pass and won’t care about keyboard drivers. ssh login will also work since this also does not depend on the local keyboard. From there you could observe any log files. If you are using serial console, then you can turn on logging and simply “cat /var/log/Xorg.0.log” (or whichever log file) and the serial console session log can be posted. If you are using ssh, then you could simply (from the host PC; I am making up the Jetson’s address which you’d need to adjust):
scp <your user name>@<your Jetson IP address>:/var/log/Xorg.0.log .
(this copies that log to the current directory)

Flashing again offers some advantages if you’ve used the l4t_create_default_user.sh script prior to flashing. In that case the name and address and first boot setup are already complete before the flash is done.

Okay, I am running the default user script now. I am having this issue on two separate devices, and have reflashed both a couple of times. I have also tried multiple keyboard and mouse on both. I am trying the default_user script and will try to pull the log after that.
Thank you!

I am having trouble running the ‘l4t_create_default_user.sh’. My understanding is that I need to run ‘apply_binaries.sh’ first, but I get the following error:

||||||||||||||||||||||| ERROR |||||||||||||||||||||||

  1. The root filesystem, provided with this package,
    has to be extracted to this directory:
    /mnt/c/Users/Jacob Wallace/Desktop/JetsonBuildTools/Linux_for_Tegra/rootfs

  1. The root filesystem, provided with this package,
    has to be extracted with ‘sudo’ to this directory:
    /mnt/c/Users/Jacob Wallace/Desktop/JetsonBuildTools/Linux_for_Tegra/rootfs

Consult the Development Guide for instructions on
extracting and flashing your device.
|||||||||||||||||||||||||||||||||||||||||||||||||||||

I am positive that I have correctly unpacked the correct filesystem to Linux_for_Tegra/rootfs. Could ‘apply_binaries.sh’ be failing because I am running it on a windows machine, using wsl?

Hi,

It might be related to use wsl.
Please prepare a native ubuntu and flash again.

Thanks

Normally, via JetPack/SDK Manager, this is what would happen:

  • All of this expects unpacking into an ext4 filesystem type.
  • The “driver package” would be unpacked as your regular user. This produces almost everything, including the “Linux_for_Tegra/” subdirectory. If you unpack this with sudo, then expect errors.
  • The “sample root filesystem” would then be unpacked using sudo and create the content in “Linux_for_Tegra/rootfs/”.
  • From “Linux_for_Tegra/”, and only once, the command “sudo ./apply_binaries.sh” would be run. This is not to be run again after it has been run once. There may be errors associated with using this if apply_binaries.sh has run twice, or if sudo was missed.

This does not install the tools/l4t_create_default_user.sh. You would manually run that command using sudo.

Something which does need to occur is certain packages and features need to be available on your host PC. JetPack/SDKM will install much of that. Part of it could be related to ARM emulation or loopback support. As mentioned by @DavidDDD, if you use a VM, much of this will be missing (not the parts I mentioned earlier, but the parts which are required support). The l4t_create_default_user.sh script itself uses some ARM emulation packages.

I am assuming all of this is done manually, and not via JetPack/SDK Manager. Is that correct? If so, you will need to:

  1. Unpack the driver package as a regular user at some empty location to create “Linux_for_Tegra/” and most content.
  2. Unpack the sample root filesystem in “Linux_for_Tegra/rootfs/” using sudo.
  3. Run “sudo ./apply_binaries.sh” once from “Linux_for_Tegra/”.
  4. Run “sudo ./tools/l4t_create_default_user.sh” once from “Linux_for_Tegra/”.

You can log each of those commands in case of failure so you can post the results. Just append this to the command: " 2>&1 | tee log_somename.txt" and attach the log to the forum. Example:
sudo ./tools/l4t_create_default_user.sh 2>&1 | tee log_create_default.txt
(if you see something like a user name you don’t want to post, then just edit that part in the log file, e.g., replace with the letter ‘x’)

Assuming this is a VM, which isn’t technically supported, then there will likely be other errors. Probably the first will be related to missing ARM emulation or loopback. If this is not an emulation, then give us the exact host PC specification, e.g., what shows up in “cat /etc/issue”.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.