9 ms·

I would just be happy if my rpi would not randomly corrupt the memory card for no reason all the time. Have it on a quality adapter, hooked up to a ups, with a

I would just be happy if my rpi would not randomly corrupt the memory card for no reason all the time. Have it on a quality adapter, hooked up to a ups, with a quality card, yet it still corrupts itself for no reason.

msumpter 9y ago
And that's why I moved over to MMC based Pi clones (specifically the Rock64), I am overly tired of SD cards mysteriously corrupting themselves. As of yet, I haven't had an MMC go upside down, but that's certainly far from guaranteed as well.
- zwieback 9y ago
  Do you know how much of that is due to connector and signal paths? I worked on a design that had soldered on eMMC and it was rock solid (and 8 bit wide) but I always assumed SD problems were due more to the flaky form factor. Is there a standard for removable eMMC modules?
  - dbuder 9y ago
    Yes it's like one of those double row press fit connectors usually used for displays in phones that fit better than they look like they will. If you are soldering in your first question is why am I using eMMC. SBC computers are a good use case for it imo.
- copperx 9y ago
  Is it possible for the rPi to boot from a USB device? One solution would be to hook it up to a $20 32GB SSD drive instead of relying on an SD card.
  - wolrah 9y ago
    Depends on the model, or actually technically it depends on the bootcode but which version is preloaded depends on the model. The brand new Pi 3B+ ships with the latest bootcode and will boot from USB mass storage or PXE by default. Their PXE is a bit nonstandard but it's close enough that anyone who's PXE booted a PC will understand it. The older Pi 3 supports USB and PXE booting, but has those modes disabled by default. There's a bit you can set in one-time programmable memory to enable it permanently. PXE booting has some quirks in this mode and doesn't get along with switches that take more than a second or so to activate ports. Earlier models do not support anything but SD on their stock bootcode. In all cases, a SD card containing nothing but the latest bootcode can be inserted which brings the new features to the older models, allowing them to boot the rest of the OS from whatever.
  - ygra 9y ago
    At least for the older models you still needed the card, but only for a marker that tells the Pi to boot from USB. I've been using that setup with Kodi/OSMC with a Pi 2 since USB is faster than the SD card.
kiddico 9y ago
Do you have an overclock running? Specifically sdram_freq.
penagwin 9y ago
Also losing power seems to result in a corrupt sd card 80% of time. Obviously it's bad to lose power while on, but that's crazy.
- semi-extrinsic 9y ago
  I had a GoPro develop a flaky voltage regulator so it would sometimes brown out, that thing killed microSD cards like a champ.
- slig 9y ago
  Once corrupted, it can't be re-used after formatting?
  - penagwin 9y ago
    You just have to reflash it and it'll be just fine, only the data is corrupt. But that means that the whole OS has to be wiped; any saved files, programs, configurations, etc. are gone and have to be redone. Not the end of the world, but if that happens almost everytime you unplug something (possibly accidentally), it can be a huge nuisance. I use my pi with octoprint so I'm not even doing many writes (only on file upload).
    - slig 9y ago
      Thanks for clarifying.
monocasa 9y ago
I worked on a project professionally to find out why we were corrupting SD cards. Turned out that the SD card firmware is just garbage in a lot of cases. Ended up with a test program that could corrupt an SD card from a given manufacturer within a couple hours with slow (80kb/s) continous reads and writes from any hardware running Linux. The manufacturer couldn't have cared less and essientially blew us off despite having a support contract. Long story, short, buy 'industrial' SD cards if you care about them not getting corrupted.
- Ahmed90 9y ago
  Are you allowed to share the results of your experiment? i have a similar issue with a very limited market (SD Brands/models), it would be great if you provide more info :)
  - monocasa 9y ago
    I'd be hesitant to name any names due to NDAs and what have you. I'll just say that all consumer level cards pretty much don't really care about your data, even the good brands.
    - logicallee 9y ago
      I think I speak for everyone that we really appreciate what you did share here. For how to use what you've shared if we trust you, can you throw us a bone more than: >buy 'industrial' SD cards For example can you name a specific card? Or give us enough clues that we can do so? I for one take your advice very seriously but I don't know how to use what you've just shared. I've seen ATM-style Pi-based kiosks with corrupted SD cards that wouldn't boot. It looked expensive.
      - monocasa 9y ago
        ATP Inc. has treated us very well, both their products and their support. But in general 'industrial' is the keyword to get the good shit from manufacturers who'll treat you like an adult.
segmondy 9y ago
after how long? i've been running my pi off the usb port of my server. knock on wood, no issues yet.
geerlingguy 9y ago
I've had a number of Pis (currently 6) in continuous operation around my house for over two years now. One is running http://www.drupalpi.com/ http://www.drupalpi.com/ currently (uptime was 300+ days until last night when I re-flashed it)... I only use SanDisk Extreme and Samsung Evo+ cards now, but have not had any corruptions on any of these actively-used devices (most are either storing photos (e.g. time-lapse) and then dumping them to the cloud every week or month, or storing time-series data, so there are frequent writes. I wonder if you could provide what type of card you're using? Also the type and brand of power supply? Besides any of the cheaper cards (basically any brand besides SanDisk and Samsung, it seems) being flaky in my experience, the power supply being flaky (usually when I used a cheap 500 mA supply that came with some device for free) is the only other thing that _ever_ caused corrupt data for me.
- written 9y ago
  I have similar experience with SanDisk and Samsung EVO+. 9 Pi's (not raspberry) running continuously for ~2 years. No kernel panics/PostgreSQL failures. I run with data checksuming enabled. I also disabled options in PostgreSQL that cause periodic and unnecessary write activity. Frequent regular updates, periodic database activity (web scraping, environment monitoring, ...). Running on F2FS. I have logical replication setup in PostgreSQL, because I don't trust the SD cards anyway, but I have had no issues so far.
  - steelframe 9y ago
    I came here to suggest f2fs. Glad to see you're already doing that.
    - written 9y ago
      It works surprisingly well and it makes many operations faster than ext4. I noticed it especially when doing system updates. And I've just read yesterday, that F2FS in Linux 4.17 will have further optimizations for low end systems. Yay.
michrassena 9y ago
My first go around with the original Pi, I ended up burning out two micro SD cards in short order. The solution at the time was to mount the file systems read-only and put /tmp in RAM and do without swap (if I recall correctly). For my purposes this worked out fine, since the Pi was being used as a signage kiosk. Later I retired the original Pi and bought the series 3. I bought a much higher quality card, based on a similar performance and longevity article. Maybe something changed between versions of Pi, or maybe these cards really are better, but I haven't had the problem reoccur even with a read/write filesystem.
bscphil 9y ago
I recommend netbooting the Pi off a server. Not only is it easy to back up and restore, the performance on small reads and writes is probably better than you can expect from any mSD card, if the specs here are to be believed. Plus you don't burn out SD cards that cost at least half what the Pi does.
- geerlingguy 9y ago
  And as a bonus the Pi 3 B+ gets ~230 Mbps over LAN (whereas all the older models maxed out at ~93 Mbps), so netboot performance should be even better than in the past.
- StavrosK 9y ago
  Are there any good guides on how to do this? I never once got it working. Also, where do you persist data? NFS share?
  - bscphil 9y ago
    Yeah, it's unfortunately not the easiest thing in the world. I suggest cloning a working Raspbian installation to your server, pointing tftp at /boot (with the "--secure" option set so as to allow relative paths). You can then set up a rw NFS share on / for the Pi to boot off of (and lock it down with your firewall). You also need to point the Pi to the server via DHCP, which you can do in dnsmasq like so: dhcp-option=43,Raspberry Pi Boot dhcp-option=66,$SERVERIP I wrote up a more complete guide here a while back: https://adamfontenot.com/post/how_to_netboot_a_raspberry_pi_3_from_a_linux_server_with_tftp_and_nfs https://adamfontenot.com/post/how_to_netboot_a_raspberry_pi_... The other really cool thing you can do with this is install qemu emulation support for arm on the server and then use systemd-nspawn to chroot into your Raspbian installation. Then for any commands that don't need access to the Pi's ports, you can run them directly on the server. It's really nice to do updates this way, much faster than looping them through the Pi and its slow processor. Love following your projects, by the way.
    - mxvzr 9y ago
      Thank you so much for posting these two options; The RPI kept sending TFTP requests to the machine running the DHCP server despite my attempts to specify another IP (the "official" documentation specifies pxe-service=0,"Raspberry Pi Boot" to which I added the filename & ip as per dnsmasq man page; same thing with dhcp-boot parameter)
doctoboggan 9y ago
I built a product with an embedded rpi and dealt with this same problem. The solution was to purchase "industrial" SD cards. I ended up using ATP micro SD cards. You can find them on Digikey. They are almost double the price, but I have not had a single SD corruption since switching to them. In my experience the samsung SD cards would be corrupted when the power was pulled around 30% of the time.
elijahparker 9y ago
I don't know if it's an issue with the rpi or not, but I know that SD cards can draw current in short spikes during writes and need a good supply with good decoupling capacitors so there's not voltage drops, as these can cause corruption. In an embedded device I've designed (with careful capacitor selection), I've very rarely had any SD card issues (3 corruption cases in ~1000 devices over a couple years). I'm using Sandisk and Samsung class 4, 6 or 10 (depending on availability).
Abishek_Muthian 9y ago
My overclocked pi's & abruptly shutdown pi's were the primary reason for my corrupted SD cards. In my experience Toshiba Exceria M302 (built for action cameras) scores higher in longevity than Samsung EVO. I've abused the Toshiba SD card to get it corrupted & I've yet to see one.

msumpter 9y ago

And that's why I moved over to MMC based Pi clones (specifically the Rock64), I am overly tired of SD cards mysteriously corrupting themselves. As of yet, I haven't had an MMC go upside down, but that's certainly far from guaranteed as well.

zwieback 9y ago
Do you know how much of that is due to connector and signal paths? I worked on a design that had soldered on eMMC and it was rock solid (and 8 bit wide) but I always assumed SD problems were due more to the flaky form factor. Is there a standard for removable eMMC modules?
- dbuder 9y ago
  Yes it's like one of those double row press fit connectors usually used for displays in phones that fit better than they look like they will. If you are soldering in your first question is why am I using eMMC. SBC computers are a good use case for it imo.
copperx 9y ago
Is it possible for the rPi to boot from a USB device? One solution would be to hook it up to a $20 32GB SSD drive instead of relying on an SD card.
- wolrah 9y ago
  Depends on the model, or actually technically it depends on the bootcode but which version is preloaded depends on the model. The brand new Pi 3B+ ships with the latest bootcode and will boot from USB mass storage or PXE by default. Their PXE is a bit nonstandard but it's close enough that anyone who's PXE booted a PC will understand it. The older Pi 3 supports USB and PXE booting, but has those modes disabled by default. There's a bit you can set in one-time programmable memory to enable it permanently. PXE booting has some quirks in this mode and doesn't get along with switches that take more than a second or so to activate ports. Earlier models do not support anything but SD on their stock bootcode. In all cases, a SD card containing nothing but the latest bootcode can be inserted which brings the new features to the older models, allowing them to boot the rest of the OS from whatever.
- ygra 9y ago
  At least for the older models you still needed the card, but only for a marker that tells the Pi to boot from USB. I've been using that setup with Kodi/OSMC with a Pi 2 since USB is faster than the SD card.

kiddico 9y ago

Do you have an overclock running? Specifically sdram_freq.

penagwin 9y ago

Also losing power seems to result in a corrupt sd card 80% of time. Obviously it's bad to lose power while on, but that's crazy.

semi-extrinsic 9y ago
I had a GoPro develop a flaky voltage regulator so it would sometimes brown out, that thing killed microSD cards like a champ.
slig 9y ago
Once corrupted, it can't be re-used after formatting?
- penagwin 9y ago
  You just have to reflash it and it'll be just fine, only the data is corrupt. But that means that the whole OS has to be wiped; any saved files, programs, configurations, etc. are gone and have to be redone. Not the end of the world, but if that happens almost everytime you unplug something (possibly accidentally), it can be a huge nuisance. I use my pi with octoprint so I'm not even doing many writes (only on file upload).
  - slig 9y ago
    Thanks for clarifying.

monocasa 9y ago

I worked on a project professionally to find out why we were corrupting SD cards. Turned out that the SD card firmware is just garbage in a lot of cases. Ended up with a test program that could corrupt an SD card from a given manufacturer within a couple hours with slow (80kb/s) continous reads and writes from any hardware running Linux. The manufacturer couldn't have cared less and essientially blew us off despite having a support contract. Long story, short, buy 'industrial' SD cards if you care about them not getting corrupted.

Ahmed90 9y ago
Are you allowed to share the results of your experiment? i have a similar issue with a very limited market (SD Brands/models), it would be great if you provide more info :)
- monocasa 9y ago
  I'd be hesitant to name any names due to NDAs and what have you. I'll just say that all consumer level cards pretty much don't really care about your data, even the good brands.
  - logicallee 9y ago
    I think I speak for everyone that we really appreciate what you did share here. For how to use what you've shared if we trust you, can you throw us a bone more than: >buy 'industrial' SD cards For example can you name a specific card? Or give us enough clues that we can do so? I for one take your advice very seriously but I don't know how to use what you've just shared. I've seen ATM-style Pi-based kiosks with corrupted SD cards that wouldn't boot. It looked expensive.
    - monocasa 9y ago
      ATP Inc. has treated us very well, both their products and their support. But in general 'industrial' is the keyword to get the good shit from manufacturers who'll treat you like an adult.

segmondy 9y ago

after how long? i've been running my pi off the usb port of my server. knock on wood, no issues yet.

geerlingguy 9y ago

I've had a number of Pis (currently 6) in continuous operation around my house for over two years now. One is running http://www.drupalpi.com/ http://www.drupalpi.com/ currently (uptime was 300+ days until last night when I re-flashed it)... I only use SanDisk Extreme and Samsung Evo+ cards now, but have not had any corruptions on any of these actively-used devices (most are either storing photos (e.g. time-lapse) and then dumping them to the cloud every week or month, or storing time-series data, so there are frequent writes. I wonder if you could provide what type of card you're using? Also the type and brand of power supply? Besides any of the cheaper cards (basically any brand besides SanDisk and Samsung, it seems) being flaky in my experience, the power supply being flaky (usually when I used a cheap 500 mA supply that came with some device for free) is the only other thing that _ever_ caused corrupt data for me.

written 9y ago
I have similar experience with SanDisk and Samsung EVO+. 9 Pi's (not raspberry) running continuously for ~2 years. No kernel panics/PostgreSQL failures. I run with data checksuming enabled. I also disabled options in PostgreSQL that cause periodic and unnecessary write activity. Frequent regular updates, periodic database activity (web scraping, environment monitoring, ...). Running on F2FS. I have logical replication setup in PostgreSQL, because I don't trust the SD cards anyway, but I have had no issues so far.
- steelframe 9y ago
  I came here to suggest f2fs. Glad to see you're already doing that.
  - written 9y ago
    It works surprisingly well and it makes many operations faster than ext4. I noticed it especially when doing system updates. And I've just read yesterday, that F2FS in Linux 4.17 will have further optimizations for low end systems. Yay.

michrassena 9y ago

My first go around with the original Pi, I ended up burning out two micro SD cards in short order. The solution at the time was to mount the file systems read-only and put /tmp in RAM and do without swap (if I recall correctly). For my purposes this worked out fine, since the Pi was being used as a signage kiosk. Later I retired the original Pi and bought the series 3. I bought a much higher quality card, based on a similar performance and longevity article. Maybe something changed between versions of Pi, or maybe these cards really are better, but I haven't had the problem reoccur even with a read/write filesystem.

bscphil 9y ago

I recommend netbooting the Pi off a server. Not only is it easy to back up and restore, the performance on small reads and writes is probably better than you can expect from any mSD card, if the specs here are to be believed. Plus you don't burn out SD cards that cost at least half what the Pi does.

geerlingguy 9y ago
And as a bonus the Pi 3 B+ gets ~230 Mbps over LAN (whereas all the older models maxed out at ~93 Mbps), so netboot performance should be even better than in the past.
StavrosK 9y ago
Are there any good guides on how to do this? I never once got it working. Also, where do you persist data? NFS share?
- bscphil 9y ago
  Yeah, it's unfortunately not the easiest thing in the world. I suggest cloning a working Raspbian installation to your server, pointing tftp at /boot (with the "--secure" option set so as to allow relative paths). You can then set up a rw NFS share on / for the Pi to boot off of (and lock it down with your firewall). You also need to point the Pi to the server via DHCP, which you can do in dnsmasq like so: dhcp-option=43,Raspberry Pi Boot dhcp-option=66,$SERVERIP I wrote up a more complete guide here a while back: https://adamfontenot.com/post/how_to_netboot_a_raspberry_pi_3_from_a_linux_server_with_tftp_and_nfs https://adamfontenot.com/post/how_to_netboot_a_raspberry_pi_... The other really cool thing you can do with this is install qemu emulation support for arm on the server and then use systemd-nspawn to chroot into your Raspbian installation. Then for any commands that don't need access to the Pi's ports, you can run them directly on the server. It's really nice to do updates this way, much faster than looping them through the Pi and its slow processor. Love following your projects, by the way.
  - mxvzr 9y ago
    Thank you so much for posting these two options; The RPI kept sending TFTP requests to the machine running the DHCP server despite my attempts to specify another IP (the "official" documentation specifies pxe-service=0,"Raspberry Pi Boot" to which I added the filename & ip as per dnsmasq man page; same thing with dhcp-boot parameter)

doctoboggan 9y ago

I built a product with an embedded rpi and dealt with this same problem. The solution was to purchase "industrial" SD cards. I ended up using ATP micro SD cards. You can find them on Digikey. They are almost double the price, but I have not had a single SD corruption since switching to them. In my experience the samsung SD cards would be corrupted when the power was pulled around 30% of the time.

elijahparker 9y ago

I don't know if it's an issue with the rpi or not, but I know that SD cards can draw current in short spikes during writes and need a good supply with good decoupling capacitors so there's not voltage drops, as these can cause corruption. In an embedded device I've designed (with careful capacitor selection), I've very rarely had any SD card issues (3 corruption cases in ~1000 devices over a couple years). I'm using Sandisk and Samsung class 4, 6 or 10 (depending on availability).

Abishek_Muthian 9y ago

My overclocked pi's & abruptly shutdown pi's were the primary reason for my corrupted SD cards. In my experience Toshiba Exceria M302 (built for action cameras) scores higher in longevity than Samsung EVO. I've abused the Toshiba SD card to get it corrupted & I've yet to see one.