Is there a test suite for Pi2/armv7 ?

The only item that I would suspect has 'wear' issues would be the SD cards.

We always suspect SD cards, rightly so, but it could be other stuff. It is quite common for routers to die of old age.

A quick google reveals there are test tools, such as memtest, or maybe stress-ng.

Only time I have had routers fail is after lightning strikes on or near DSL lines

Well all semiconductors are subject to dopant migration and/or contamination after sealing failures. Especially at elevated temperatures. But since nothing on a Pi is 'user replaceable' knowing what is faulty is of academic interest only.

SD cards are cheap and so are Pis. selective replacement would seem to be a simpler method to achieve a working setup again.

I don’t know of a test suite as such but if it can’t reliably boot a Linux kernel from known-good storage (e.g. fresh install on a uSD card) then you’ve got the core of your answer: it’s broken.

As others have said, SD card failure should be right at the top of the list of possible causes.

“Processes reporting errors” is harder to assess with so little information, certainly there’s not enough presented here to assume a hardware fault.

Fuzzing is a technique for discovering bugs you didn’t yet know existed. In this case it seems you can already reproduce the issues...

We have smartctl for SATA and NVME drives, that tells us how healthy these devices are. Is there something similar for SD cards?

I've had failures to: ADSL router, VDSL modem, cable router. I dunno what goes wrong, but these are devices running close to design capacity for many years. Whereas most desktop PCs rarely break a sweat. We know electronic components like electrolytic capacitors do wear out.

Which reminds me, an even more common failure is USB wall warts, that probably should show up in dmesg or journalctl as an "under voltage" error.

Only tools that will write data to them and then read it back to check if the data is still correct. There's no standard like SMART for them the SD card controller to report stats back over the card interface.

SMART isn’t much use, anyway. I test my storage devices for actual I/O errors.

That's what you use SMART *for*. Amongst other things

No, I test doing actual I/O.

So does SMART.

And with SSDS you dont want to be actually doing any superfluous read or write ops I am curious. Have you ever used SMART at all?

By the time any type of storage device is reporting errors during actual use, it's already in a really bad way, and should have been replaced.

Both spinning discs and flash media are over provisioned with a number of spare sectors/blocks which they will silently map in, either over sectors which have started giving read errors, or any flash blocks which have reached their write limits and could be unreliable.

The SMART information on the drive will tell you when this happens, long before the OS finds the disc has started to be come corrupted. Use this as the first warning to replace the disc before data loss or complete failure.

---druck

Exactly. ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x0032 100 100 050 Old_age Always - 0 5 Reallocated_Sector_Ct 0x0032 100 100 050 Old_age Always - 0 9 Power_On_Hours 0x0032 100 100 050 Old_age Always - 23833 12 Power_Cycle_Count 0x0032 100 100 050 Old_age Always - 113

160 Unknown_Attribute 0x0032 100 100 050 Old_age Always - 0 161 Unknown_Attribute 0x0033 100 100 050 Pre-fail Always - 100 163 Unknown_Attribute 0x0032 100 100 050 Old_age Always - 8 164 Unknown_Attribute 0x0032 100 100 050 Old_age Always - 70687 165 Unknown_Attribute 0x0032 100 100 050 Old_age Always - 326 166 Unknown_Attribute 0x0032 100 100 050 Old_age Always - 115 167 Unknown_Attribute 0x0032 100 100 050 Old_age Always - 142 168 Unknown_Attribute 0x0032 100 100 050 Old_age Always - 7000 169 Unknown_Attribute 0x0032 100 100 050 Old_age Always - 98 175 Program_Fail_Count_Chip 0x0032 100 100 050 Old_age Always - 0 176 Erase_Fail_Count_Chip 0x0032 100 100 050 Old_age Always - 0 177 Wear_Leveling_Count 0x0032 100 100 050 Old_age Always - 0 178 Used_Rsvd_Blk_Cnt_Chip 0x0032 100 100 050 Old_age Always - 0 181 Program_Fail_Cnt_Total 0x0032 100 100 050 Old_age Always - 0 182 Erase_Fail_Count_Total 0x0032 100 100 050 Old_age Always - 0 192 Power-Off_Retract_Count 0x0032 100 100 050 Old_age Always - 51 194 Temperature_Celsius 0x0022 100 100 050 Old_age Always - 40 195 Hardware_ECC_Recovered 0x0032 100 100 050 Old_age Always - 1397810 196 Reallocated_Event_Count 0x0032 100 100 050 Old_age Always - 0 197 Current_Pending_Sector 0x0032 100 100 050 Old_age Always - 0 198 Offline_Uncorrectable 0x0032 100 100 050 Old_age Always - 0 199 UDMA_CRC_Error_Count 0x0032 100 100 050 Old_age Always - 0 232 Available_Reservd_Space 0x0032 100 100 050 Old_age Always - 100 241 Total_LBAs_Written 0x0030 100 100 050 Old_age Offline - 247432 242 Total_LBAs_Read 0x0030 100 100 050 Old_age Offline - 56254 245 Unknown_Attribute 0x0032 100 100 050 Old_age Always - 346410

Raw error read read is there, also something you wouldn't find outside SMART - reallocated sector count plus erase fail and wear levelling counts

No, it extrapolates from its internal firmware behaviour. It tries to predict failures before they happen.

This is why you have redundant systems. That’s how the pros do it.

No it doesn't. It predicts from stored values of errors. I/O amongst them

Do try to keep up.

No. Its why you use SMART.

AND redundant storage, which SSDs already have built in

Yes but the kind of redundancy I thought of first was some kind of RAID or live backup (I do both and monitor SMART) so that there isn't just one copy of the data ready to be used.

Oh indeed. My new server will feature two SMART enabled SSDs...one a mirror of the other. I am not interested in RAID. RAID increases availability, but does not archive data