I’ve had issues with official rpi psu’s going low volts (around 4.8V) when one of the caps blows. Out of a batch of 6, two did exactly the same thing. I also lost loads of SD cards before I realised the problem because the pi would boot and run for a bit before it crashed. I don’t think the psu’s were designed to be left on for long periods. This happened using raspian, mp4museum and volumio on the SD cards in various different applications.
I’ve read somewhere that there has been a batch of official PSU’s with a too low output voltage. (unable to find it anymore)
@Evan, This will be my last reply to you.
and please take the test. Take a sequence of 10 loops and boot your Pi from a SD, during the boot process just pull the power plug after 5-10 seconds.
FAT, MFT, DFS, HPFS, EXT2, EXT3, EXT4 all share the same basics but a different implementation and/or improvements. It’s just a table, one or more, containing file/disk info registrations. One implementation is more sensitive to break down than others. A MBR, MDR or GPT stores the location tables itself or locations to them.
When people report they have been able to restore data, I assume something happened to the registration of these files and/or location.
Bottom line, with voltage drops or spikes a FS/SD can get damaged, by broken cells or unknown status of the file.
Sofar you’re not giving any useful feedback or helpful information.
When connecting my portable to battery I assure you that the power went on and off way more than 10 times at random points. And every upgrade and modification has involved reattaching and unattaching those same wires. You either have a faulty SD card or your pie is not getting enough current. Killing power doesn’t hurt it
1 Like
Give it up. Anyone with a long history of using Pis has a bagfull of dead SDs.
@SimonE LOL! Yeah, I killed the one on my main streamer when removing it. I don’t know if it was static or physically damaged because it was stuck and I had to use tweezers, but it happened during removal. Never killed one by power cycling though!
I turn off Volumio every night before going to bed by turn off the power switch from my LPS and turn it on in the morning. The reason is even Volumio running in idle, the LPS is still warm.
There is absolutely no problem with me. BTW, I’m using Samsung EVO 32GB mSD.
True, but you have to realise that most computers won’t like the power being pulled either…
pulling power =! turning off
… with risk of data corruption.
True since I first lost the firm’s supercalc data on a 5.25" floppy back in 1983.
And Volumio in 2022? 
But the system isn’t running entirely from RAM? It’s just an overlay system - the upper filesystem isn’t ramfs or tmpfs? (At least that is how I understood it, to be clarified - Volumio Architecture)
Not trying to say the system can’t be fault tolerant to SD card issues, but just trying to shed light on this aspect of no writes are being done post bootup by Volumio.
The OS is loaded into RAM and runs from there, However still there needs to be I/O to the SD, otherwise every change is lost on reboot?
And yes this is a more gray area for me. If i run a command like:
find . -mmin -60 -type f -exec ls -l {} +
No clue if it display’s Mem or SD data? It won’t run on a booted rpi and disconnected SD.
As I understand it - the initrd inital RAM disc is what is loaded into RAM, that prepares the rootfs which is then utilised to boot the actual OS.
In Volumio’s case, the rootfs is an OverlayFS, which is made up of a readonly squashFS for the “lower” part, and an ext4 part on the SD card for the “upper” part. This allows for system resets, OTA and other nice-to-haves. See relevant code - volumio3-os/init at 076bd9af8324cdf94fd31ff6fbdaba49389f67aa · volumio/volumio3-os · GitHub
So as I understand it, there is no “Loading the entire OS into RAM”. If so, you could pop out your SD card and have a volatile system (on RAM). This is not the case? Again - I could be wrong as @volumio keeps mentioning this a feature of Volumio.
PS: @DarkMantle I will move your WiFi posts to a new thread, and rename this thread to “SD card corruption” or something along those lines…
1 Like
When you consider the squashfs to be the complete OS, then it is sort of true, being read-only.
The system is still “vulnerable” for write errors in the upper part of the overlay fs.
But even then, when it won’t boot, you can still insert a usb-stick with a file “user-data”, boot and get an automatic factory reset. The chance of getting a fatal corruption on the boot or image partition is very small, even during the OTA update process, when data is written to boot and image partition.
Volumio doesn’t touch the partition table, doesn’t touch the bootloader and uboot sectors.
It is very unlikely that the Volumio operation itself is responsible for a corrupted SD card.
1 Like