Running on read-only SD card

Question

I have setup the Raspberry Pi to run XBMC, and I want it to boot up to always play a playlist and files on the SD card. I have turned off the Raspbmc automatic update. It still runs okay when I switch the SD card to the "lock" position. Now my qeustions are:

1. Will the "read-only" SD card system works all the time in my application?

2. Since the SD card is always in read-only mode, if I do not use shutdown command, and just turn off the power switch, will it damage my system?

3. Even if this works reliablely, it will always pop-up the message "Raaspbmc did not shut down properly". Is there any way to disable this message when the Pi powers up?

Answer 1

I had a similar use. I'm using the Pi for narrowcasting web-pages in a building entrance. Powering the Pi via the USB-port on the TV.

Mount / read-only.

To make it powerloss proof I mounted / read-only by changing a line in /etc/fstab

/dev/mmcblk0p2  /               ext4    defaults,noatime,ro  0       1

Pretty simple. But some processes on a functional machine need to write.

Mount /tmp in memory.

Many things write to /tmp so I mounted that in memory by adding a line to /etc/fstab

tmpfs           /tmp            tmpfs   defaults,size=30M    0       0

I had a 512MB Pi available so I made /tmp 30M big.

Disable services I don't need that write.

I disabled rsyslog to stop it from logging and dphys-swapfile as it has no real place to write. Running without swap will give problems if you do heavy lifting that is memory intensive. In my case running a single midori process for a day, isn't. cat /etc/rc2.d/README on your Pi on how to do that. (raspbian starts in runlevel 2 by default, raspbmc may differ)

Let services I do need faux-write.

You can provide write access to a filesystem in memory the way a live-cd does it; with a union mount. But I didn't like the prospect of cross-compiling my own kernel for unionfs or the later aufs. Luckily unionfs-fuse is prebuilt available. It can't union mount /, but do I really need that?

Running midori I need X to work. X wants to write in /home/pi as I autologin as pi and to a couple of places in /var I decided to mount those to places using unionfs.

# move original /var and /home aside
mkdir /ro
mv /var /ro
mv /home /ro
# create mount points
mkdir /var /home

and appended 2 lines to /etc/fstab

unionfs-fuse#/tmp=rw:/ro/var=ro  /var  fuse   cow,allow_other,nonempty
unionfs-fuse#/tmp=rw:/ro/home=ro  /home  fuse   cow,allow_other

This is pretty nasty, as writes to /var, /home and /tmp all endup in /tmp. But I only need my machine to run for 8 to 10 hours, and then the power gets cutoff. So this will do.

Remounting read-write when tweaking stuff

When I changed networks, the /etc/resolv.conf that dhclient wrote didn't work anymore.

$ sudo mount / -o remount,rw
$ ifdown eth0; ifup eth0
$ sudo reboot

Don't forget to shutdown cleanly, or remounting ro after remounting rw.

PS

If you can read German, there is a cleaner way (from archive.org). Deutsche Gründlichkeit...

Answer 2

SD card lock position pin is not connected at all on pcb, so your locking is virtual unless the card has internal locking mechanism. Try to write anything to SD card while it's locked and check it yourself.

Answer 3

SD's read-only switch is, at best, a software option. Almost every device I have will ignore it, and if avra's comment is correct, the Raspberry Pi may have no way to tell if it's on or off. So, to your questions:

1. Yes, it will work, because it's not read-only.
2. Yes, it will damage your system. You'll need to look at mounting root read-only, and having a small ram/tempfs file system for the things that Linux needs to keep track of.
3. No, because there's a good chance you will have damaged the filesystem.

Answer 4

1. I have not used XBMC, but this is not a good idea WRT to a normal operating system unless you go to some lengths to set it up for that purpose. By implication, if XBMC isn't explicitly set up so, then it is not a good idea for it either.

2. If the card really is read only, actually it will NOT damage your system, however, if it were really read only, you are unlikely to get to the point where you could run 'shutdown'. If you did (meaning again, you are certain the entire card really is read only!), don't bother running shutdown. Just pull the plug. Since nothing on the card can change, it does not matter what you do.

3. Sure, you could find the init files responsible and edit them (obviously, the filesystem will have to be writable to do that).

Realistically, if you do mount the root filesystem read-only (that may be harder than just using the lock toggle), you probably won't get a successful boot, because the OS does need to write to disk. HOWEVER, if you do, then feel free to do whatever you want (and can get away with). If the card is read-only it cannot be changed, so you can't do any harm.

Answer 5

If you just do

1.

/dev/mmcblk0p2 / ext4 defaults,noatime,ro 0 1
/dev/mmcblk0p1 / vfat defaults,noatime,ro 0 1
you have a full read only system.

2.

You can start Xorg with: -logfile /tmp/Xorg.log, and find other service which needs write access, redirect them to /tmp

3.

As already mentioned, disable service you dont need with

insserv -r dphys-swapfile
insserv -r rsyslog
insserv -r samba (if installed) etc

then there should no problem at all. The good question is if there will be really no damage to SD card at all if RO only and plugin / out power all the time...

Finally, a beautiful splash screen and there you go, you have a custom cheap standalone appliance. :) And I love the Idea to power the PI over USB port from TV. But is that not limited to 500mA? Not sure, but PI needs approx 1A or not?

Answer 6

A quick look into this online suggests that no one has posted any solution to this for the latest version of XBMC.

The main issue as Goldilocks pointed out is XBMC wasn't designed with the intention of making it read only. This point is furthered if you take a look at this thread on the OpenELEC Media Center Forum. The general consensus there is its not possible to make Kodi read only.

The reason according to the user klojum was:

To have OpenELEC work on a readonly device will not happen. Kodi needs to store/update its databases with video information. The system partition set up as readonly for a reason. All settings go via the 2nd, /storage partition. So removing that, via the cmdline or otherwise, is not an option. Restoring the system after each reboot is insane. Install OE, make it running to your wishes and make a full backup/image. Restore that in case of trouble

There might be a way round this as people have found workarounds for older versions, but in general I don't think there is any need to.

I can understand as someone who has used Kodi for a couple of years the annoyance of an SD card becoming corrupted. But there are other simpler ways to mitigate the problem that don't included low level code tinkering.

The number one reason an SD card will become corrupted is if there is a sudden power outage. There are couple of reasons as to why this can happen. Either someone disconnects the power to the Pi mid-way through a write to the SD card. Or the system freezes and you have to disconnect the power. Although, I think the second reason is less likely to cause corruption. Or it suggests there is another fault at play.

In the early days of the Pi the power delivery circuit on the board certainly left something to be desired. I can remember the days of causing a system crash simply by plugging in a USB dongle to the Pi whilst it was powered on. If you don't believe me see problems running XBMC on 2011 Raspberry Pi. The other issue is the software in the early days was not fully mature. The Pi was a different take on what a desktop computer could be and ironing out software issues takes time. So, much newer versions of Kodi are less likely to suffer from random system freezes.

To solve the sudden power loss problem power your Pi through some kind of uninterruptible power supply (UPS). A regular UPS would work but there are actually specifically Pi designed UPS's. Like this Uninterrupted Power Supply for Raspberry Pi. If a system freeze does happen it should be something you are prepared for. This means setting up the OS with all of the settings and apps and preferences to your taste and then making an image of the SD card. So if something goes wrong you can just re-image the SD card.

The other reason an SD card will fail is due to it wearing out. However, this isn't a problem I have experienced myself. If you use a high quality SD card from a reputable brand I think you are probably half way there to solving that problem. To minimize SD card wear means ensuring the SD card is doing the absolute minimum. It shouldn't be used as storage space for your vast collection of films e.t.c...

An option that will work with OpenELEC is running it off a USB drive. Of course all of the boot files will have to remain on the SD card. There are a number of tutorials on how to do this. There is one that looks quite easy to follow here, but for completeness I will give you an overview:

The first step is setting up the SD card and USB drive. Using a program like MiniTool Partition Wizard format the SD card as FAT32 with a primary active partition of 150MB or larger, in fact the entire SD card could be formatted as FAT32. Just make sure the partition is set to primary active. It might also be useful to label the SD card as something like SYSTEM so you remember what its for in the future. Then format the entire USB drive as one primary active partition with the filesystem type as EXT4, again its worth labeling it as something like STORAGE.

Once you have downloaded and extracted OpenELEC go to the root folder. And select these files:

openelec.ico
README.md

And copy them to the root of the SD card.

Next from the target folder copy the files:

KERNEL
SYSTEM

And again paste them into the SD card's root directory.

Then from the 3rdparty/bootloader folder copy the files:

bootcode.bin
config.txt
fixup.dat
LICENCE.broadcom
start.elf

And paste them into the root directory of the SD card.

The final step is to change the filename of the file KERNEL on the SD card to kernel.img.

To create the startup files, in the root directory of the SD card create a file called cmdline.txt and add the following line to it:

boot=/dev/mmcblk0p1 disk=/dev/sda1 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 ssh

Be sure to close the file with saving it. And from there you are good to go. The source of the information suggested running XBMC off a USB drive increased responsiveness. I'm not so sure about this claim, but you are not going to see any performance degradation as a result of using this method.

As for your media collection I suggest storing that on a second drive whether it is USB or a network location.