Zero-WH, strange SD card behaviour

How clean is the RPi environment, i.e. is there anything volatile near it that might be oxidising or otherwise affecting the SD card contacts: they look more like a copper alloy than gold on the (full size) Sandisk SD card in my camera (the closest SD card to hand). A hot environment, one containing a heavy smoker or that's near heavy industry or the sea could also affect the card's contacts.

--
Martin    | martin at 
Gregorie  | gregorie dot org

perhaps you should reconsider your approach "Reboots are for hardware changes only" if your system has stability issues (have you confirmed this or where you just being cautious?) then you need to investigate & correct.

also consider a watchdog so that reboots only occur in the event of an unexpected failure.

I've got 10 Raspberry Pi's doing temperature logging with those and similar I2C and 1-wire sensors, and I've never needed to reboot for stability. If you are needing to do this, something is very wrong.

It will be probably an issue reconnecting to the router. Reboot it again and look in /var/log/syslog or /var/log/syslog.1 for the messages logged between the last two reboots.

I found one of my Pi Zeros wouldn't reconnect to the router after a power failure, but would do after power cycling just the Zero. Not sure what the issue was as I re-imagined from one which didn't do this.

If you suspect a card failure, do a sudo dmesg -H after boot and look for evidence the the filing system is being repaired. But if the corruption is bad enough to stop it booting once, it usually wont come back up the second time either, without the card having to be repaired in another Linux system. Which is why I suspect networking.

So:-

1) Reboot less 2) Look at the logs to see what happened 3) Compare with one that does work

---druck

Hi there, thanks for all the hints!

A few things I forgot to mention:

- Formerly I had a watchdog running, which forces a hardware reboot if sshd on localhost is no longer reachable. But this is somehow dangerous because then the OS may demand for a fsck during next boot. If this happens, then it is no longer fully non-interactice needed for headless mode

- I switched to crontab-based reboots because the same machine (RPi Zero Wifi) is used for taking photos on demand. Therefore I ssh into it and start a script which accesses a USB webcam via fswebcam and transfers the photos to a webserver. This works fine, but from time to time fswebcam suddenly is no longer able to get data from the webcam for some reason. In this case even a "USB reset" does not work. So the machine has to be rebooted anyway.

But, back to the Micro SD card in question:

I dont't think that this is a contact problem since I have pulled out and pushed it back into the RPi several times, prior to inserting it into the (Linux) PC. Then, after accessing it from the PC and put it back into the RPi it works instantly. This occurred on two RPi Zeroes and with different types of Micro SD cards.

B.t.w., I already tried to put the line "fsck -p /dev/mmcblk0p1" into / etc/rc.local to reset file system's "dirty bit" to prevent it from demanding for a filesystem check. This seems to have no effect.

So, RPi or the OS, seems to make changes to the filesystem / MBR or what else, which cannot be recovered by RPi itself, but a "normal" Linux machine can handle this without even alerting about any trouble.

Best regards,

Markus

--
Please reply to group only. 
For private email please use http://www.dipl-ing-kessler.de/email.htm

Sounds familiar. I have 10 Pi Zero (some W some not) running motion software for security and wildlife cameras (some usb cameras some pi cameras).

For years I suffered with random problems such as yours. e.g. The wifi would drop and not return unless the power was cycled. The camera would cease to work. Again requiring a power cycle. The pi would not reboot after a power cycle unless I put the SD card into a PC. This resets the "dirty bit" on the partitions. A few other mysterious unexplainable events.

Then a serendipitous event led me to remove the Bluetooth drivers.

It looked like people walking past the house with Bluetooth scanning from their phones active, would cause a Pi to misbehave.

Since removing the drivers about 4 months ago - no problems.

--
Nev 
It causes me a great deal of regret and remorse 
that so many people are unable to understand what I write.

This suggests to me that the webcam may be very close to the maximum current available from the Zero's USB port. If it has been currently limited the voltage will drop and many devices will no longer respond until the power is cycled. A USB deivce drawing too much current may also cause the WiFi to drop out on the Pi.

The solution would be to either attach the webcam through an externally powered USB hub, or replace it with a Raspberrp Pi camera, which are lower power.

A fsck will be performed on system startup, long before anything in /etc/rc.local gets run. I know you can force an fsck on boot using /boot/cmdline.txt but I don't think you can prevent one.

If this is happening the card needs to be replaced. If it wasn't a Zero I'd suggest booting from a USB stick for better reliability, but as an SD card is the only option, a high endurance version is probably worthwhile.

---druck

Am Sat, 22 Jun 2019 12:20:59 +0100 schrieb druck:

Hi druck,

what you describe above (connecting the camera directly to the RPi) was what I did first, but that was indeed not so stable. Hence, very soon I switched to using an active-powered USB hub which feeds camera and RPi.

It may sound strange, but for me it seems that the higher the resolution of the connected webcam, the more problems this will cause to RPi / Raspian / fswebcam.

In the beginning, I tried to reset the USB bus -- with no success. Then I added commands to my script to rmmod and insmod / modprobe the relevant USB-to-video kernel drivers -- that worked often, but sometimes the whole machine crashed (!). That was the point when I involved watchdog mechanism also to get the machine back again in such a case.

So, meanwhile I prefer to wait at least 10..15 seconds after taking of a photo fails, until repeating it, and if this will not lead to success, then I run a reboot.

To the Micro SD cards: I tried several different ones in size and manufacturer, but alway the same. Except Kingston -- these cards just die under load, but then things are clear at least...

B.t.w., resetting the "dirty flag" is done during startup, in the hope, that this state may last until the machine crashes or the watchdog runs a hardware reset. But, it's likely that the flag will be set (again) prior to some crash, anyway?

Well, what I intend to try next is, what nev young recommends -- on most of my raspberries Bluetooth is really not needed at all. So, I'll switch the driver off and see.

Best regards,

Markus

--
Please reply to group only. 
For private email please use http://www.dipl-ing-kessler.de/email.htm

That's not something I've found with several 8Mpix Camera V2's connected to both 2Bs, 3Bs and Zero Ws, or some mini 5MPix ones on ZeroWs.

That sounds seriously unreliable. As Pi Zero's are cheap, I'd buy another one to see if it behaves any better.

I've found Samsung to be the best, but make sure you buy them from a reputable source, as the market are flooded with inferior fakes.

The flag is set when running, and cleared by a controlled shutdown.

Disabling Bluetooth will reduce the power draw slightly, which could help if the power draw is marginal.

---druck

Hello David,

I have seen a Pi starting form USB stick without a SD card inserted. You then first need to write the write once only OTP-bit in the machine. It then checks if there is an USB disk to start from the Pi 3B. I am not sure if that OTP-bit is usable in the older Pi's and Zero machines.

Henri.

-=> Henri Derksen wrote to druck If this is happening the card needs to be replaced. If it wasn't a Zero > I'd suggest booting from a USB stick for better reliability, but as an > SD card is the only option, a high endurance version is probably > worthwhile.

HD> I have seen a Pi starting form USB stick without a SD card HD> inserted. You then first need to write the write once only HD> OTP-bit in the machine. It then checks if there is an USB disk to HD> start from the Pi 3B. I am not sure if that OTP-bit is usable in HD> the older Pi's and Zero machines.

I have a Pi 3B running 24x7, with no SD card installed. It boots and runs from a 2.5" laptop 500GB SATA hard drive, which sits in an externally powered adapter housing and connects to the Pi with a normal USB cable. I did have to set the OTP-bit to enable that to work. On a 3B+ it is not necessary to set the bit, it will boot from either an SD or an USB/external stick/drive. This does not work on any Pi 2's or earlier models. I'm assuming the 4B will have this ability as well.

... So easy, a child could do it. Child sold separately. === MultiMail/Linux v0.52

Yes you can do this if you don't want to use a SD card at all. However, I just use a small SD card to hold the BOOT partition and modify cmdline.txt so it uses the USB stick for the main Linux partition.

I was thinking more that the Pi Zero only has one micro USB port, which you would have to use for the USB drive. There are a very limited range of micro USB drives, but otherwise you'd have to have a normal one hanging off an adaptor, which would greatly increase the footprint of the Pi Zero.

---druck