3 ms·

It's fairly straightforward if you know what you're doing. I did it myself, I had been meaning to put a blog together about it but never got around to it, you k

It's fairly straightforward if you know what you're doing. I did it myself, I had been meaning to put a blog together about it but never got around to it, you know how these things go. I'm happy to give some pointers or find something that looks suitable when I get home, if you like. Edit: This is pretty close to what I've done with mine: https://petr.io/en/blog/2015/11/09/read-only-raspberry-pi-with-jessie/ https://petr.io/en/blog/2015/11/09/read-only-raspberry-pi-wi... When I need to update I just run the remount command (IMPORTANT: on both /boot and /), make your changes, perform your updates, clean up the apt cache, then remount read-only or just reboot.

kingosticks 8y ago
I'm concerned that as density increases and TLC (and QLC) sd cards become the norm, the controllers will be forced to implement read-levelling as most SSDs already do. Once that happens, even your read-only filesystem is going to start doing writes and then we are back to square one.
- alias_neo 8y ago
  It's not perfect, but this isn't a replacement to the tried and tested, fail-safe method of backing things up. Any decent safety solution needs to be multi-tiered; I backup my configs to Git, make a backup of the now read-only filesystem after you've set this up and put it somewhere safe, and when the worst happens, restore to a new card, or build from the backup configs. I don't keep anything critical on Pi SD cards, that's why losing so many cards has been little more than an inconvenience. For read-only filesystems, a simple copy of the card in multiple locations, on and off-site is good, for read-write, backups configs to Git, RAID arrays and off-site. If the system is time-critical, first, I would suggest not running it on a Pi, use something more reliable (I moved my home automation to a NUC because it's more reliable than the Pis were), or, use multiple Pi's in redundancy, even half a dozen Pis is cheaper than a NUC if your use-case supports distributing the load.
  - kingosticks 8y ago
    It's just a big hassle when you've got a machine that you wanted to provision and forget about. I think I'll just move to booting from nfs and be done with it.

kingosticks 8y ago

I'm concerned that as density increases and TLC (and QLC) sd cards become the norm, the controllers will be forced to implement read-levelling as most SSDs already do. Once that happens, even your read-only filesystem is going to start doing writes and then we are back to square one.

alias_neo 8y ago
It's not perfect, but this isn't a replacement to the tried and tested, fail-safe method of backing things up. Any decent safety solution needs to be multi-tiered; I backup my configs to Git, make a backup of the now read-only filesystem after you've set this up and put it somewhere safe, and when the worst happens, restore to a new card, or build from the backup configs. I don't keep anything critical on Pi SD cards, that's why losing so many cards has been little more than an inconvenience. For read-only filesystems, a simple copy of the card in multiple locations, on and off-site is good, for read-write, backups configs to Git, RAID arrays and off-site. If the system is time-critical, first, I would suggest not running it on a Pi, use something more reliable (I moved my home automation to a NUC because it's more reliable than the Pis were), or, use multiple Pi's in redundancy, even half a dozen Pis is cheaper than a NUC if your use-case supports distributing the load.
- kingosticks 8y ago
  It's just a big hassle when you've got a machine that you wanted to provision and forget about. I think I'll just move to booting from nfs and be done with it.