SD-card destroyed by power-off ???

[lagerschaden]

Hi,

it ist well known, that a SD-card can be destroyed when you power-off a Raspberry-Pi without a shutdown. Does the same issue exist with an Orange-Pi (One) ?

I want to use an Orange-Pi One headless and without SSH/TTY, only some sensors and LEDs are attached.

Tnx L

[botfap]

You are mistaken. There is no possible way, outside of a hardware fault, for any SBC to destroy any sd card on shutdown or power off. 

 

You might corrupt the fat32 boot partition on a ras pi which will prevent it booting till you reflash the sd card but it won’t break it unless there was already a fault with the sdcard or SBC. This isn’t the fault of the SBC or sdcard though, it’s more to do with poor design decisions with raspi software. 

 

Arbian doesn’t use a fat32 partition, presumably because it’s a shitty, unreliable solution for most use cases, though there are a few scenarios where fat32 for boot is the only option.

[tkaiser]

2 hours ago, lagerschaden said:

SD-card can be destroyed when you power-off a Raspberry-Pi without a shutdown

 

This is about filesystem corruption and on the 1st generation Raspberries (A and B, not including A+/B+ and all the later variants!) there was a nice underpowering <--> SD card failure relationship: https://tech.scargill.net/a-question-of-lifespan/#comment-34055 (reading through all the comments there is also interesting since you can easily see that a lot of Raspberry Pi users consider SD cards totally unreliable).

 

That being said if you do not properly shutdown an Armbian installation filesystem corruption can occur as well though I never ran into this if not the SD card itself became corrupt (they all do after some time but this is just due to wear out or physical damage -- I just cooked one to death recently). Armbian's rather high commit interval of 10 minutes might add to this behaviour as well as an fsck running at boot if necessary (initrd). But if you have to deal with power losses you should not trust in filesystem self-healing but prepare for the worst (using a read-only rootfs, just search the forum for recipes)

 

45 minutes ago, botfap said:

there are a few scenarios where fat32 for boot is the only option

 

Not on any of the boards Armbian supports. The only SBCs I own that really need a FAT partition to boot are Raspberry Pis since there the primary OS that runs on the VideoCore IV can only be loaded from FAT due to the 1st stage bootloader living in the SoC not able to deal with anything else (that's also where the 'use SD-Formatter and format your SD card prior to usage' BS originates from since Raspberry Pis can not deal with ExFAT too while all modern SD cards exceeding a certain capacity ship preformatted with ExFAT. SD-Formatter is only needed with Raspberries Pi, SDXC cards and when the user wants to run NOOBS)

[botfap]

I didnt mean Armbian specifically. We support boards where we only have a binary uboot available and nearly always when this happens the binary only has fatload support. I was (badly) trying to point out to OP that the probability is fs corruption on unclean shutdown is obviously a lot higher with fat32 than with ext4.

[lagerschaden]

I am very nosey, therefore I made a little test:

Yesterday I took my Orange Pi One and a SD-Card Exceria by Toshiba and Armbian https://dl.armbian.com/orangepione/Ubuntu_xenial_default.7z and every 10 minutes I switched it off for some seconds and on again for another 10 minutes and off again for some seconds and on again .... (of course I did it not by myself but another SBC via crontab, GPIO, a transistor and a relay). Every time the OS started a little python script did some dummy things and the time was written via network to another computer to see if the OS ist still ok. Now it was running for >25 hours -> 152 x switched off and on and everything ist still ok.  I think, that's enough.

L.

[tkaiser]

23 minutes ago, lagerschaden said:

I think, that's enough

 

I think, testing through a 'worst case' scenario would be also or even more interesting. Powering off while the sync call is executed below:

dd if=/dev/urandom of=tempfile bs=10M count=100 ; sync

BTW: Last year in March and April I also tried very hard to get filesystem corruption on SD cards and simply stopped using 'shutdown' any more. Maybe tested also +100 times, never occured a problem but still this is not a good idea since when filesystem structures are updated at the same time power is lost there will be corruption for sure (and you should have a serial console ready to deal with the 'UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY' situation then)