Google Coral USB support on Truenas Scale 25.10

TrueNAS General
1

Hello,

I would like to know when it will be possible again to use Google Coral USB on Truznas Scale 25.10, as it is possible on the 24.10 version ? It is to use with Frigate.

Security risk: stay on 25.04.2.6 or upgrade but use "unauthorised" Nvidia drivers?
2

I’d say the chances for official support is pretty slim given the fact that the feature request to add the coral dkms driver has been denied

However i don’t know if that driver is only required for the pcie version or also for the usb version.

3

I believe USB version doesnt need any additional driver and should work out of the box.

4

I asked ChatGPT why my cpu is still very high while the Coral is well recognized by Frigate.

It says that If apex_0 does NOT exisT, then Frigate cannot use the Coral, even if it is seen by lsusb.

5

Subject: Help with Google Coral USB Accelerator on TrueNAS SCALE 25.10.3 — Stuck in Bootloader Mode (1a6e:089a)

Hello TrueNAS Community,

I am running TrueNAS SCALE 25.10.3 and trying to set up a Google Coral USB Accelerator to use with Frigate (running inside Home Assistant). I have hit a hard technical wall with how the host OS and virtualization layers handle the device’s native hardware initialization sequence.

The Problem:

When plugged into the TrueNAS hardware, lsusb identifies the Coral stick exclusively in its un-flashed bootloader state: ID 1a6e:089a Global Unichip Corp.

Because the device requires a runtime driver (libedgetpu) to push the firmware and dynamically morph its identity into operational mode (ID 18d1:9302 Google Inc.), I cannot get TrueNAS or any downstream services to interact with it properly.

What I Have Tried:

  1. Debian Docker Container Workaround: I set up a bootstrap container to handle the firmware initialization locally. While I successfully managed to install the official Google Coral repositories and driver runtimes inside the container, the device failed to switch states globally. Because Docker relies on static host cgroups mappings, the moment the Coral dropped connection to execute its hardware reset, the namespace mapping broke and the device immediately defaulted right back to the 1a6e:089a bootloader state.

  2. Debian Virtual Machine (KVM): I set up a dedicated Debian VM to try and handle the dynamic hardware state changes via virtualization. However, passing the individual USB device (1a6e:089a) through the TrueNAS Web UI fails. The guest VM completely loses sight of the USB device during the bootloader transition phase, rendering the VM unable to utilize the Coral chip.

Questions for the Community:

Since the device state must change at the hypervisor or host level, how are users successfully deploying the USB Coral on modern TrueNAS SCALE releases?

  • Is there a safe, supported way to inject the udev rules or the libedgetpu1-std driver directly onto the TrueNAS SCALE host so it handles the device transmutation natively?

  • Alternatively, what is the best practice for configuring KVM passthrough in TrueNAS SCALE to ensure a Linux VM doesn’t drop the USB connection when the vendor/product ID re-enumerates? (I tried passing through the entire physical PCIe USB controller instead of the device node but it didn’t work)?

Any insight, scripts, or guidance from anyone running a similar NVR setup would be greatly appreciated!

6

There are already multiple posts with similar issues and a feature request to include the driver in Truenas, but afaik that request was denied, so you have only limited options to use either a VM or an lxc and use USB pass through to one of the mentioned options.

2 Likes
7

FWIW, I found the benefit of Coral to be negligible when using BlueIris and the various detection libraries. Hopefully, zmarachi can get it to work with Frigate!

8

Resolution & Technical Breakdown

After systematic troubleshooting and assistance from AI, a clean and highly effective solution was discovered that completely bypasses the need to modify the host OS or configure complex virtual machine passthroughs.

Instead of relying on the TrueNAS SCALE host or an intermediary guest VM to initialize the hardware, the Coral USB device can be passed directly into the Docker environment. Frigate already contains the native libedgetpu runtimes and drivers baked directly into its image.

When Frigate is configured to look for the hardware, it handles the firmware injection and subsequent USB re-enumeration internally. By simply adding the following four lines to the Frigate config.yml file, the container successfully communicates with the device, forces it out of bootloader mode, and shifts it into its operational Google identity:

YAML

detectors:
  coral:
    type: edgetpu
    device: usb

Why This Works

When Frigate boots and initializes the edgetpu detector type mapped to usb, its internal drivers target the Global Unichip bootloader. As the chip drops connection to morph into the operational Google Inc. state, the direct container device mapping allows Frigate to immediately re-bind to the new product ID (18d1:9302) without losing the underlying connection namespace. This keeps your TrueNAS SCALE host completely clean, stable, and untampered with, adhering to best practices for appliance-based operating systems.