Can't Get Past IMX519 Camera Install Steps for OctoPrint on Debian 11

Raspberry Pi Cameras
1

Hi, hoping someone can help me out because I’m stuck. I’m trying to get an Arducam IMX519 16MP Autofocus camera working on a Raspberry Pi running Debian GNU/Linux 11 (bullseye). I’ve been following the directions on the Arducam website but I can’t get through the install process at all — it just never completes for me. Honestly the camera has never worked, not once since I got it.

What I actually want in the end is to use this camera with OctoPrint. I’ve looked all over the internet for a solution and had zero luck. Can anyone tell me how to get past these steps?

2

Welcome! Let’s figure out where it’s breaking. A few quick things first so we know what we’re dealing with:

  1. What’s the exact output of libcamera-hello --list-cameras?
  2. What does cat /boot/config.txt | grep -iE 'imx|camera|i2c' show?
  3. Which step of the install process is it that blocks you — the driver install, or the part where you verify the camera is detected?

Post those and we’ll go from there.

3

Sure, here’s what I get.

$ libcamera-hello --list-cameras
No cameras available!

and:

$ cat /boot/config.txt | grep -iE 'imx|camera|i2c'
camera_auto_detect=1

Model is IMX519 16MP Autofocus. I get stuck around the part where it wants me to verify the camera is detected — that’s where “No cameras available” shows up and I can’t go any further.

4

I added those two lines, saved, and rebooted. Still the same result:

$ libcamera-hello --list-cameras
No cameras available!

But dmesg is now complaining about something:

$ dmesg | grep -iE 'imx|camera|i2c'
[    2.101234] imx519 10-001a: probe failed, -5

So it looks like it’s trying to load the driver but failing. Not sure what -5 means here.

5

Good — that’s actually useful. -5 is an I/O error, which almost always means the driver loaded but it can’t talk to the sensor over I2C. So this is either a ribbon cable / port problem or the sensor isn’t reachable on the bus.

Let’s check a couple of things:

  1. Enable I2C if it isn’t already: sudo raspi-config → Interface Options → I2C → enable (or check dtparam=i2c_arm=on in config.txt).
  2. Scan the bus the camera sits on:
sudo apt install -y i2c-tools
sudo i2cdetect -y 10

The IMX519 should show up at address 0x1a. Post what you see.

6

Here’s the scan:

$ sudo i2cdetect -y 10
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:                         -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- UU -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
...

No device at 0x1a at all. So the bus is up but the camera isn’t responding on it. That matches the probe failure I guess.

7

OK so I reseated the ribbon cable on both the camera end and the Pi end, made sure it’s the correct CSI port, and tried the shorter cable that came in the box too. Still nothing:

$ sudo i2cdetect -y 10
... 10: -- -- -- -- -- -- -- -- -- -- UU -- -- -- -- --

and dmesg still gives the same imx519 10-001a: probe failed, -5. The cable orientation looks right to me (metal contacts facing the board) but I’m not 100% sure on the camera connector. Anything else I can try on the cabling side?

8

If you’ve reseated both ends and tried a second cable, the physical connection is likely fine. At this point I want to rule out a mismatch between the overlay/driver and the libcamera build, which is a very common cause on bullseye.

Can you run these and paste the output?

libcamera-hello --version
uname -a
lsmod | grep -i imx
dpkg -l | grep -i libcamera

Also — did you install the Pivariety/libcamera packages from Arducam’s installer, or is this the stock libcamera that shipped with the OS? If stock packages are still present they can conflict with the IMX519 overlay.

9

Here you go:

$ libcamera-hello --version
rpicam-apps v1.1.0 (or something similar, libcamera 0.0.x)

$ uname -a
Linux raspberrypi 5.15.61-v8+ #1579 SMP PREEMPT ... aarch64 GNU/Linux

$ lsmod | grep -i imx
(no output)

$ dpkg -l | grep -i libcamera
ii  libcamera0:arm64    0.0.x  ...

I honestly don’t remember which installer I used — probably the one from the guide, but it might be the default that came with the OS. Does that matter?

10

It matters a lot, yes. The stock libcamera won’t talk to the IMX519 overlay — you need the Arducam build that’s matched to the driver. Let’s clean it up and reinstall from the official script:

wget -O install_pivariety_pkgs.sh https://github.com/ArduCAM/Arducam-Pivariety-V4L2-Driver/releases/download/install_script/install_pivariety_pkgs.sh
chmod +x install_pivariety_pkgs.sh
./install_pivariety_pkgs.sh -p libcamera_dev
./install_pivariety_pkgs.sh -p libcamera_apps

Then reboot and re-check libcamera-hello --list-cameras. Also, for the OctoPrint side, here’s the guide we point people to: Redirecting... — it walks through how the camera is set up and what OctoPrint needs. We’ll get to that once the camera is detected.

11

OK that made progress! After re-running the installer and rebooting:

$ libcamera-hello --list-cameras
0 : imx519 [4656x3496] (/base/soc/i2c0mux/i2c@1/imx519@1a)

And libcamera-still -o test.jpg actually saves a picture now, so the sensor is alive. So the detection problem is fixed.

But OctoPrint still can’t use it. When I add it in the webcam settings the feed is just broken/blank. Any idea what I’m doing wrong there?

12

Nice, that confirms the root of the detection problem: the stock libcamera conflicting with the IMX519 overlay. Now the remaining piece is that OctoPrint doesn’t speak libcamera directly — it expects an MJPEG stream over HTTP, so you have to bridge the camera with something like libcamera-vid piped into mjpg-streamer (or a libcamera-aware OctoPrint plugin).

Quick test to confirm the stream side works:

libcamera-vid -t 0 --inline --width 1280 --height 720 -o - | ...

or point an MJPEG-capable viewer at the camera first before wiring it into OctoPrint. If that stream comes up, the OctoPrint webcam URL just needs to match it.

So, to summarize where we are: camera detection is solved (overlay + matched libcamera build). The outstanding item is getting OctoPrint to consume the stream, since its built-in webcam support doesn’t talk to libcamera natively. Follow the OctoPrint guide at Redirecting... and post back the exact command/URL you’re feeding OctoPrint if the feed is still blank — we can tune it from there.