Files unreadable for some reason.

[neonix]

I have this kind of problems all the time, with my memory cards and pendrives. Why? Because crappy Chinese memory card readers, bad quality USB cables and the most important, it's not recommended to use journaling with flash technology. That's why I run my TC in LiveCD mode. If I want to archive somethings I'll copy it to pendrive.

There are some solutions, you can use NAS as a hard disk or force TC to do file system check from time to time. Other solution is to create 2 partitions, remaster TC that all data will be loaded from partition 1 by bootloader and after loading, don't use 1st partition. In this way partition 1 always by use as read-only and there is no risk because it won't be mounted and there will be not chance to corruption.

I destroyed my Debian/Ubuntu installation many times (no jurnaling). I use TC on memory card since 2009 and it corrupt many times. But since I load remastered version from the bootloader, I don't have any problems.

[atomant]

I just pull the plug, so to say. As far as i know corruption of the SD card should only occur if it is being written to when the power is removed. To my knowledge, this isn't happening (but of course i could be wrong). I'm using this system to play music from the internet, it is running YouTubeDL (python script), omxplayer and some self-written software to control what's happening. True, i'm not completely sure if either python or the player won't start writing files to the SD card but i don't see any sign of this (i see no remnant files lying around). My guess is that if any of these has the need to write some temporary files, it would do so to /tmp which is on the memory drive. Of course, this is a big guess again.

[coreplayer2]

Not all SD cards are created equal, some are of really dubious quality.  So try a high quality branded SD card

[atomant]

Not all SD cards are created equal, some are of really dubious quality.  So try a high quality branded SD card

On paper it's a SanDisk...do you have any recommendations perhaps?

[coreplayer2]

I would recommend a SanDisk without hesitation, but are sure it's an original?

Could be defective in any case

[atomant]

I would recommend a SanDisk without hesitation, but are sure it's an original?

No idea how i could be sure of that...didn't get it from some shady looking memory card dealer in a long raincoat.  As far as i can remember i bought it in a computer store, where they got it from i can't know...

[curaga]

Could there be a voltage spike when you pull power?

Internal, delayed block ordering could result from a write (so the SD card could be writing several seconds after Linux says the write is done), but you say there were no writes.

[neonix]

SanDisk is the best brand. File system corruption occurs even on HDD (when you don't use journaling). You can use journaling on your flash device (with the risk it degenerate faster) or you can configure your system in way that everything will be in RAM and all devices will be unmounted.

[Greg Erskine]

piCorePlayer based on piCore has hundreds, maybe thousands of installations. I prepared a "copy2fs" solution waiting for corruptions of SD cards. It never happened. We might be lucky that our application does little writing to the SD card.

When you use "copy2fs" you can set it up to dismount all disks. I actually removed the SD card.

I've been using piCore based RPi's for over 5 years and I can't remember having a random SD card corruption! Lucky?

I use mainly SanDisk.

[PDP-8]

Roberts designed TC to be nice to flash from the outset, so if you are getting corruption, there is a local problem.

The major issue (aside from counterfeits) is write-amplification.  That is, many small files being written all the time.  Wear leveling helps.  To help wear-leveling perform the best, use 4MB partition boundaries.

Even with TC, use a big card to have redundant cells.  My recommendation is to go no smaller than 32gb, even if you are only using a small fraction of that with the o/s and your files.

And if overall speed is not a concern, there are so-called "high endurance" cards available designed for long term writing (think dashcams, body-cams, surveillance cams), which tradeoff a bit of speed for more endurance.

One such is the Samsung "Pro Endurance".  Markets itself as "High Endurance for Video Monitoring".

Use of ext-2:  these days the wear-leveling techniques are good enough that you *can* use journaling filesystems without worrying too much.  Especially with an o/s like TinyCore.

But yeah, if one is using a 2gb card from 1998, then maybe ext2 is a good idea.  Thing is, this "advice" from the past can live well beyond its expiration date if one stays up with technology.  And it provides good fodder for click-bait sales of old stock, that marketers are well aware of.

[PDP-8]

Want peace-of-mind?  Test with the F3 util:

Computer stores and online sales that seem reputable may be vulnerable to man-in-the-middle counterfeit substitutions.

Check yours - perhaps a single one if purchasing in a batch:

https://fight-flash-fraud.readthedocs.io/en/stable/

Here's are some examples.  Many on web video as well:

https://fight-flash-fraud.readthedocs.io/en/stable/introduction.html#examples

You can get it for compiling right here:  Note that most linux users will want to read the entirety of the above docs if they want the "extra applications" to work.

https://github.com/AltraMayor/f3/releases

Looks like F3 would make a *great* candidate for a F3.tcz package!

[atomant]

Could there be a voltage spike when you pull power?

Internal, delayed block ordering could result from a write (so the SD card could be writing several seconds after Linux says the write is done), but you say there were no writes.

Not that i can see but of course it's not impossible, can't see what happens inside the rPi's hardware. I see no spike on the power line with the multimeter.

To the others, card is 16Gb and i'm using Ext4 on the partition that's experiencing the problems. Theoretically, in normal operation, no writes to the card should ever occur, but as said before, i do not know this for sure.

[Rich]

Hi atomant

... I see no spike on the power line with the multimeter. ...

If it's a digital multimeter, you probably won't see a spike, its response is too slow. If it's an analog meter, you might be able to
spot something if it's blatant enough.
Try to isolate the problem. Start with Juanitos advice

Do you use "sync" and then "sudo exitcheck.sh" to shutdown piCore or just pull the power cord out?

If the corruption continues, make sure cables are as short as possible. Try another power supply.
Doesn't the Pi have a power status LED that lights when the power rail is questionable?

If the corruption stops, then it doesn't like you just cutting the power.

[atomant]

I hope it's not the power-cut because creating a "proper shutdown" is a pain in the ass...

[atomant]

FYI: I used iotop to see if any writes occur during operation, apparently not.