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.
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.
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.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?
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
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.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?)mji wrote:Is there some way of physically write protecting the SD card, insuring that the raspberry pi cannot write to it?
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...milhouse wrote: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?)mji wrote:Is there some way of physically write protecting the SD card, insuring that the raspberry pi cannot write to it?
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...?
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?)dms75 wrote: It will even still be readonly when used on annother PC in a cardreader
The proper way to do it would probably be an extension to the kernel sdcard driver that could be used in the manner ofmilhouse wrote:dms75 wrote: Such a straight forward feature would be hugely appealing to the embedded market.
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.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"
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 ).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.