interestingghans wrote:The RPi ignores write lock. (cheap card slot)
Code: Select all
log in as root apt-get install fsprotect vi /etc/default/grub Change the line GRUB_CMDLINE_LINUX_DEFAULT and add fsprotect=15% to the command Run update-grub reboot create a file reboot verify file is gone after reboot
we don't have GRUB on the Pi, so like nobradvido wrote:This is what I did on my test VM
I don't have my RPi yet, but i'm going to be installing Raspbmc which uses grub:Licaon_Kter wrote:we don't have GRUB on the Pi, so like nobradvido wrote:This is what I did on my test VM
http://www.raspbmc.com/wiki/technical/partitioning/ wrote:"The fat32 partition contains the firmware files and is mounted at /boot to emulate a traditional Debian setup which stores GRUB there"
No, that's not quite what it's saying. It's saying a traditional desktop would store parts of GRUB in /boot, but on the Raspberry Pi, you'll find firmware files there.bradvido wrote:I don't have my RPi yet, but i'm going to be installing Raspbmc which uses grub:Licaon_Kter wrote:we don't have GRUB on the Pi, so like nobradvido wrote:This is what I did on my test VM
http://www.raspbmc.com/wiki/technical/partitioning/http://www.raspbmc.com/wiki/technical/partitioning/ wrote:"The fat32 partition contains the firmware files and is mounted at /boot to emulate a traditional Debian setup which stores GRUB there"
To enable fsprotect you need to add the fsprotect kernel option. The fsprotect parameter takes one optional argument, which it passes to mount(8) as the size option of the tmpfs. It is the size in bytes, and K/M/G suxes can be used as multiplicators. If no argument is specied, mount(8) will create a tmpfs with size half the system's memory. The syntax is fsprotect=size, where size can be any size that can be under-stood by mount. For example: fsprotect=1024M or just: fsprotect
As stated in the first post, i don't want to have a battery backup solution. I want to be able to kill the power at any time and have it return to its original state without any risk of corruption.Alfadaz wrote:I used to do a fair bit of in car PC stuff back in the day and i would be looking to set it up as follows:
Have the Pi powered from the battery - obviously not directly to the 12v, but your power supply would be always on regardless of the ignition.
Then look at a relay system which would send a signal via the GPIO to the Pi to perform a shutdown and turn on with the ignition.
If you wanted to get clever, i once made a little circuit with a timer, that kept the PC alive for 30 seconds following the ignition being turned off. If you pressed the button i had installed on the dash, the relay wouldnt switch and the pc would stay on until the next time the ignition was turned off or you shut it down manually. This was good when say you stopped in a shop etc when you wanted to the keep the PC running (mine was running XP, so took a while to bootup/shutdown).
if you want to use a XBMC based distro, you should look at OpenELEC (http://www.openelec.tv). It is designed for such usecases from ground up. the needed read/write parts are done in ramfs mounts (and will be recreated on boot), the storage where the user can store the medias and XBMC saves the database and settings on changes. the rest is readonly and nearly "unbrickable".bradvido wrote:I'm planning on using my RPi in my car and having it suddenly lose power when the car turns off. I understand this would inevitably cause corruption on a typical SD card installation where data may be writing to the card when it loses power.
I'm wondering if there is some way to set up an SD image to be like the Linux "live" CD's where nothing is actually written to the disk, it is only read?
Preferably, I would be able to configure the image to my liking before I set to to be read-only/live.
Please don't suggest to have some sort of battery backup to gracefully shutdown the RPi when the car turns off.... this is not the route I want to go.
The root fillesystem must be protected at the very first stages of the boot procedure. This is done during the initramfs boot stage where the root filesystem is mounted but hasn't become / yet (no pivot_root done). This is accomplished by adding a local-bottom script to the initramfs.
yes, the PI ignores the write lock, but it has nothing to do with the card slot, as the card slot has a write lock switch, its just not connected up, as a normal distro needs to be able to write to its storage medium, so the designers of the PI didn't think it necessary to wire up the switch.ghans wrote:The RPi ignores write lock. (cheap card slot)