Camera not detected despite being plugged in

[ZPMMaker]

I have a dozen remote RPi ZeroW's set up spread across a few countries, which I can control via SSH. They all have the RPi camera module v2 plugged in and have operated for about two years. They all run the same script every five minutes, which takes a photo and sends it to my server.

I did an apt-get update && apt-get upgrade about twelve hours ago on all of the systems.

Most of the systems still work fine, with my code unchanged. However, three systems are now having different issues, despite being set-up identically, and running the exact same software.


I have a separate post about two of the three problematic systems (here: https://www.raspberrypi.org/forums/view ... 8&t=262647), but in this post I'd like to troubleshoot the issue with one of the three systems, which is unable to use the camera...

I have a fairly complicated script, but the gist of it is that it uses raspistill to take a photo. So I decided to test raspistill itself with the minimum options:

Code: Select all

$ raspistill -o image.jpg
mmal: Cannot read camera info, keeping the defaults for OV5647
mmal: mmal_vc_component_create: failed to create component 'vc.ril.camera' (1:ENOMEM)
mmal: mmal_component_create_core: could not create component 'vc.ril.camera' (1)
mmal: Failed to create camera component
mmal: main: Failed to create camera component
mmal: Camera is not detected. Please check carefully the camera module is installed correctly

I understand this error usually indicates the ribbon cable is disconnected. The system is inside a locked plastic enclosure mounted on a rooftop. I doubt anyone has climbed up and disconnected the camera ribbon cable from the camera itself. They are sealed containers so I doubt any bug could've got in and eaten the ribbon cable. I have asked a local to check, and he reports that there is no physical damage to the enclosures, so presumably the Pi itself and the ribbon cable are fine.

I also understand this error could mean a lack of memory. But I ran my script while viewing the output of htop, which showed a barely-noticeable increase in memory usage (it hovered around 80MB used, and an awful lot more free/available). So it's not an out-of-memory issue.

I tried running memtester to check the memory, and it passed the tests.

I haven't changed my code at all and it's working perfectly on all my other systems so I know it isn't my code. To be sure, I deleted the code running on the Pi and downloaded a fresh copy from my git repo.

I have tried rebooting, and also completely powering down and having someone unplug and re-plug the power in to turn it back on, but that didn't help.

Clutching at straws, I opted to run sudo rpi-update (I know you're not meant to do it normally, but I felt I had exhausted every other option). That ran and no errors appeared. I then rebooted as it instructed, and then re-ran the above raspistill command, but that resulted in the same error again.

I also tried uninstalling and then reinstalling raspistill:

Code: Select all

sudo apt remove libraspberrypi-bin

Code: Select all

sudo apt-get install -y libraspberrypi-bin

...and got the same error when trying to run raspistill.

I also tried sudo apt purge libraspberrypi-bin (to remove config files) and then reinstalling, but again, same error.

I have also checked raspi-config; the camera interface is definitely enabled, and the graphics memory is set to 200MB, which is the same settings as all the other systems.

Last night I tried to install python 3.5.3 on all my systems. It worked on all but two (I can't remember what the error message said) - not this particular system, though. For the two where it didn't work, I had to uninstall python3 and then reinstalled it and it seemed to work. But again, that wasn't this system, so I don't think that's related.

The power logs I have show 100% uptime and no sudden loss of power for the system, so I don't think it is a corrupt SD card, although I haven't done any tests to prove such...

Can anyone please suggest any possible solutions or ways of at least diagnosing what the problem might be?

Thanks in advance.
David



Some potentially-useful diagnostics:

Code: Select all

$ vcgencmd get_camera
supported=1 detected=0

Code: Select all

$ vcgencmd version
Jan 16 2020 16:00:12
Copyright (c) 2012 Broadcom
version a15d66d3615281e13110f10573bf580c4d1156fa (clean) (release) (start_x)

Code: Select all

$ sudo raspi-gpio get
BANK0 (GPIO 0 to 27):
GPIO 0: level=1 fsel=0 func=INPUT
GPIO 1: level=1 fsel=0 func=INPUT
GPIO 2: level=1 fsel=0 func=INPUT
GPIO 3: level=1 fsel=0 func=INPUT
GPIO 4: level=1 fsel=0 func=INPUT
GPIO 5: level=1 fsel=0 func=INPUT
GPIO 6: level=1 fsel=0 func=INPUT
GPIO 7: level=1 fsel=0 func=INPUT
GPIO 8: level=1 fsel=0 func=INPUT
GPIO 9: level=0 fsel=0 func=INPUT
GPIO 10: level=0 fsel=0 func=INPUT
GPIO 11: level=0 fsel=0 func=INPUT
GPIO 12: level=0 fsel=0 func=INPUT
GPIO 13: level=0 fsel=0 func=INPUT
GPIO 14: level=1 fsel=4 alt=0 func=TXD0
GPIO 15: level=1 fsel=4 alt=0 func=RXD0
GPIO 16: level=0 fsel=0 func=INPUT
GPIO 17: level=0 fsel=0 func=INPUT
GPIO 18: level=0 fsel=0 func=INPUT
GPIO 19: level=0 fsel=0 func=INPUT
GPIO 20: level=0 fsel=0 func=INPUT
GPIO 21: level=0 fsel=0 func=INPUT
GPIO 22: level=0 fsel=0 func=INPUT
GPIO 23: level=0 fsel=0 func=INPUT
GPIO 24: level=0 fsel=0 func=INPUT
GPIO 25: level=0 fsel=0 func=INPUT
GPIO 26: level=0 fsel=0 func=INPUT
GPIO 27: level=0 fsel=0 func=INPUT
BANK1 (GPIO 28 to 45):
GPIO 28: level=1 fsel=4 alt=0 func=SDA0
GPIO 29: level=1 fsel=4 alt=0 func=SCL0
GPIO 30: level=0 fsel=1 func=OUTPUT
GPIO 31: level=0 fsel=1 func=OUTPUT
GPIO 32: level=1 fsel=0 func=INPUT
GPIO 33: level=1 fsel=0 func=INPUT
GPIO 34: level=1 fsel=7 alt=3 func=SD1_CLK
GPIO 35: level=1 fsel=7 alt=3 func=SD1_CMD
GPIO 36: level=1 fsel=7 alt=3 func=SD1_DAT0
GPIO 37: level=1 fsel=7 alt=3 func=SD1_DAT1
GPIO 38: level=1 fsel=7 alt=3 func=SD1_DAT2
GPIO 39: level=1 fsel=7 alt=3 func=SD1_DAT3
GPIO 40: level=0 fsel=1 func=OUTPUT
GPIO 41: level=1 fsel=1 func=OUTPUT
GPIO 42: level=0 fsel=0 func=INPUT
GPIO 43: level=1 fsel=4 alt=0 func=GPCLK2
GPIO 44: level=0 fsel=1 func=OUTPUT
GPIO 45: level=0 fsel=1 func=OUTPUT
BANK2 (GPIO 46 to 53):
GPIO 46: level=1 fsel=0 func=INPUT
GPIO 47: level=1 fsel=1 func=OUTPUT
GPIO 48: level=0 fsel=4 alt=0 func=SD0_CLK
GPIO 49: level=1 fsel=4 alt=0 func=SD0_CMD
GPIO 50: level=1 fsel=4 alt=0 func=SD0_DAT0
GPIO 51: level=1 fsel=4 alt=0 func=SD0_DAT1
GPIO 52: level=1 fsel=4 alt=0 func=SD0_DAT2
GPIO 53: level=1 fsel=4 alt=0 func=SD0_DAT3

Code: Select all

$ uname -a
Linux v1iOTS3 4.19.95+ #1292 Thu Jan 16 15:39:51 GMT 2020 armv6l GNU/Linux

Code: Select all

$ cat /etc/*-release
PRETTY_NAME="Raspbian GNU/Linux 9 (stretch)"
NAME="Raspbian GNU/Linux"
VERSION_ID="9"
VERSION="9 (stretch)"
VERSION_CODENAME=stretch
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"

Code: Select all

$ cat /proc/cpuinfo
processor       : 0
model name      : ARMv6-compatible processor rev 7 (v6l)
BogoMIPS        : 697.95
Features        : half thumb fastmult vfp edsp java tls
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x0
CPU part        : 0xb76
CPU revision    : 7

Hardware        : BCM2835
Revision        : 9000c1
Serial          : 00000000674f94fe
Model           : Raspberry Pi Zero W Rev 1.1

[Pekka]

I don't have a solution, but I have the very same problem with one of my new Zero Ws. I ordered two and equipped them with the card with the same image running Raspbian Lite with mjpg_streamer. Between the two I only changed the hostname and the static IP. One runs perfectly OK, the other one doesn't detect the camera (RPi cam v2). The same camera works in several other RPis that I have, so I swapped the faulty one with a Zero W I had before and use the faulty one in the application not needing the camera, so it's not really a problem for me. I never found the cause, though. On the fauly Pi vcgencmd get_camera also gives "supported=1 detected=0". The HW doesn't have any visually detectable faults. I tried swapping cables and cameras to no avail.

[ZPMMaker]

I don't have a solution, but I have the very same problem with one of my new Zero Ws. I ordered two and equipped them with the card with the same image running Raspbian Lite with mjpg_streamer. Between the two I only changed the hostname and the static IP. One runs perfectly OK, the other one doesn't detect the camera (RPi cam v2). The same camera works in several other RPis that I have, so I swapped the faulty one with a Zero W I had before and use the faulty one in the application not needing the camera, so it's not really a problem for me. I never found the cause, though. On the fauly Pi vcgencmd get_camera also gives "supported=1 detected=0". The HW doesn't have any visually detectable faults. I tried swapping cables and cameras to no avail.

Out of interest, how long ago was that? I’m just wondering if you might’ve had the same version of whatever software I updated just before the issue started on my systems...

Thanks

[scruss]

I understand this error usually indicates the ribbon cable is disconnected. The system is inside a locked plastic enclosure mounted on a rooftop. I doubt anyone has climbed up and disconnected the camera ribbon cable from the camera itself. They are sealed containers so I doubt any bug could've got in and eaten the ribbon cable. I have asked a local to check, and he reports that there is no physical damage to the enclosures, so presumably the Pi itself and the ribbon cable are fine.

Sealed, as in hermetically? Enclosures tend to “breathe” with daily temperature and pressure changes. In doing so they can aspirate water into the enclosure from any source: morning dew, through outdoor power cables (even through most IPxx glands), standing snow/ice … Annoyingly, this water often can't get back out, so it can slowly build up. I don't know how many remote weather station boxes I've opened for maintenance that released a small tidal wave of water.

Bugs can be a hidden challenge; ants especially. I've had a couple of weather stations completely taken over by ants as nests. One in Jamaica even had ants chew through DB25-like serial connectors to get into the sealed logger inside a steel can. Both stations looked fine from the outside. By the time this happened, though, nothing electronic was still working.

A couple of years outside without maintenance is not bad, frankly. UV exposure will degrade many plastics in that time. It sounds to me like thermal cycling could have popped the camera connector open, or environmental exposure has cracked a ribbon cable somewhere. Since you've tried everything with software (except maybe fsck: segfaults can come from corrupted binaries and libraries) it's most likely the hardware.

[ZPMMaker]

I understand this error usually indicates the ribbon cable is disconnected. The system is inside a locked plastic enclosure mounted on a rooftop. I doubt anyone has climbed up and disconnected the camera ribbon cable from the camera itself. They are sealed containers so I doubt any bug could've got in and eaten the ribbon cable. I have asked a local to check, and he reports that there is no physical damage to the enclosures, so presumably the Pi itself and the ribbon cable are fine.

Sealed, as in hermetically? Enclosures tend to “breathe” with daily temperature and pressure changes. In doing so they can aspirate water into the enclosure from any source: morning dew, through outdoor power cables (even through most IPxx glands), standing snow/ice … Annoyingly, this water often can't get back out, so it can slowly build up. I don't know how many remote weather station boxes I've opened for maintenance that released a small tidal wave of water.

Bugs can be a hidden challenge; ants especially. I've had a couple of weather stations completely taken over by ants as nests. One in Jamaica even had ants chew through DB25-like serial connectors to get into the sealed logger inside a steel can. Both stations looked fine from the outside. By the time this happened, though, nothing electronic was still working.

A couple of years outside without maintenance is not bad, frankly. UV exposure will degrade many plastics in that time. It sounds to me like thermal cycling could have popped the camera connector open, or environmental exposure has cracked a ribbon cable somewhere. Since you've tried everything with software (except maybe fsck: segfaults can come from corrupted binaries and libraries) it's most likely the hardware.

Sorry, when I say "plastic enclosure", I mean "cheap Chinese take-away plastic container".
(The goal for this project was a MVP at the lowest possible cost to demonstrate if the idea would at least work, so it's definitely a low-cost option. For the next version, I intend to make a custom-designed hermetically-sealed enclosure.

Interesting to read your experiences with water - thanks for the wisdom! I was planning on using a Rosahl MDL5 dehumidifier in my next version system to take the moisture out - https://www.micro-dehumidifier.com/products/membranes/ - I have been prototyping with one for the last year or so and it seems to work very well. I was also planning on using Rust-oleum LeakSeal self-fusing silicone tape and/or Rust-oleum LeakSeal flexible rubber coating (sprays on, forms a seal) to seal the entire enclosure. I was hoping that a decent seal, plus the dehumidifier, would keep things dry inside. I also am planning on using heaters and coolers to keep the temperature fairly constant.

To deal with bugs, I was planning on using an ultrasonic bug repeller.

But certainly, the system I'm current running is literally just the RPi Zero inside the RPi Zero official camera case, which is then put inside a transparent plastic container, and that's it.

My grandfather used to deal with electronics (he manufactured and imported and exported radio parts back in the 1960s) and he once advised me to "pot the electronics". From what I can gather (he's now dead, so I can't ask him for clarification), this means putting the RPi board inside a resin and having the resin set into a solid block, thereby sealing the Pi off to prevent any physical damage (and it would also prevent movement of cables etc) (way back a few years ago when I was discussing this project with him, I was thinking about burying some sensors. The idea of burying the sensors is long gone, no longer necessary, but he was giving me that advice based on my burying things and wanting to keep bugs etc. out). I haven't tried this yet but I may give it a go. I imagine that could be problematic for the thermals though, as the Pi would have no way of dissipating heat. Perhaps I could use a very long heatsink that sticks up and out of the resin block...

It sounds to me like thermal cycling could have popped the camera connector open, or environmental exposure has cracked a ribbon cable somewhere.

That's certainly a possibility. However, it's odd (and really unlikely) that it happened at the exact same time as doing apt-get upgrade, and that same thing caused problems with two other Pi's. Actually, interesting you should mention seg-faults...

maybe fsck: segfaults can come from corrupted binaries and libraries

The other two faulty pi's are able to use their cameras just fine. However, they're getting a seg fault when using cURL. I am trying to troubleshoot that issue over in this thread: https://www.raspberrypi.org/forums/view ... 4#p1600224

The latest comment I made in that discussion details how I was testing the SD card for possible corruption, but it found no bad sectors. Nonetheless, whenever I run curl on those two Pi's (to send data to my server), I get a seg-fault.

maybe fsck: segfaults can come from corrupted binaries and libraries

Would you mind please explaining how I could use fsck to find out if there are corrupted binaries and libraries? I remain hopeful this is a software issue rather than a hardware one...

Thanks for your help and advice.
Dave

[pi-anazazi]

I "cured" a raspi 2 with buster by turning on fsck on each boot and enabeling permanent logs (for better debugging... sudo mkdir /var/log/journal), see here

https://www.raspberrypi.org/forums/view ... &p=1591076

...added to /boot/cmdline.txt

Code: Select all

fsck.repair=yes

and enabled fsck on each boot

Code: Select all

sudo tune2fs -c 1 /dev/mmcblk0p2

[pi-anazazi]

btw:

Design tipppp: I have one outdoor cam, only the cam module is outdoor, connected through closed window to raspi with a long cam cable (you can buy them up to 2 meters in length).

[ZPMMaker]

I "cured" a raspi 2 with buster by turning on fsck on each boot and enabeling permanent logs (for better debugging... sudo mkdir /var/log/journal), see here

https://www.raspberrypi.org/forums/view ... &p=1591076

...added to /boot/cmdline.txt

Code: Select all

fsck.repair=yes

and enabled fsck on each boot

Code: Select all

sudo tune2fs -c 1 /dev/mmcblk0p2

Thanks for that suggestion. After running the last command, I rebooted, but the Pi booted back up again in the normal amount of time, and the raspistill command is still failing with the same error message.

By chance, a user called jojopi recommended in a different discussion (https://www.raspberrypi.org/forums/view ... 9#p1600939)that I run debsums -c to check for files on a different RPi that don't have the right checksums. (I'm having a separate issue on two other RPi's running the curl command).

Anyway, I decided to run this command on this current Pi with the faulty camera:

Code: Select all

$ sudo debsums -c
/opt/vc/bin/dtoverlay
/opt/vc/bin/dtoverlay-post
/opt/vc/bin/dtoverlay-pre
/opt/vc/bin/edidparser
/opt/vc/bin/mmal_vc_diag
/opt/vc/bin/raspistill
/opt/vc/bin/raspivid
/opt/vc/bin/raspividyuv
/opt/vc/bin/raspiyuv
/opt/vc/bin/vcdbg
/opt/vc/include/bcm_host.h
/opt/vc/include/interface/vctypes/vc_image_structs.h
/opt/vc/lib/libEGL_static.a
/opt/vc/lib/libGLESv2_static.a
/opt/vc/lib/libdebug_sym_static.a
/opt/vc/lib/libkhrn_client.a
/opt/vc/lib/libkhrn_static.a
/opt/vc/lib/libvchostif.a
/opt/vc/lib/libvcilcs.a
/opt/vc/lib/libbcm_host.so
/opt/vc/lib/libdebug_sym.so
/opt/vc/lib/libdtovl.so
/opt/vc/lib/libmmal_core.so
/opt/vc/lib/libmmal_vc_client.so
/opt/vc/lib/libvcsm.so
/boot/bootcode.bin
/boot/fixup.dat
/boot/fixup_cd.dat
/boot/fixup_db.dat
/boot/fixup_x.dat
/boot/start.elf
/boot/start_cd.elf
/boot/start_db.elf
/boot/start_x.elf
/boot/bcm2708-rpi-b-plus.dtb
/boot/bcm2708-rpi-b.dtb
/boot/bcm2708-rpi-cm.dtb
/boot/bcm2708-rpi-zero-w.dtb
/boot/bcm2708-rpi-zero.dtb
/boot/bcm2709-rpi-2-b.dtb
/boot/bcm2710-rpi-3-b-plus.dtb
/boot/bcm2710-rpi-3-b.dtb
/boot/bcm2710-rpi-cm3.dtb
/boot/kernel.img
/boot/kernel7.img
/boot/overlays/README
/boot/overlays/dht11.dtbo
/boot/overlays/gpio-shutdown.dtbo
/boot/overlays/i2c-rtc.dtbo
/boot/overlays/i2c-sensor.dtbo
/boot/overlays/i2c3.dtbo
/boot/overlays/i2c4.dtbo
/boot/overlays/i2c5.dtbo
/boot/overlays/i2c6.dtbo
/boot/overlays/mcp23017.dtbo
/boot/overlays/mcp342x.dtbo
/boot/overlays/pitft35-resistive.dtbo
/boot/overlays/sc16is752-i2c.dtbo
/boot/overlays/spi3-1cs.dtbo
/boot/overlays/spi3-2cs.dtbo
/boot/overlays/spi4-1cs.dtbo
/boot/overlays/spi4-2cs.dtbo
/boot/overlays/spi5-1cs.dtbo
/boot/overlays/spi5-2cs.dtbo
/boot/overlays/spi6-1cs.dtbo
/boot/overlays/spi6-2cs.dtbo
/boot/overlays/uart2.dtbo
/boot/overlays/uart3.dtbo
/boot/overlays/uart4.dtbo
/boot/overlays/uart5.dtbo
/usr/bin/rpi-update

Code: Select all

dpkg -S /opt/vc/bin/raspistill

Code: Select all

sudo apt install --reinstall libraspberrypi-bin

Code: Select all

raspistill -o test.jpg

...this again failed, with the same error.

I also did

Code: Select all

sudo apt install --reinstall rpi-update

as I noticed that was in the above list. I then re-ran sudo rpi-update, but it said that my firmware was up-to-date.

There are a lot of other files in that debsums -c list; I will reinstall them tomorrow and will let you know how I go.

Thanks for your help.
Dave

[Pekka]

Out of interest, how long ago was that? I’m just wondering if you might’ve had the same version of whatever software I updated just before the issue started on my systems...

My four Zero Ws are all running the same version of Raspbian Stretch Lite from early 2018 with kernel 4.19.93 and MJPG Streamer v2.0 (fork by jacksonliam with raspicam support) started as systemd service. The only difference in software between them is a static IP set in /etc/dhcpcd.conf and the hostname set in wherever it eeds to be set. Otherwise they are exactly identical. Each of them has a Camera V2 aconnected an they only receive occasional Stretch updates. For a test I have just run apt-get update && apt-get upgrade on all of them and they all still work as before. The one failing to recognise the camera has been ordered about a month ago and has serial # 0000000046f996f4. Another (working) one from the same order has serial # 0000000096263505, the other two are about two years old, serial #s 000000002d9aeba1 and 00000000d402df8a.

[ZPMMaker]

Out of interest, how long ago was that? I’m just wondering if you might’ve had the same version of whatever software I updated just before the issue started on my systems...

My four Zero Ws are all running the same version of Raspbian Stretch Lite from early 2018 with kernel 4.19.93 and MJPG Streamer v2.0 (fork by jacksonliam with raspicam support) started as systemd service. The only difference in software between them is a static IP set in /etc/dhcpcd.conf and the hostname set in wherever it eeds to be set. Otherwise they are exactly identical. Each of them has a Camera V2 aconnected an they only receive occasional Stretch updates. For a test I have just run apt-get update && apt-get upgrade on all of them and they all still work as before. The one failing to recognise the camera has been ordered about a month ago and has serial # 0000000046f996f4. Another (working) one from the same order has serial # 0000000096263505, the other two are about two years old, serial #s 000000002d9aeba1 and 00000000d402df8a.

Ok, thanks for the info.

[pi-anazazi]

You should really have a look at dmesg and and (permanent?) logs in systemctl to see, if anything is in there...

[ZPMMaker]

You should really have a look at dmesg and and (permanent?) logs in systemctl to see, if anything is in there...

Sorry, could you please explain how to do this?
Thanks.

[ZPMMaker]

The other two faulty RPi's (as per the other discussion linked-to in the OP) were fixed by doing a software update.

So on this Pi with the bad camera, I ran:

Code: Select all

sudo apt-get update && sudo apt full-upgrade -y && sudo apt -y dist-upgrade

I'm now running on Raspbian Buster (I was previously on Stretch).

Sadly, that hasn't helped. I'm still getting the same error when running raspistill and raspivid, etc.

[ZPMMaker]

I decided to try and completely remove libraspberrypi-bin (of which raspistill is a part), and then reinstall it.

I actually did

Code: Select all

sudo apt-get --reinstall install libraspberrypi-bin

earlier, so instead I tried to uninstall all its dependencies as well, with the aim of reinstalling them too, hoping that the issue is due to a dependency:

Code: Select all

sudo dpkg -P libraspberrypi-bin rpi-eeprom

Code: Select all

 sudo apt-get install libraspberrypi-bin rpi-eeprom

(The first time around, it said rpi-eeprom depended on libraspberrypi-bin, and so I had to uninstall and reinstall both.)

The reinstallation seemed to go OK, but running raspistill still results in the same error.

Desperate for a solution, I stumbled upon a command to reinstall every single package installed on the system:

Code: Select all

sudo aptitude reinstall '~i'

Sadly, this didn't seem to work. The output of this command was fairly extensive, but the gist of it was that it couldn't find sources to be able to download the packages that needed to be reinstalled. Here's an example one-liner:

E: Can't find a source to download version '0.8.0~bzr25-1+rpi3' of 'lxkeymap:armhf'

The end of the output had the following:

E: Internal error: couldn't generate list of packages to download
E: Perhaps the package lists are out of date, please try 'aptitude update' (or equivalent); otherwise some packages or versions are not available from the current repository sources

I then tried to run

Code: Select all

sudo aptitude update

Again, a bunch of errors printed to stdout. Here's an example line:

W: Package libavresample2 had been marked to reinstall, but the file for the current installed version 6:11.12-1~
deb8u8+rpi1 is not available

Re-running

Code: Select all

sudo aptitude reinstall '~i'

resulted in the same error as before - it still couldn't find a source for the packages to be reinstalled.

I realise completely reinstalling literally every package is extreme and likely isn't recommended, but I'm clutching at straws here, and am really trying to avoid replacing the system entirely.

Can anyone please advise how I can fix the issues running the package reinstall?
Or any better ideas?

Thanks,
Dave

[rpdom]

You have a mix of Stretch and Buster packages by the look of it. lxkeymap was in Raspbian Stretch, but doesn't exist in Buster. It looks to have been something originally from Ubuntu that was specifically added to Raspbian for the Pi. It's not a standard Debian package.

It would be better, if possible, to start with a fresh install of Buster.

[ZPMMaker]

You have a mix of Stretch and Buster packages by the look of it. lxkeymap was in Raspbian Stretch, but doesn't exist in Buster. It looks to have been something originally from Ubuntu that was specifically added to Raspbian for the Pi. It's not a standard Debian package.

It would be better, if possible, to start with a fresh install of Buster.

Thanks for that. Sadly, a fresh install isn't really feasible as it's a remote device.

Is there a command I can use to list what packages were from Stretch or earlier, that can be safely removed?

[6by9]

If you have

Code: Select all

$ vcgencmd get_camera
supported=1 detected=0

whilst

Code: Select all

$ vcgencmd version
Jan 16 2020 16:00:12
Copyright (c) 2012 Broadcom
version a15d66d3615281e13110f10573bf580c4d1156fa (clean) (release) (start_x)

(start_x includes the camera control code), then you have a hardware issue. The Pi can't talk over I2C to the sensor.

If you wish to dig into why, then add "dtparam=i2c_vc=on" to /boot/config.txt to enable /dev/i2c-0. You will need to load the module i2c-dev if it isn't already loaded.
The default pinmuxing is not for the camera, so you'll need to adjust the muxing manually

Code: Select all

raspi-gpio set 0 ip
raspi-gpio set 1 ip
raspi-gpio set 28 a0
raspi-gpio set 29 a0

"raspi-gpio get" should now list GPIOs 0&1 as inputs, 28 as SDA0, and 29 as SCL0. Ensure GPIOs 44&45 are not listed as SDA0 and SCL0.

Code: Select all

raspi-gpio set 44 dh
raspi-gpio set 40 dh

should enable the camera power supplies.
Now run "i2cdetect -y 0" to scan all the addresses on i2c-0. An IMX219 sensor should be on address 0x10.

[ZPMMaker]

Thanks for your reply and advice, 6by9.

If you have

Code: Select all

$ vcgencmd get_camera
supported=1 detected=0

whilst

Code: Select all

$ vcgencmd version
Jan 16 2020 16:00:12
Copyright (c) 2012 Broadcom
version a15d66d3615281e13110f10573bf580c4d1156fa (clean) (release) (start_x)

(start_x includes the camera control code), then you have a hardware issue. The Pi can't talk over I2C to the sensor.

My version is slightly different:

Code: Select all

vcgencmd version                                                                                  
Jan 10 2020 17:02:31                                                                                             
Copyright (c) 2012 Broadcom                                                                                      
version f3e39fed4763ce4efbffabb2d4787aaacddeda0f (clean) (release) (start_x)

...not sure if that makes a difference, nor how to update it, as I have done the normal apt update && apt upgrade earlier today so it should be up-to-date.

Code: Select all

raspi-gpio set 0 ip
raspi-gpio set 1 ip
raspi-gpio set 28 a0
raspi-gpio set 29 a0

"raspi-gpio get" should now list GPIOs 0&1 as inputs, 28 as SDA0, and 29 as SCL0. Ensure GPIOs 44&45 are not listed as SDA0 and SCL0.

My output of raspi-gpio set 0 ip match these values. 44 and 45 are outputs.

Code: Select all

raspi-gpio set 44 dh
raspi-gpio set 40 dh

should enable the camera power supplies.
Now run "i2cdetect -y 0" to scan all the addresses on i2c-0. An IMX219 sensor should be on address 0x10.

The first two of these commands ran without any error. They didn't actually return anything at all, so I'm not sure if they worked or not.

Code: Select all

i2cdetect -y 0

Code: Select all

     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f                                                              
00:          -- -- -- -- -- -- -- -- -- -- -- -- --                                                              
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --                                                              
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --                                                              
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --                                                              
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --                                                              
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --                                                              
60: -- -- -- -- 64 -- -- -- -- -- -- -- -- -- -- --                                                              
70: -- -- -- -- -- -- -- --

Sorry, but I'm not familiar with this and don't understand what this means. Could you please explain?

Thanks again for your help,
David

[6by9]

Code: Select all

i2cdetect -y 0

Code: Select all

     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f                                                              
00:          -- -- -- -- -- -- -- -- -- -- -- -- --                                                              
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --                                                              
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --                                                              
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --                                                              
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --                                                              
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --                                                              
60: -- -- -- -- 64 -- -- -- -- -- -- -- -- -- -- --                                                              
70: -- -- -- -- -- -- -- --

Sorry, but I'm not familiar with this and don't understand what this means. Could you please explain?

Consider i2cdetect to be the I2C equivalent of pinging each address on a network and reporting whether they responded.

In your case 0x64 has responded, which is a chip on the camera board, so the ribbon cable from the Pi to the camera board is OK.

0x10 has NOT responded, and that would have been the actual sensor. Either it has failed, or the little connector between the sensor and camera board has become detached. Whilst it may be in a sealed box, thermal expansion could cause the connector to pop off after some time.

[ZPMMaker]

Code: Select all

i2cdetect -y 0

Code: Select all

     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f                                                              
00:          -- -- -- -- -- -- -- -- -- -- -- -- --                                                              
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --                                                              
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --                                                              
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --                                                              
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --                                                              
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --                                                              
60: -- -- -- -- 64 -- -- -- -- -- -- -- -- -- -- --                                                              
70: -- -- -- -- -- -- -- --

Sorry, but I'm not familiar with this and don't understand what this means. Could you please explain?

Consider i2cdetect to be the I2C equivalent of pinging each address on a network and reporting whether they responded.

In your case 0x64 has responded, which is a chip on the camera board, so the ribbon cable from the Pi to the camera board is OK.

0x10 has NOT responded, and that would have been the actual sensor. Either it has failed, or the little connector between the sensor and camera board has become detached. Whilst it may be in a sealed box, thermal expansion could cause the connector to pop off after some time.

Great, thanks for the explanation and for your help.

I'll try to get the system sent back to me and I'll inspect that connector.

Thanks again to everyone ITT.