Known Issues and FAQ

Table of Contents [Sticky]

This page collects the most common problems encountered during build, flashing, boot, multimedia validation, and runtime testing on Jetson platforms using the Yocto environment described throughout this guide.

The goal is not to document every possible failure scenario, but to provide a practical starting point when something does not behave as expected.

Before troubleshooting any specific feature, confirm the basics first:

The correct MACHINE was selected
The image flashed successfully
The target booted from the expected storage device
The multimedia plugins are present on the target
The commands are being executed on the Jetson and not accidentally on the host system

Quick Checks

When something fails unexpectedly, these commands usually provide a good first indication of the system state:

lsusb -d 0955:
systemctl status nvargus-daemon
gst-inspect-1.0 nvv4l2h264enc
grep -n 'FDT\|OVERLAY' /boot/extlinux/extlinux.conf

In general:

lsusb helps confirm recovery mode detection during flashing
nvargus-daemon confirms that the CSI camera service is running
gst-inspect-1.0 verifies that NVIDIA multimedia plugins are installed
extlinux.conf helps confirm which device tree and overlays are active

Recovery Mode Problems

If the board is not detected in recovery mode, flashing cannot begin.

The most common causes are:

USB cables that only provide charging
Unstable USB hubs or adapters
Incorrect recovery button sequence
USB passthrough issues inside virtual machines

To verify recovery mode detection:

lsusb -d 0955:
dmesg | tail -n 50

A correctly detected Jetson should appear as an NVIDIA USB recovery device.

If nothing appears, retry the hardware recovery sequence and connect the board directly to the host instead of through a hub.

For development work, native Linux hosts are strongly preferred over virtual machines.

Flashing Issues

If flashing starts but later stalls or fails, the issue is usually related to the host environment or storage configuration rather than the Yocto build itself.

Typical examples include:

Incorrect storage target
USB instability
Partition layout mismatches
Laptop power saving services interfering with USB transfers

In these cases:

Re-enter recovery mode manually
Try another USB port
Avoid USB hubs
Review both the flashing log and serial console log

NVMe Boot Problems

External NVMe rootfs setups can occasionally fail to boot even after a successful flash.

Usually this happens because:

The board still contains an older partition layout
The boot order does not prioritize NVMe
The image configuration does not match the selected storage target

Useful checks on the target:

lsblk
findmnt /

If an old NVMe layout is interfering with the flashing process, clear the partition table before reflashing:

sgdisk /dev/nvme0n1 --clear

After rebooting, verify that the root filesystem is mounted from the intended device.

Login and User Issues

Some Yocto images only create the root user by default.

If SSH login using nvidia fails, create the user manually:

useradd -m -s /bin/bash nvidia
passwd nvidia
usermod -aG video,render,audio,sudo nvidia

The additional groups are important because several multimedia and graphical components require access to the video or render groups.

Multimedia Plugin Problems

If NVIDIA accelerated GStreamer plugins are missing, the image likely does not include the required multimedia packages.

Useful checks:

gst-inspect-1.0 nvv4l2h264enc
gst-inspect-1.0 nvv4l2decoder
gst-inspect-1.0 nvvidconv

These commands should print plugin information instead of reporting missing elements.

If the plugins do not exist:

Verify that the target was built using the multimedia enabled image
Confirm that the correct packages were added to the image configuration
Rebuild and redeploy the image if necessary

Graphical Sink Problems Over SSH

Graphical sinks such as:

nveglglessink

often fail over SSH forwarding sessions even when the multimedia stack itself is functioning correctly.

This is expected in many remote environments because EGL and DRI based rendering typically require a local graphical session.

For headless validation, prefer:

fakesink
File based pipelines
Encode only pipelines

If graphical rendering is required, run the pipeline directly from the Jetson desktop session instead of through SSH forwarding.

Overlay Problems

If hardware nodes are missing at runtime, the overlay may not have been applied correctly.

To inspect the active boot configuration:

grep -n 'FDT\|OVERLAY' /boot/extlinux/extlinux.conf

This helps confirm:

Which DTB is active
Which overlays were loaded during boot

If the expected overlay does not appear:

Rebuild the image
Reflash the target
Confirm that the overlay is enabled for the correct MACHINE

Host vs Jetson Confusion

Some multimedia plugins exist only on Jetson hardware.

For example:

nvv4l2decoder

is Jetson specific and will not exist on a normal x86 Linux host.

This is a common source of confusion during development when commands are accidentally executed on the host machine instead of the Jetson target.

When testing on x86 hosts, software decoders such as:

avdec_h264

should be used instead.

RTSP Issues

Some RTSP helper scripts depend on Python GObject bindings. You can also check whether RTSP helper binaries are installed:

which test-launch

Depending on the selected image configuration, some RTSP example utilities may not be installed by default.

Build Fetch Errors

If the build fails during do_fetch, the issue is usually related to missing artifacts or source mirror problems.

Recommended checks:

Verify that the required downloads exist in the mirror
Review the corresponding log.do_fetch file
Confirm that the NVIDIA bundle and downloads cache are complete

These problems are typically unrelated to the application code itself.

FAQ

Which image should I use for multimedia validation?

Use:

demo-image-full

unless the goal is specifically to validate a minimal image configuration.

Can multimedia be tested without a CSI camera?

Yes.

Most pipelines can still be validated using:

videotestsrc
Local video playback
Decode pipelines
File generation pipelines

Why does the board boot but the display stays black?

This can happen if:

The display is unsupported
The graphical session failed to start
The wrong device tree configuration is active

Check the system logs and confirm that the graphical environment initialized correctly.

Why does flashing work on one machine but fail on another?

USB controllers, power management, virtualization, and host kernel configuration can all affect Jetson flashing reliability.

Native Linux hosts with direct USB connections are usually the most reliable option.

How do I confirm that the system booted from NVMe?

Run:

findmnt /

The mounted root device should correspond to the expected NVMe partition.

Why are overlays not taking effect?

Usually because:

The board was not reflashed
The overlay was not enabled for the selected MACHINE
The overlay was added but the system was not rebooted afterward

Why does multimedia work locally but not over SSH?

Remote SSH sessions often do not provide the graphical environment required by EGL based rendering sinks.

The multimedia stack itself may still be functioning correctly.

❯

Share This Page

Send Email Using