Another SD card bites the dust

Last June I set up a Raspberry Pi as an OpenVPN server. It’s rarely used. Late last year it stopped working. I couoldn’t be bothered to find out why until more recently. The machine always seemed to freeze (no mouse cursor movement, no nothing).

Finally yesterday I invested the time and effort to make it work again. When I was doing anything with it, like trying to update Linux, it would freeze within minutes. I tried three different ways of powering it, but nothing helped.

Eventually I tried substituting a different micro SD card (in adaptor) and performing a new installation. Now it works, and it has continued to work today. I had to generate new ovpn files and install them on the clients (mobile phones) of course.

So the only thing that changed that made a difference was the micro SD card. The old one is a SanDisk 16GB Ultra; the new one is a SanDisk 8GB.

I have to assume that the old one ceased to be writable (at least), and maybe ceased to be readable without errors too.

The old one is a SanDisk 16GB Ultra; the new one is a SanDisk 8GB.

I’m sure you’ve many of the articles I have and we both know that the word “allegedly” needs inserting before the SanDisk.
Other brands get pirated but SanDisk is a prominent target.

Mind you it depends how much write action is going on with that rarely used setup.
You still can’t beat spinning rust can you? Especially when the OS likes to write back regularly.

Some cards are better than others on the Pi – there’s a list somewhere. Maybe yours was an edge case that worked until it didn’t?

I can’t imagine there was that much write action, not at least compared to a Pi running a server on RISC OS and five minute weather updates, plus all the faffing around with directory/map that this would involve. My weather thingy has logged 44452 events at 5 min intervals (doing the maths – your homework!) plus regular stupidity from China logged in the WebJames logs (both of them – I really ought to point those logs to null).

Ah, here’s the SD list. Quite eye opening. https://elinux.org/RPi_SD_cards

Flash memory cards are not really the right thing for hosting operating systems.

I gave up on them a long time ago and now I only use USB Solid State Drives (including mSATA). Life is so much better.

(and they are easier to backup!)

Flash memory cards are not really the right thing for hosting operating systems.

I think the OS is fine there, as long as the OS isn’t regularly writing to it. After all it’s a device designed to used in a fashion akin to an electrically erasable ROM.

I suppose a High Endurance SD card wouldn’t be too bad – but I’ve never seen one less than 16GB, and the cheapest seem to be 32GB.

Samsung Evo+ works OK here on several Pi.
Samsung Pro seems to be much less reliable.
I did not yet tried the Endurance models.

I gave up on them a long time ago and now I only use USB Solid State Drives (including mSATA). Life is so much better.

Sometimes.
Here I have three big bugs:

- Time state is not stored on the microSD any more. Normally, if you have no network on boot, a Pi without hardware RTC clock will start from the latest recorded time. With USB disk, it starts from 0. A nightmare when you need to store files or to use tools as Organizer, that will simply refuse to launch.

- If you plug a (too) big hard disk on your Pi, all the USB disks are disconnected. Even my main USB disk. Not a big problem if you boot from microSD. But a biggest one when the system disk is a USB one and gets disconnected…

- !Territory does not work reliably. Sometimes RISC OS finds it on the USB disk, sometimes not. Probably a delay a bit too short when booting on an external disk.

So I switch back to my EVO+ cards, that worked without any problem 6-8 hours a day for almost two years now. I can’t say the same for the other cards I did test.

microSD cards are a bit slower with benchmarks than USB disks, but much faster in real use, as the bandwith is not shared with the other USB peripherals (and so with the network chip too).

Nota: SanDisk Ultra are much much slower and less reliable than Samsung Evo+ (and even Samsung Evo). So don’t base your judgement on them. And don’t use Samsung Pro too. They will be faster… but not for a long time (around 9 months here).

- Normally, if you have no network on boot, a Pi without hardware RTC clock will start from the latest recorded time. With USB disk, it starts from 0.

My Pi 5.24 build with a USB Drive 4 Solid State Disc (and no network) boots with the latest recorded time.

- !Territory does not work reliably. Sometimes RISC OS finds it on the USB disk, sometimes not. Probably a delay a bit too short when booting on an external disk.

A delay can be added to config.txt. There are a number of options to do this. But I think SSDs do not need it, whereas spinning rust might.

- If you plug a (too) big hard disk on your Pi, all the USB disks are disconnected.

Is this just a power surge knocking out the USB chip on the Pi. Solved with an up-to-date Pi and Solid State Drives. (or a powered hub)

I will try a Samsung Endurance SD card – being delivered on Thursday.

Although I am not looking forward to creating the bootable RISCOS system, with its fake Loader partition. SSDs are so much easier to build.

My Pi 5.24 build with a USB Drive 4 Solid State Disc (and no network) boots with the latest recorded time.

Without a RTC module?
You boot on microSD+SSD or SSD only (no ROM on the microSD)?

A delay can be added to config.txt. There are a number of options to do this. But I think SSDs do not need it, whereas spinning rust might.

I use a SSD.

Is this just a power surge knocking out the USB chip on the Pi. Solved with an up-to-date Pi and Solid State Drives. (or a powered hub)

I use a Pi 3B+, an 4 AMP PSU and a low power SSD.
Still have problems.

I will try a Samsung Endurance SD card – being delivered on Thursday.

Please give us bench values.
The problem with Pro and Pro+ is that the write speed is around 0 after 6 months of continuous use.

Without a RTC module?

No RTC module

The Fat formatted microSD card has only the Pi Loader files on it (including the RISCOS ROM Image and the CMOS file)

The CMOS file is set with *configure filesystem SCSI and *configure SCSIFSDrive 4

The same here. Strange.
Probably a change in RISC OS 5.26.