Musicbox - SD Card Corrupt! Fix by using Read Only file filesystem?

[PieterScheffers]

Every couple of weeks the SD card gets corrupted. When that happens I plug the SD in my PC and re-write the musicbox0.6.img on it using Win32DiskImager. I then copy over the settings.ini file to get access to my spotify profile. After putting back the SD in the Raspberry Pi 2, everything works again.

I've been checking some ways to make sure the system doesn't get corrupted from power outages for an other Raspberry Pi project. One way to do it is by using a read-only filesystem, with an unionfs for the parts that need write access. Or an seperate partition that gets recreated on boot (and the system reboots when it isn't writable anymore).

I was wondering if that would be possible with the musicbox image?

I don't need to be able to change any settings with the web-interface, so not being able to persist the settings wouldn't be a problem.

Sources:

• https://hallard.me/raspberry-pi-read-only/
• http://petr.io/2015/11/09/read-only-raspberry-pi-with-jessie/
• http://blog.pi3g.com/2014/04/make-raspbian-system-read-only/

[kingosticks]

I agree this would be a good improvement, it's something that has come up before and I've been looking into it a bit recently. My thoughts so far were leaning towards unionfs and steering clear of changing partitions.

Most people would want to use the web settings normally so supporting this would be good. It'd probably be enough to sync back the changes on shutdown.

[javieitez]

Hi there,

I also agree it would be a great improvement. On most music systems, the ideal setup would involve having the RPi hidden below a HiFi setup, and only turning it on when it's going to be used for playing music. In such cases, the SD card doesn't survive three power cycles without becoming corrupted.

Things I've tried, from the HowTos linked above:

• Removing the swap
• Setting the ro flag on /etc/fstab
• setting /var/log, /tmp and /var/tmp to tmpfs

removing packages doesn't seem necessary, since the Pi Music Box image seems to be already stripped of all unnecessary stuff. DHCP also works without linking to a different file.

For logging, I had to change the log path from /var/log/mopidy/mopidy.log to just /var/log/mopidy.log on /etc/mopidy/logging.conf. For some reason it wasn't able to create the subfolder on the tmpfs.

With only these changes, everything seems to work fine, but extremely slow. I'm not sure if this is a specific problem of 0.7 RC4, anyway. Other users have reported slowness in the forum as well.

Since the music is hosted in a remote SMB or NFS share, I think it would be clever to move the database there. I've tried digging on the folders and on the project documentation, but haven't found the path of it. Do any of you guys have an idea of where this path can be?

Apart from the DB, are there any other files or folders where the MPD service needs to write?

[kingosticks]

I personally don't see why you'd be switching the pi off and I maintain that's the ideal setup. However, I appreciate it's entirely up to you or it might just be logistically difficult with your power arrangement.

In 0.7.0rc4 there should already be no swap and a tmpfs at /tmp.

Mopidy doesn't try to create it's folder in /var/log and I think you'll find that's the case with other services that have their own subdirectory there (apache springs to mind). I'm not sure if that's some sort of debian best practice or something. Some other tmpfs logging setups I looked into would go and specifically create all the folders that were missing (which is derived from the target directory used to sync things to on shutdown).

I've heard of streams being slow to start but not slowness in general. Do you have examples of other slowness? Maybe we could work out where it's now unable to cache to. /var/cache maybe? Spotify expects somewhere like that, I don't recall where off the top of my head. Gstreamer might be using somewhere unexpected on the file system for it's buffering.

Are you using the MPD frontend? That is generally slower than the Http frontend, especially with streaming backends like Spotify.

I don't think you'd want to move the database to somewhere slower to access. You want the database local. Having a remote music directory should only result in slow scanning but then be unnoticeable. You're welcome to try it though: https://docs.mopidy.com/en/release-1.1/ext/local/#confval-local/data_dir

Other places to write:

• The playlists directory (if creating them)
• other random directories in /var
• a bunch of /etc files (if making system changes through settings.ini)
• probably others!

[javieitez]

Thanks for the feedback.

Well, I've just added /var/cache to the list of tmps dirs on fstab and have noticed a great improvement, even on an old RPi 1. Maybe something was trying to write to that dir constantly.

I'll take your advice about not moving the DB to a network share. I'm considering the idea of putting it into a separate USB drive. That would give faster and read-write access. Do you know what's the exact path of it?

[kingosticks]

In normal operation there are only reads, so I don't think there is much to be gained by moving it.

You can change the setting, it's actually https://docs.mopidy.com/en/release-1.1/config/#confval-core/data_dir that you want (different to what I said before). By default it's set data_dir = $XDG_DATA_DIR/mopidy which is /home/mopidy/.local/share/mopidy

[AurelFR]

I allways shutdown the pi thru ssh with putty-poweroff command.using for 1year ago without any data or sdcard coruption.
Sometimes when i wanna leasen fast i use moc player installed on pi and thru ssh on my laptop

[acca84]

Hello,
I'm new to pimusicbox. i have downloaded the latest image and i'm trying to follow those steps in order to make the system read only :
http://blog.gegg.us/2014/03/a-raspbian-read-only-root-fs-howto/

but the command : apt-get install busybox-syslogd gives me this error :

Reading package lists... Error!

E: Write error - write (28: No space left on device)

E: IO Error saving source cache

E: The package lists or status file could not be parsed or opened.

Do you think the method linked should work with pimusicbox ? can someone give me the steps to make pimusicbox read only ?

thanks !

[michaellunzer]

I'm not an expert but it looks like you're out of space. Have you expanded the filesystem?

I think there is a way to configure it in the settings.ini file so it happens automatically on the first boot.
If you're new to Pi Musicbox, you might not be aware of all the config options.

# ---------------------
# | MusicBox Settings |
# ---------------------


# Automatically resize the filesystem and use all available space on your SD card. 
# Use at your own risk, you could lose data on your card.  
# (If so, you can put the original MusicBox image on it again and start over) 
resize_once = true

[acca84]

Thanks you,; i did it using raspi-config, but it looks like it didn't work.

[kingosticks]

The latest image does this automatically.

[acca84]

I took musicbox_v0.7.0RC5 but it wasn't automatical

thank you for your great work !

[kingosticks]

Interesting. Thanks for the report, I'll take a look.

[acca84]

My system is box read only but i have no sound from my usb sound card (wich worked in rw mode).
Any advice To make it work please ?

[kingosticks]

Sometimes there is a buffer somewhere on the filesystem like /var/cache/gstreamer that needs to write.

…

On 23 Sep 2017 3:03 p.m., "acca84" ***@***.***> wrote: My system is box read only but i have no sound from my usb sound card (wich worked in rw mode). Any advice To make it work please ? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#373 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA5DqKdDtX7cpdgYM8ZnE-lEjEullV3tks5slQ_BgaJpZM4IyAyk> .

[acca84]

So, should i move /var/cache to tmpfs as javieitez did ?
Could you explain how to do it please ? :)
Sorry, im on my phone