This is just a head’s up for RaspberryPi/PiHole users - sometimes RaspberryPi PiHole needs to be rebooted. Until it is, you get some weird symptoms.
The 2.4gHz radio appeared to be completely inoperable. The first symptoms were a good WiFi signal but an inability to reach the internet. After that I could not even get a WiFi indication. (Kindle, two different models.) I even considered PiHole early and removed its DNS address and let the router pick one automatically. That didn’t work and left me considering a broken 2.4gHz radio.
What I checked and tried.
The router’s AP/Settings have 1 6 11 channels set and I have tried Channel Widths of 20, 20/40, and 40. (20 always worked previously.)
I downloaded a diagnostic report.
Since this happened soon after adopting Firmware 8.1, I reverted to 8.0.2 and loaded the previous configuration.
I have several devices that should function on the 2.4gHz band - MacBook Pro and Amazon FireStick; none worked on 2.4gHz, with either firmware.
Oddly, my FireStick is set to 5gHz and to go through the PiHole. That worked okay in 5 but not in 2.4gHz; I presume Amazon has embedded a backup DNS address for such issues, but I can’t be sure.
What finally worked was my attempt to switch to the RPi/PiHole screen and finding it blank. I had to unplug the RaspberryPi and replug it to reboot. After that, the PiHole screen showed up everything else worked fine, too. In retrospect, I should have noticed that the RaspberryPi wasn’t in the Status/Client List. I’m back on Firmware 8.1 and everything’s working.
I hope my mistakes can help new people troubleshoot some problems.
With the kind of problem I described I couldn’t get into it direct or ssh, so I had no choice. As to versions, I’m keeping it on 4.x until the bugs are gone - I like the idea of 5 capabilities, but I’m not ready yet.
Hi. @stego is correct about the risks associated with “pulling the plug,” although I understand you had no choice. A corrupted SD card is a likely result.
We have many installations out there and all are stable at these revs:
Question: Are you running Jessie, Stretch or Buster?
NB: I moved this threat from SOHO to “Everything Else.”
You can certainly do that. But sometimes its just easier to blow it away and start fresh – particularly when things have been acting “goofy.” It’s not much work to reimage. Just an idea …
I setup several Pi-holes the other week. Zero issues. Not using Raspberry WiFi, instead have hardwired, and am disabling WiFi and Bluetooth to save on power.
@Jaywalker@Rick-DC Simple 1-liner Backup method for proper shutdown of a Raspberry Pi in case of no longer being able to ssh in and/or log in : with peripherals:
I add this to a Raspberry Pi 3B/3B+ 's config.txt file whenever I set one up:
##### ADD TO /boot/config.txt
# (default is GPIO 4 (pin 5) ) pin26 is BCM numbering. Use physical pin 37 ( see https://pinout.xyz ):
dtoverlay=gpio-shutdown,gpio_pin=26
To trigger shutdown, use a standard wire with female-female Dupont connectors to connect your defined pin above to a ground pin momentarily.
Don’t know why they never made this feature more visible…I’ve seen tons of blog posts about creating a button with a python script running as a systemd service, which obviously isn’t at all needed.
Right, I think that should trigger an orderly shutdown. Good work!
We’ve never done that because (1) so many of them we touch are remote and it’d be essentially impossible and (2) it’s not much of a job to rebuild it if the thing crumps. Actually, they’ve been pretty stable – very few real problems. The only issue we’ve had, say within the last year or so, was upgrading the software w/o paying attention to the OS (Jessie is no longer supported.)
Before this, I haven’t bothered with alternate shutdown methods because pulling the plug has never caused me problems - wasn’t aware it could - and I always have an image I can use to re-flash that SD card or a replacement.
@Rick-DC is absolutely right. The raspberry pi official docs talk about this, and there are gazillions of forum post about it, along with alternative power source stuff, & possible methods to mitigate the risk such as read-only or sparse write commit file systems etc…
The problem is really well described by the source linked below… Notice the last sentence in the first paragraph pasted here. Article is pretty interesting actually & whoever wrote this did a great job.
Basically most of the time you don’t know as a user when damage is being done until the collective corruption over time acquires critical mass and catastrophic failure occurs.
I’ve been messing with these things long enough in various projects, that I’ve also experienced 3-4 times SBC’s failing to reboot with just one accidental power disconnect until I replaced the SD card or USB stick.
“Almost any computer system is subject to unexpected power failures. For some embedded systems, this only occurs when the power grid goes down. For others, it may happen when a user decides to pull the plug instead of using a documented shutdown procedure…
If an embedded system is implemented without thinking about what happens when the power goes down it could lead to catastrophic failures down the road.
Due to the nature of failures caused by unexpected power loss an embedded system may run for weeks, months, or years before users experience an unexpected and catastrophic failure. From the users perspective, their device worked fine yesterday and today it doesn’t even turn on, and they don’t tie it back to the unexpected power failure event.”
I’m facing that right now after several days of rolling blackouts, and perhaps an unwise decision to “full upgrade” after a partial failure of “update.” I’m now considering asking the RPi site for help recovering the mess or simply flushing it with a backup-flashed RPi/Pihole image. I’ll probably do the latter.
A simple approach would have been to turn off the RPi and even the router after the first of many rolling blackouts. I did turn off the desktop but just forgot the RPi, but there was no internet for the RPi to reach, anyway. The main reason I didn’t do ups was because I’m a little pressed to remember how each piece I already have functions and didn’t want to add anything that commands shutdown. Luddite, almost.
