Hi Luxonis Team, We are currently experiencing an issue with an **OAK-D-CM4-POE** that we recently deployed. When running any DepthAI example (for example, `camera_preview.py`), we consistently receive the following `RuntimeError: Failed to boot device!` It appears that the pipeline is not being successfully loaded onto the device. ### Environment Details: * Device: OAK-D-CM4-POE * DepthAI version: 2.x * Running on: RVC2 device (CM4 onboard) Also when I checked for DeviceInfo this was the output: DeviceInfo(name=2.1, deviceId=14442C10614D39D200, X_LINK_UNBOOTED, X_LINK_USB_VSC, X_LINK_MYRIAD_X, X_LINK_SUCCESS) When I compare this to another camera that doesn't have the issue it mxid instead of deviceId key shown above. I am not sure if this information helps. I have tried running multiple different DepthAI examples, but all of them result in the same “Failed to boot device!” error. What’s unusual is that we have deployed other OAK-D-CM4-POE units previously using the same setup and DepthAI version, and we have not encountered this issue before. Any guidance or troubleshooting steps would be greatly appreciated. Thank you in advance for your assistance.

Hey @"GurdeepakSidhu"#p33204 - which depthai version is installed on the working and which on the non-working camera can you check? mxid instead of deviceId points that you have different versions of depthai installed, afaik the swithc from mxid to deviceID happened with DepthAi v3, so its possible you have that installed... We have premade images available [here](https://docs.luxonis.com/hardware/platform/deploy/to-rpi/#Deploy%20with%20Raspberry%20Pi-Using%20pre-configured%20RPi%20OS%20image). For DAi v2 I think v10 is the last one... Thanks, Oskar

Hi @"OskarSonc"#3466, Thank you for that insight. Previously, the non-working camera was indeed running DepthAI v3. However, I’ve now created a new virtual environment and ensured that both the working and non-working cameras are using the same DepthAI version: **v2.30.0.0**. Despite that, the `depthai-python` examples are still not working on the non-working camera. It consistently fails with a **“failed to boot device”** error. Please let me know how to proceed in order to fix this issue. Thank you and have a great day, Best regards

Hi @"OskarSonc"#p33217, > Here is an example of running the camera_preview.py sample: > (edge) pi@tallyvision-camera-0029:\~/depthai-python/examples/Camera $ python3 camera_preview.py > > [2026-02-26 18:39:51.672] [depthai] [warning] Skipping X_LINK_UNBOOTED device with name "2.1" () > > [2026-02-26 18:39:52.764] [depthai] [warning] skipping X_LINK_UNBOOTED device having name "2.1" > > Traceback (most recent call last): > > File "/home/pi/depthai-python/examples/Camera/camera_preview.py", line 8, in > > with dai.Device() as device: > > ^^^^^^^^^^^^ > > RuntimeError: Failed to boot device! Hope this helps! Thank you and have a great day!

Are you using any custom image on this camera or on the other? One thing that you could do is flash the new image from the link I sent onto the non-working camera... But before that, can you run the depthai-python/utilities/cam_test.py with DEPTHAI_LEVEL=debug: `DEPTHAI_LEVEL=debug XLINK_LEVEL=debug python3 cam_test.py` and then send the logs back. Thanks, Oskar

Hi @"OskarSonc"#p33231 Hope you are doing well! I ran the command you provided. `DEPTHAI_LEVEL=debug XLINK_LEVEL=debug python3 cam_test.py` Below are the logs: > pi@tallyvision-camera-0029:\~/depthai-python/utilities $ DEPTHAI_LEVEL=debug XLINK_LEVEL=debug python3 cam_test.py > > [2026-02-27 20:16:17.566] [depthai] [debug] Python bindings - version: 2.30.0.0 from build: 2025-03-18 13:32:35 +0000 > > [2026-02-27 20:16:17.566] [depthai] [debug] Library information - version: 2.30.0, commit: e0f6b52d048ef7ceac2ecd44deb2e161dbb97699 from 2025-03-18 12:44:00 +0100, build: 2025-03-18 11:51:40 +0000, libusb enabled: true > > [2026-02-27 20:16:17.584] [depthai] [debug] Environment 'XLINK_LEVEL' set to 'debug' > > [2026-02-27 20:16:17.584] [depthai] [debug] Initialize - finished > > [2026-02-27 20:16:17.812] [depthai] [debug] Resources - Archive 'depthai-bootloader-fwp-0.0.28.tar.xz' open: 5ms, archive read: 231ms > > [2026-02-27 20:16:18.884] [depthai] [debug] Resources - Archive 'depthai-device-fwp-a62b2ccb0bc493c2fb41694cb81c08887be24c52.tar.xz' open: 5ms, archive read: 1309ms > > QObject::moveToThread: Current thread (0x3dc5ad30) is not the object's thread (0x3dfd93d0). > > Cannot move to target thread (0x3dc5ad30) > > qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "/home/pi/.local/lib/python3.11/site-packages/cv2/qt/plugins" even though it was found. > > This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem. > > Available platform plugins are: xcb, eglfs, linuxfb, minimal, minimalegl, offscreen, vnc, wayland-egl, wayland, wayland-xcomposite-egl, wayland-xcomposite-glx. > > Stack trace (most recent call last): > > \#25 Object "[0xffffffffffffffff]", at 0xffffffffffffffff, in > > \#24 Object "python3", at 0x5cffef, in _start > > \#23 Object "/lib/aarch64-linux-gnu/libc.so.6", at 0x7f9f267857, in __libc_start_main > > \#22 Object "/lib/aarch64-linux-gnu/libc.so.6", at 0x7f9f26777f, in > > \#21 Object "python3", at 0x5d0153, in Py_BytesMain > > \#20 Object "python3", at 0x60631b, in Py_RunMain > > \#19 Object "python3", at 0x60806f, in _PyRun_AnyFileObject > > \#18 Object "python3", at 0x608307, in _PyRun_SimpleFileObject > > \#17 Object "python3", at 0x60875f, in > > \#16 Object "python3", at 0x5f7bcf, in > > \#15 Object "python3", at 0x5fafa7, in > > \#14 Object "python3", at 0x4a0b5f, in PyEval_EvalCode > > \#13 Object "python3", at 0x4aa23b, in _PyEval_EvalFrameDefault > > \#12 Object "python3", at 0x4944d7, in _PyObject_MakeTpCall > > \#11 Object "/usr/lib/python3/dist-packages/PyQt5/sip.cpython-311-aarch64-linux-gnu.so", at 0x7f8859afa7, in > > \#10 Object "/usr/lib/python3/dist-packages/PyQt5/QtWidgets.abi3.so", at 0x7f893fff0b, in > > \#9 Object "/usr/lib/python3/dist-packages/PyQt5/QtWidgets.abi3.so", at 0x7f893ffe23, in > > \#8 Object "/lib/aarch64-linux-gnu/libQt5Widgets.so.5", at 0x7f79561c87, in QApplicationPrivate::init() > > \#7 Object "/lib/aarch64-linux-gnu/libQt5Gui.so.5", at 0x7f804d24eb, in QGuiApplicationPrivate::init() > > \#6 Object "/lib/aarch64-linux-gnu/libQt5Core.so.5", at 0x7f81b03ebf, in QCoreApplicationPrivate::init() > > \#5 Object "/lib/aarch64-linux-gnu/libQt5Gui.so.5", at 0x7f804cf297, in QGuiApplicationPrivate::createEventDispatcher() > > \#4 Object "/lib/aarch64-linux-gnu/libQt5Gui.so.5", at 0x7f804cee33, in QGuiApplicationPrivate::createPlatformIntegration() > > \#3 Object "/lib/aarch64-linux-gnu/libQt5Core.so.5", at 0x7f818ede3b, in QMessageLogger::fatal(char const\*, ...) const > > \#2 Object "/lib/aarch64-linux-gnu/libc.so.6", at 0x7f9f2674bb, in abort > > \#1 Object "/lib/aarch64-linux-gnu/libc.so.6", at 0x7f9f27a76b, in gsignal > > \#0 Object "/lib/aarch64-linux-gnu/libc.so.6", at 0x7f9f2c09d0, in > > Aborted (Signal sent by tkill() 2988 1000) > > Aborted > > Also, this camera is physically deployed at the client’s factory. If flashing the new image is required, would I be able to do that remotely? Thanks again and looking forward to hearing from you, Best regards

@"OskarSonc"#p33231 I tried running the command Offscreen and I am getting this error. ``` > QT_QPA_PLATFORM=offscreen DEPTHAI_LEVEL=debug XLINK_LEVEL=debug python3 cam_test.py > > [2026-02-27 20:33:55.125] [depthai] [debug] Python bindings - version: 2.30.0.0 from build: 2025-03-18 13:32:35 +0000 > > [2026-02-27 20:33:55.125] [depthai] [debug] Library information - version: 2.30.0, commit: e0f6b52d048ef7ceac2ecd44deb2e161dbb97699 from 2025-03-18 12:44:00 +0100, build: 2025-03-18 11:51:40 +0000, libusb enabled: true > > [2026-02-27 20:33:55.143] [depthai] [debug] Environment 'XLINK_LEVEL' set to 'debug' > > [2026-02-27 20:33:55.143] [depthai] [debug] Initialize - finished > > [2026-02-27 20:33:55.370] [depthai] [debug] Resources - Archive 'depthai-bootloader-fwp-0.0.28.tar.xz' open: 5ms, archive read: 238ms > > E: [global] [ 435956] [Thread (pooled)] getLibusbDeviceMxId:411 libusb_bulk_transfer (Input/Output Error), transfer: 0, expected: 9 > > D: [global] [ 435956] [Thread (pooled)] getUSBDevices:171 getLibusbDeviceMxId returned: Input/Output Error > > [2026-02-27 20:33:56.429] [depthai] [debug] Resources - Archive 'depthai-device-fwp-a62b2ccb0bc493c2fb41694cb81c08887be24c52.tar.xz' open: 5ms, archive read: 1297ms > > [2026-02-27 20:33:56.481] [depthai] [warning] skipping X_LINK_UNBOOTED device having name "2.1" > > This plugin does not support propagateSizeHints() > > E: [global] [ 438430] [Thread (pooled)] getLibusbDeviceMxId:411 libusb_bulk_transfer (Input/Output Error), transfer: 0, expected: 9 > > E: [global] [ 438439] [Thread (pooled)] getLibusbDeviceMxId:411 libusb_bulk_transfer (Input/Output Error), transfer: 0, expected: 9 > > E: [global] [ 438442] [Thread (pooled)] getLibusbDeviceMxId:411 libusb_bulk_transfer (Input/Output Error), transfer: 0, expected: 9 > > E: [global] [ 438450] [Thread (pooled)] getLibusbDeviceMxId:411 libusb_bulk_transfer (Input/Output Error), transfer: 0, expected: 9 > > D: [global] [ 438450] [Thread (pooled)] getUSBDevices:171 getLibusbDeviceMxId returned: Input/Output Error > > [2026-02-27 20:33:58.953] [depthai] [warning] skipping X_LINK_UNBOOTED device having name "2.1" > > E: [global] [ 440933] [Thread (pooled)] getLibusbDeviceMxId:411 libusb_bulk_transfer (Input/Output Error), transfer: 0, expected: 9 > > E: [global] [ 440941] [Thread (pooled)] getLibusbDeviceMxId:411 libusb_bulk_transfer (Input/Output Error), transfer: 0, expected: 9 > > E: [global] [ 440961] [Thread (pooled)] getLibusbDeviceMxId:411 libusb_bulk_transfer (Input/Output Error), transfer: 0, expected: 9 ``` I hope this helps in isolating the issue and finding a resolution. Best regards,

Hm I have seen similar problems here: https://discuss.luxonis.com/d/6243-cm4-connection-issues/18 If you run `lsusb` does Pi see the device? And what do you get when running this: ``` import depthai as dai dai.Device.getAllAvailableDevices() ``` Also try running this: `DEPTHAI_LEVEL=debug XLINK_LEVEL=debug python3 ~/depthai-python/examples/host_side/device_information.py`

Hi @"OskarSonc"#p33251 Thank you for getting back to me. This is the output when I run `lsusb:` ``` pi@tallyvision-camera-0029:~ $ lsusb Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 003 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 002 Device 002: ID 03e7:2485 Intel Movidius MyriadX Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub ``` It seems like I see the following device `Intel Movidius MyriadX`, is this device you are referring to? After running the following code: ``` import depthai as dai dai.Device.getAllAvailableDevices() ``` It returns null with the warning shown below: ``` pi@tallyvision-camera-0029:~ $ python3 test.py [2026-03-02 19:29:44.161] [depthai] [warning] skipping X_LINK_UNBOOTED device having name "2.1" ``` I also tried running this command: `DEPTHAI_LEVEL=debug XLINK_LEVEL=debug python3 ~/depthai-python/examples/host_side/device_information.py` This is the output I get: ``` pi@tallyvision-camera-0029:~ $ DEPTHAI_LEVEL=debug XLINK_LEVEL=debug python3 ~/depthai-python/examples/host_side/device_information.py [2026-03-02 19:36:42.544] [depthai] [debug] Python bindings - version: 2.30.0.0 from build: 2025-03-18 13:32:35 +0000 [2026-03-02 19:36:42.545] [depthai] [debug] Library information - version: 2.30.0, commit: e0f6b52d048ef7ceac2ecd44deb2e161dbb97699 from 2025-03-18 12:44:00 +0100, build: 2025-03-18 11:51:40 +0000, libusb enabled: true [2026-03-02 19:36:42.561] [depthai] [debug] Environment 'XLINK_LEVEL' set to 'debug' [2026-03-02 19:36:42.561] [depthai] [debug] Initialize - finished Searching for all available devices... E: [global] [ 202599] [python3] getLibusbDeviceMxId:411 libusb_bulk_transfer (Input/Output Error), transfer: 0, expected: 9 E: [global] [ 202605] [python3] getLibusbDeviceMxId:411 libusb_bulk_transfer (Input/Output Error), transfer: 0, expected: 9 D: [global] [ 202606] [python3] getUSBDevices:171 getLibusbDeviceMxId returned: Input/Output Error [2026-03-02 19:36:42.770] [depthai] [debug] Resources - Archive 'depthai-bootloader-fwp-0.0.28.tar.xz' open: 5ms, archive read: 219ms [2026-03-02 19:36:43.113] [depthai] [warning] skipping X_LINK_UNBOOTED device having name "2.1" Couldn't find any available devices. [2026-03-02 19:36:43.810] [depthai] [debug] Resources - Archive 'depthai-device-fwp-a62b2ccb0bc493c2fb41694cb81c08887be24c52.tar.xz' open: 5ms, archive read: 1259ms ``` It seems like the issue is that the Pi can't find the camera device. How can we fix this issue? Also, I don't have the camera with me and it is in the factory, so any fix that I am able to do is restricted to being performed while I am ssh'd into the device. Thank you and looking forward to hearing from you. Best Regards,

@"OskarSonc"#p33251 Just following up on the last message. Thank you and looking forward to hearing from you! Best regards,

@"GurdeepakSidhu"#p33271 try running this two commans: `sudo ln -sf renesas/K2026.mem /lib/firmware/renesas_usb_fw.mem ` `echo -n 0000:01:00.0 | sudo tee /sys/bus/pci/drivers/xhci-pci-renesas/bind ` This worked for most people. If not my next suggestion would be to try to try re-seating the SOM or reflashing with newer image, but for that you will need a device. Thanks

OAK-D-CM4-POE Failing to Boot Device – "Failed to boot device!" Error

OskarSonc

Hey GurdeepakSidhu - we’ve seen this exact issue a few times before. From what we’ve been able to tell, it appears to be related to a Renesas/Raspberry Pi driver issue, which unfortunately is difficult for us to diagnose or support directly.

That said, a few users were able to get things working again by power cycling the device and then rerunning these two commands:

sudo ln -sf renesas/K2026.mem /lib/firmware/renesas_usb_fw.mem
echo -n 0000:01:00.0 | sudo tee /sys/bus/pci/drivers/xhci-pci-renesas/bind

Sorry for the inconvenience. Since this seems to be tied to the Renesas/Raspberry Pi driver stack, our ability to help is limited. This is also one of the reasons we’ve moved toward our own camera lineup(the new OAK-D series, RVC4 etc) without relying on Raspberry Pi units, and why we generally recommend that path for most customers.

Thanks,
Oskar

« Previous Page