Seriously, what is wrong with Volumio?

yeah please dig into this before stating that something is not true. I am not talking about a single file, I am talking about the MBR or allocation/index table(s), during booting. I am pretty sure servers don’t use SD cards.
You should google it, only 500000+ hits, so yes it’s rare and it’s not happening and a big hoax.

You seem to ignore one thing: since Raspberry PI 1 (we’ve seen many…) the SD Card of PI is the most brittle part of the system, when the power supply is not adequate.

Reason is: if the internal voltage drops too much below 5V ± 0,25 volts, the SD Card has a high probability to loose data.
Want a proof?
Start your PI, then connect a very power hungry device to it, it will fail to restart after few times you do it (happened to me today with a PI running octoprint and a big LED lamp connected via USB).

The reason why I suggest to power both at the same time is that you might be triggering something funny in the communication (I2C) bus between the PI and the hat.
I’ve seen it happening quite often (when using a I2S DAC with external power and having left on). Hence my suggestion.

Last, people is helping you, this is not a competition where we try to be right, but just to help. If you don’t want to listen what people have to tell you, don’t bother to ask.

Aren’t you talking about an I2S DAC? What does it have to do with USB?

As you say, it’s a workaround, not a solution. That’s why it did not get in.

I rarely get irritated… this is one of such cases…

I just actually upgraded the power supply to a toroidal dual linear 5 volt 25 watt unit. I’ll see if this helps with my issue of dropping the Digione as a playback option on power cycles. Before I was using a a regular stock Pi supply and the USB 0.5 amp supply from my amp on the clean side. Now I’m sure I have enough stable power. It sounds better, I can tell you that. By the way, how do I grab log and when would I grab the log so you can see what’s happening on the boot up?

1 Like

Are you trying to say that the master boot record was in the process of being rewritten when you powered down? If so you have way more problems. The fat file system is the only one that has file allocation tables that might have been modified. That would mean the boot file system which isn’t even mounted during normal operation. If somebody else commented not having sufficient current on your power supply maybe an issue. I would look there before blaming power down and power up sequences that’s just not going to be the issue. But feel free to ignore my advice and continue looking in the wrong direction

No not i2s but USB DAC. One which is powered off when I switch away from that input. So basically it left me with a broken system that I had to reboot all the time. The work around at least allowed me to use the system without having to reboot.

I just wish support would get back to me so I can get a refund since I no longer use volumio at all. You guys basically took my money and ran!

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!

12 posts were split to a new topic: WiFi refues to connect

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? :smiley: :wink:

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