Boot with SD readonly?


37 posts   Page 1 of 2   1, 2
by Mike McCauly » Mon Jul 09, 2012 11:21 pm
Hi,

Im building an unattended RPi system that is to show works of art on a big screen. Its intended to be no keyboard/mouse and off the net, and the power may go on and off unexpectedly.

I have it just about done, so that it boots to init level 5, auto logs in pi, and then auto runs feh fullscreen to display the art. All good so far.

The only thing left that Im concerned about is what happens if the power goes off unexpectedly.
As I understand it, there is a possiblility the SD card might get corrupted if this happens. Correct?

I tried setting the 'lock' switch on the side of the SD card and rebooting, but this does not seem to make the card readonly when it is mounted (ie I can still create files on it).

So....
Is it possible to force the SD card to mount readonly? How? and
will RPi still run happily like that?
Or does it need the swap partition at least to be writable?
Posts: 8
Joined: Sun Jun 24, 2012 9:47 am
by Mortimer » Mon Jul 09, 2012 11:28 pm
As far as I can tell, the write protect switch on the SD-card holder is not wired up. So the position of the write protect slider on the SD-card will not make any difference.
User avatar
Posts: 711
Joined: Sun Jun 10, 2012 3:57 pm
by Mike McCauly » Mon Jul 09, 2012 11:46 pm
Schematics confirm the SD card socket WP switch is not connected.

Mortimer wrote:As far as I can tell, the write protect switch on the SD-card holder is not wired up. So the position of the write protect slider on the SD-card will not make any difference.
Posts: 8
Joined: Sun Jun 24, 2012 9:47 am
by AndrewS » Wed Jul 11, 2012 10:27 pm
Have a look at how the initramfs image in kernel_emergency.img works - the entire rootfs is embedded inside kernel.img so after start.elf has loaded kernel.img into RAM, the SDcard never gets touched again. I guess you could then mount the SDcard read-only from /etc/fstab and load your images/slideshows/etc. from there.
User avatar
Posts: 3591
Joined: Sun Apr 22, 2012 4:50 pm
Location: Cambridge, UK
by KenT » Thu Jul 12, 2012 7:01 am
Mike

I'm hoping to do the same as you but for video playing in a visitor centre and sound effects in a museum. It would be super if you could write up how you have achieved unattended operation once it fully works.

TIA
Pi Presents - A toolkit to produce multi-media interactive displays for museums, visitor centres, and more
Download from http://pipresents.wordpress.com
Posts: 588
Joined: Tue Jan 24, 2012 9:30 am
Location: Hertfordshire, UK
by AndrewS » Thu Jul 12, 2012 12:22 pm
There's more information about using an initramfs/initrd in this thread (and the others it links to) viewtopic.php?f=63&t=10532
User avatar
Posts: 3591
Joined: Sun Apr 22, 2012 4:50 pm
Location: Cambridge, UK
by Mike McCauly » Tue Jul 17, 2012 9:09 pm
Hmmm, thats interesting.

But, even if that were done and the / filesystem were mounted RO, would not the kernel still need to write to the swap area on the SD card?

And if so, and the power went off half way through an SD card write, could it corrupt the SD card in a way that would prevent it booting next time?

AndrewS wrote:Have a look at how the initramfs image in kernel_emergency.img works - the entire rootfs is embedded inside kernel.img so after start.elf has loaded kernel.img into RAM, the SDcard never gets touched again. I guess you could then mount the SDcard read-only from /etc/fstab and load your images/slideshows/etc. from there.
Posts: 8
Joined: Sun Jun 24, 2012 9:47 am
by ksangeelee » Tue Jul 17, 2012 10:32 pm
If the system runs ok with a read-only root filesystem, you might also consider disabling the swap file (I never use swap, though my usage is likely quite different to yours).

An alternative, if you absolutely must have swap space, would be to have it, and perhaps some directories that you'd like to be writeable (e.g. /var/log, /tmp) on a USB stick. This could be checked and initialised during startup.

If you have both USB ports available, a second stick could be used as a backup if you're unlucky enough to have one fail (or your SD card could similarly act as a backup).
Posts: 193
Joined: Sun Dec 25, 2011 5:25 pm
Location: Edinburgh, UK
by Gert van Loo » Wed Jul 18, 2012 9:55 pm
Mike McCauly wrote:....
And if so, and the power went off half way through an SD card write, could it corrupt the SD card in a way that would prevent it booting next time?


Yes, that has happened. It seems to be card sensitive in that some SD-cards are more likely to suffer from it then others and it is not seen too often but it does happen.
User avatar
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 2039
Joined: Tue Aug 02, 2011 7:27 am
by alexchamberlain » Thu Jul 19, 2012 6:52 am
This should be as simple as editing /etc/fstab and changing everything to read-only. Having said this... consider using a different partition for /var (possibly even a tmpfs), so your RPi can still log stuff - Linux likes logging!
Developer of piimg, a utility for working with RPi images.
Posts: 121
Joined: Thu Jun 14, 2012 11:20 am
Location: Leamington Spa, UK
by jzu » Fri Jul 20, 2012 11:21 am
Here's my /etc/fstab which has been successfully tested by unplugging the power supply while running massive read operations (find /).
Code: Select all
proc            /proc     proc    defaults 0 0
/dev/mmcblk0p1  /boot     vfat    ro       0 0
/dev/mmcblk0p2  /         ext4    ro       0 0
none            /var/run  ramfs   size=1M  0 0
none            /var/log  ramfs   size=1M  0 0

Any idea to improve this setup, or to torture the system in various ways in order to find possible flaws?
User avatar
Posts: 26
Joined: Mon Aug 01, 2011 8:02 am
by jerrylamos » Wed Jul 25, 2012 2:00 am
The small distro Puppy runs in memory and doesn't write until shutdown optionally. I don't know how much it could do with 192 MB (rest of the memory for the GPU). They're working on Raspberry Pi versions see
http://bkhome.org/blog/?viewDetailed=02910.
The SD image is
http://distro.ibiblio.org/quirky/arm/te ... 105.img.xz
at 87.1 MB. I haven't tried it to see what packages it has. Puppy typically has internet with flash available, utilities, word processor, file manager, various display configs etc. but I don't know about this one.

Jerry
Posts: 27
Joined: Sun Jul 15, 2012 8:33 pm
by AndrewS » Thu Jul 26, 2012 1:20 pm
Puppy on RPi won't have flash, as Adobe don't have a publicly-available version of Flash for Linux for the ARMv6 CPU architecture the Pi uses. Everything else should be available though, as any open-source apps are usually easy to compile for different CPU architectures.
User avatar
Posts: 3591
Joined: Sun Apr 22, 2012 4:50 pm
Location: Cambridge, UK
by mji » Wed Oct 24, 2012 5:35 am
Is there some way of physically write protecting the SD card, insuring that the raspberry pi cannot write to it?
Posts: 16
Joined: Sat Jul 07, 2012 12:51 am
Location: Los Angeles, California
by itimpi » Wed Oct 24, 2012 5:42 am
mji wrote:Is there some way of physically write protecting the SD card, insuring that the raspberry pi cannot write to it?

I am afraid not. The slider switch on SD cards is advisory only to the host system, and anyway on the Pi is not even wired up in the pi's SD socket.
Posts: 1034
Joined: Sun Sep 25, 2011 11:44 am
Location: Potters Bar, United Kingdom
by mji » Wed Oct 24, 2012 5:49 am
I've done a bit of googling and it seems that there are 3 ways of write protecting an sd card... One is the the physical switch that can be ignored by a reader. The others involve setting particular bits on the SD card. One of the bits cannot be re-written once it is written (permanent write protection) What I'm not sure I'm understanding is if these bits are also simply read by the card reader (which can then also decide to ignore them) or if the firmware in the card will prevent further writes. I think it's the latter, but I was wondering if anyone has any experience with this and the raspberry pi.
Posts: 16
Joined: Sat Jul 07, 2012 12:51 am
Location: Los Angeles, California
by dms75 » Wed Oct 24, 2012 8:54 am
Hi,

since I have used sdcards in several microcontroller related projects,
I might as well give some hints how it could be done.

In theory you can set the write protect Bits in the CSD register of the sdcard.
Accessing them on the Pi is not quite so easy though.
First those writeprotect-bits are processed by the sdcard itself and provide real protection,
unlike the slider on the card where it's in the responsibility of the cardreader
to respect the writeprotection setting (which it doesn't).
Physically those bits are implemented in flash cells, even the permanent write protect bit,
but the sdcard firmware won't let you reset the permanent one once it has been set to 1.
The permanent write protect bit can easily render your card useless, you won't be able to format it.
Not even a force_erase operation will recover the card.
It will really be read only rom-like card after setting this bit.
So be warned.
For testing stay with the temporary write protect bit wich will suffice for your needs,
since it cannot easily be set or reset by the regular RPi sdcard slot, which brings us to the tricky part.

The problem will be to send the sdcard the appropriate PROGRAM_CSD command (CMD27)
with the right writeprotect bits set (temporarily or permanently).
The spi driver in the kernel will only give you access to write normal data to the blockdevice
and you don't have access to send specific commands to the card.
So you'd have to modify the spi driver to provide extra functionality.
Unless you have experience in writing linux drivers this is probably not the easiest approach to take.
It might be easier to wire the SDCARD to the GPIO Port in SPI Mode and send the initialising
sequence and the CMD27 to the card wia the SPI port or via Bit-banging.
This will require connecting of a second sdcard slot to the GPIO Pins.
You'll only need this slot to set the write protection, once the card is write protected
you'll use the card in the regular SDCARD slot.
Ofc. you could use a microcontroller to write-protect the sdcard in the first place,
if you happen to have a microcontroller developmentboard lying around -
preferably one already fitted with a sdcard slot ;-)
Software for bitbanging GPIOs and to access sdcards wia spi protocol should be easy enough
to find on the net, most microcontrollers communicate with sdcards this way,
and most microcontroller verndors provide spi libraries or even sdcard libraries for communication.
If you want to take that approach I could provide you with the spi command sequences needed
to initialize the communication and to write protect the card if you need them.

Dirk
Posts: 25
Joined: Mon Aug 06, 2012 1:41 pm
by milhouse » Wed Oct 24, 2012 9:33 am
mji wrote:Is there some way of physically write protecting the SD card, insuring that the raspberry pi cannot write to it?


Not in hardware, presumably a firmware change would be required to prevent all writes to SD card (hmmm, wonder if Dom would consider adding a cmdline.txt/config.txt option to disable SD card writes?)

Edit: Or maybe the cmdline.txt/config.txt "write protect" option could simply set the temporary CSD writeprotect bit (as described by dms75) during boot...?
Posts: 555
Joined: Mon Jan 16, 2012 12:59 pm
by dms75 » Wed Oct 24, 2012 10:02 am
milhouse wrote:
mji wrote:Is there some way of physically write protecting the SD card, insuring that the raspberry pi cannot write to it?


Not in hardware, presumably a firmware change would be required to prevent all writes to SD card (hmmm, wonder if Dom would consider adding a cmdline.txt/config.txt option to disable SD card writes?)

Edit: Or maybe the cmdline.txt/config.txt "write protect" option could simply set the temporary CSD writeprotect bit (as described by dms75) during boot...?


someone that used such a config.txt option would have a hard time getting rid of this option since when set the /boot directory will be readonly...
It will even still be readonly when used on annother PC in a cardreader, and I'm not sure wether a format from a PC actually does a force_erase on the sdcard, probably it would just fail.
I suppose a jumper between Pin number 6 and pin Number 4 on the GPIO Header will still load the emergency kernel and causes the firmware to ignore the config.txt, so it would still allow to recover form this situation if the firmware would reset the temporary CSD writeprotect bit when starting the emergency kernel.

Dirk
Posts: 25
Joined: Mon Aug 06, 2012 1:41 pm
by milhouse » Wed Oct 24, 2012 10:14 am
dms75 wrote:It will even still be readonly when used on annother PC in a cardreader


Ah, so what you described as a "temporary" setting, I took to mean would be cleared when power is removed from the SD card (which would allow the config to be edited in a PC). So it's a non-volatile setting, but which isn't write-once. My misunderstanding. Still, one option would be as you described - boot the emergency kernel to clear the write protect bit (or a vcgencmd command to clear it?)

Such a straight forward feature would be hugely appealing to the embedded market.
Posts: 555
Joined: Mon Jan 16, 2012 12:59 pm
by dms75 » Wed Oct 24, 2012 1:00 pm
milhouse wrote:
dms75 wrote:Such a straight forward feature would be hugely appealing to the embedded market.


The proper way to do it would probably be an extension to the kernel sdcard driver that could be used in the manner of
"echo 1 > /sys/class/mmc_host/mmc0/mmc*/temporary_writeprotect"
That would allow to set and to unset this Bit. It could be implemented for the permanent write protection bit too, just not resettable ofc. It is not necessary to touch the bootloader at all for this kind of functionallity.

Dirk
Posts: 25
Joined: Mon Aug 06, 2012 1:41 pm
by jojopi » Wed Oct 24, 2012 1:21 pm
dms75 wrote:The proper way to do it would probably be an extension to the kernel sdcard driver that could be used in the manner of
"echo 1 > /sys/class/mmc_host/mmc0/mmc*/temporary_writeprotect"
If you did this while any partition was mounted read-write then the card would effectively be locked in a dirty state, and the system would likely crash, and on future boots fsck would not be able to repair the filesystem. And if the distro expects to be able to mount the root filesystem for writing, then it will probably not even boot correctly with the card protected.

So basically this whole idea is wrong. It is the operating system that needs to support not writing to the card. You cannot try to impose the restriction upwards from the hardware.
User avatar
Posts: 2040
Joined: Tue Oct 11, 2011 8:38 pm
by jzu » Wed Oct 24, 2012 1:28 pm
Remember my previous post with the /etc/fstab file? It works with minimal hassle, plus you can modify the contents on another computer.
User avatar
Posts: 26
Joined: Mon Aug 01, 2011 8:02 am
by dms75 » Wed Oct 24, 2012 1:48 pm
jojopi wrote:So basically this whole idea is wrong. It is the operating system that needs to support not writing to the card. You cannot try to impose the restriction upwards from the hardware.


I totally agree that for itself it would not be very usefull. Setting up the whole system with a initrd and ro mount of the root filesystem should provide ample protection against sudden power loss. Additionally setting the WP Bit would however give some additional safeguard against remounting the sdcard rw or low level write access with dd, gparted, fdisc etc. This is probably not relevant unless you wanted to restrict users from messing with the card (as in setting the permanent write protection bit to prevent your sister/brother/wife from borrowing the card for the camera - just kidding :twisted: ).

Dirk
Posts: 25
Joined: Mon Aug 06, 2012 1:41 pm
by milhouse » Wed Oct 24, 2012 1:59 pm
Yes, it really was for belt and braces - of course if the OS expects to be able to write to the card, then it's going to end in major failure if it discovers the medium write protected... :)
Posts: 555
Joined: Mon Jan 16, 2012 12:59 pm