PSU fickleness of Raspberry Pi

I’m not kind to my raspberry pi’s. I have a few, of varying pedigrees, tucked away in the attic or other inhospitable dusty places. A week ago, the imaginatively named pi2 went offline. Irritatingly, it takes the podium of my most inhospitable rpi, tucked in the attic, balanced on a rafter, in a tight spot an uncomfortably long crawl away from the hatch.

Still. Gotta be done. I’d tried switching it off and on again. Many times. That was easy enough, and can be done from a distance. Likewise, I cycled power on its network switch a few times too. I rarely go the wifi route unless it’s unavoidable. I mean, if you can get a power cable to it, it’s usually possible to get a bit of cat5 there too.

No joy. So I brought it down, blew out the dust, and plugged it in again using a spare PSU in my study. Nothing. Except a high pitch whine coming from the, well, where was it coming from? The PSU? The rpi? Yep, definitely the pi.

I’ve never skimped on PSUs for the rpi. I’ve never much understood them either. Opting usually for the recommended product rather than skimping on a cheaper option. Although buying anything branded on Amazon nowadays is a bit of a gamble. What you see in the nice picture is not always, or even often, what you get.

Still, here’s the situation. The rpi is a, er, well, what is it? It’s back up the loft, far away in dustville, but, according to the University of Google, it’s:

root@pi2-driveway:~# cat /proc/device-tree/model
Raspberry Pi 2 Model B Rev 1.1

… and the PSU that it had been happily running on since it was sent up the attic, was:

NorthPanda Model LA-520WF

In the study I plugged it in to a spare rpi PSU, an old RS favourite. And that’s where I heard the high-pitched whine …

I was assuming the rpi was goosed but had a final visit to the University of Google, and, even though the noise was definitely coming from the rpi itself, and not the PSU, I tried one more time with a different PSU.

AAA Products MUSB2A PSU

I’m not sure when or where I bought this. According to my Amazon order history I bought this item on the 6 aug 2017 for an anker bluetooth speaker. I’m guessing that whatever it was once bought for is now jammed in a power bank, and the PSU was no longer required, until now. I’m glad I hung on to it though, because it fired up the rpi fine, and it’s back up the loft.

Permissions on /dev/video0 running motion on Raspberry pi

[ Update: 1 July 2020 ]

I can’t say my blog sees a lot of action or sets the world on fire. That’s the way I like it. But, and I’m not saying it keeps me awake at nights, this blog post regularly sees a lot of hits. It’s about 4 years old now, and in raspberry pi times, that’s a long time. I can’t recall having had this problem for ages, and on all my new-builds it seems to have just, gone away. I still have issues with the rpi deciding on its device file, and I still don’t understand them, but I’ll get around to that one day …

Wisdom of the ancients

Post from Feb 2017

It pretty much happens that every time I setup motion on a new build that it doesn’t work right away. There’s usually a few things I miss. Usually it’s an error reading from the camera, the logs reporting something like:

Feb 17 10:51:21 pi2 motion: [1] [NTC] [ALL] motion_init: Thread 1 started , motion detection Enabled
Feb 17 10:51:21 pi2 motion: [1] [NTC] [VID] vid_v4lx_start: Using videodevice /dev/video0 and input -1
Feb 17 10:51:21 pi2 motion: [1] [ALR] [VID] vid_v4lx_start: Failed to open video device /dev/video0:

which invariably means the camera is broken or I’ve misconfigured my motion setup.

This one was puzzling me a little though. It’s on a raspberry pi, imaginatively titled pi2, and it was failing to read from the camera. The reason I was puzzled was that the hardware combination had worked before. What had gone wrong was the micro-SD card, and I’d done a new raspbian build, copying over the relevant motion configuration files from the old card.

Clearly the difference had to be something to do with the OS. So what was different? I’d taken the opportunity of the SD failure to download and install the latest version of raspbian and everything looked good to go.

Running motion as root worked fine, both against the vanilla configuration file, and the customised config file I wanted to use. So let’s have a look at the video file:

root@pi2:~# ls -l /dev/video0
crw-rw----+ 1 root video 81, 0 Feb 17 11:17 /dev/video0

Looks about right. Ah, the video group. I need to be in the video group. That might be it:

root@pi2:~# usermod -G video dougie

Restart motion and try again. Nope. Let’s have a closer look at that file.

On pi2 (with a new version of raspbian):

crw-rw----+ 1 root video 81, 0 Feb 17 11:17 /dev/video0

and on pi1 (another rpi, running motion fine, with a slightly older version of raspbian):

dougie@pi1:~ $ ls -l /dev/video0
crw-rw---- 1 root video 81, 0 Jan 8 22:54 /dev/video0

Very similar, but not identical. The newer version of the device file has and extra + at the end of the permissions bit, which means the file has extra security permissions set. I’ve not had cause to use Access Control Lists (ACLs) before, and it was a temptation just to chmod 777 on the file as a quick and dirty, and lazy, fix, but I thought it’d be better to take a closer look. Using the getfacl command:

root@pi2:~# getfacl /dev/video0
getfacl: Removing leading '/' from absolute path names
# file: dev/video0
# owner: root
# group: video
user::rw-
user:pi:rw-
group::rw-
mask::rw-
other::---

I could see that I (me: dougie) did not appear on the list, although the default rpi user pi does. I rarely use the pi account. One of the first things I do is change its password, create my own user, and use that instead. So it looks like the default install for raspbian allows user pi to access /dev/video0. It also looks like I can’t access the file, despite being a member of the group video.

I found a good command summary on the (now a dead link) centos documentation website, and using that gave myself access:

root@pi2:~# setfacl -m u:dougie:rw /dev/video0

That did the trick.