2

For a Raspberry 4 setup, I'd like to keep the Raspbian's system files separated from the configuration files (i.e. /etc/resolv.conf), temp files, user files and user-installed applications. This said, I'd like to move all core system files into onto partition and all the other files onto a separate partition, with the ultimate goal to make the system partition read-only and the other partition(s) read-write.

My intention for this setup is three-fold:

  1. Set up a backup mechanism which would only back up non-system files.
  2. Make sure that I (or another user) don't accidentally change system files.
  3. Increase the longevity of the SD card by disabling write access to it once the system is set up.

Would such a setup facilitate my intentions? Are there better ways to achieve these goals?

  • the guy with the swiss accent - youtube.com/watch?v=gp6XW-fGVjo – Jaromanda X Apr 4 at 9:42
  • "What do you think?" this is a fantasy! – Milliways Apr 4 at 9:56
  • Welcome. You can do something along these lines if you want -- "along these lines" because the distinction you are trying to make needs to be clarified, what you have right now is ambiguous, and there is not a focused question (also, "user space" does not refer to what you think it refers to, you should replace that with some other term). – goldilocks Apr 4 at 13:56
  • @goldilocks Thanks for your welcome and your feedback. I tried to phrase clearer questions and remove complexity. Can you have a look again? – Lars Blumberg Apr 4 at 14:41
1

A clear and simple way to distinguish "system files" from "user data", the latter including custom installed software (vs. software installed from the distro repository via the package manager) is to consider most of the root filesystem to be the former, and the latter specific directories such as /home and /usr/local.

You can then use a second partition for the user files,1 allowing you to mount the primary partition (with the basic root fs) read-only, and symlink the user directories to a location in the (mounted) second parition. For example, if the second partition is /dev/mmcblk0p3, you can mount this at boot time via /etc/fstab:

/dev/mmblk0p3    /mnt/user ext4 defaults   0 2

You may want to use a UUID instead of the device node. It is probably best that you use ext4 or some other POSIX compatible fs type (ie., not vfat, etc) since parts of the root filesystem proper will be probably be located there.

You then create parallel directories on the second partition for the stuff you want to move to it, by moving them to it. In other words, make a directory /mnt/user/usr (while the second partition is mounted there!) and move /usr/local/ to /mnt/user/usr/local. You now have no /usr/local, which hopefully there's nothing critical there that now breaks (there isn't anything by default, so you would be aware of this), but you then create a symlink:

ln -s /mnt/user/usr/local /usr/local

You can do the same with /home or subdirectories thereof, and even subdirecories of /etc/ if you want specific stuff there writable, same with /var/log and so on.2

A complication is how much of your application software is installed from the distro, which as a rule of thumb should be as much of it as possible. Don't go build a mongoDB in /usr/local just to include it there. Use the distro packages and symlink the configuration, and/or configure the configuration to use runtime directories in /usr/local (conventionally there's also an etc there, it is empty in a base image).

This will take some experimenting/playtesting to see what stuff gripes when the root fs is mounted read-only. You probably also want to occasionally remount it read-write and do a update via the package manager. This will not tinker with stuff in /usr/local.


  1. I'm going to refer to the root fs partition, on Raspbian /dev/mmcblk0p2 as the "first partition" and the extra one as the second, even though the real first partition is the one default mounted on /boot (a method parallel to what I'm recommending for your user stuff). Note in your scenario you might as well leave that boot partition unmounted (it is not required to be).

  2. Note that you'll still have a writable tmpfs partition mounted on /tmp and/or /run or subdirs thereof, can't remember exactly which way Raspbian does it, but this should not interfere (and you want those writable!).

| improve this answer | |
  • This is a very good starting point for me. Thank you very much! – Lars Blumberg Apr 4 at 15:40
1

this little write-lock slider on the edge of every SD card

This is just a piece of plastic designed to push a switch in the card reader. This switch is not there in a Raspberry (more precisely, it's not connected electrically), so the lock slider has no effect.

You can still make an SD card practically write-protected by mounting the root FS read-only or completely write protected using sdtool.

The rest of your post should be applicable.

| improve this answer | |
  • There is no write-lock on a µSD card – Milliways Apr 4 at 11:24
  • Thanks for clarifying about the write lock! I though its position was read by the SD card's controller. – Lars Blumberg Apr 4 at 12:25
  • Can you give me feedback on the question whether it's generally worth it move the core OS on a write protected partition and all the rest onto another partition? – Lars Blumberg Apr 4 at 12:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.