TL note: "keikaku" means "plan"
Why are you not using reproducible, read only rootfs with separately mounted data partitions?
this post was submitted on 26 Apr 2026
394 points (99.0% liked)
linuxmemes
31420 readers
1767 users here now
Hint: :q!
Sister communities:
Community rules (click to expand)
1. Follow the site-wide rules
- Instance-wide TOS: https://legal.lemmy.world/tos/
- Lemmy code of conduct: https://join-lemmy.org/docs/code_of_conduct.html
2. Be civil
- Understand the difference between a joke and an insult.
- Do not harrass or attack users for any reason. This includes using blanket terms, like "every user of thing".
- Don't get baited into back-and-forth insults. We are not animals.
- Leave remarks of "peasantry" to the PCMR community. If you dislike an OS/service/application, attack the thing you dislike, not the individuals who use it. Some people may not have a choice.
- Bigotry will not be tolerated.
3. Post Linux-related content
- Including Unix and BSD.
- Non-Linux content is acceptable as long as it makes a reference to Linux. For example, the poorly made mockery of
sudoin Windows. - No porn, no politics, no trolling or ragebaiting.
- Don't come looking for advice, this is not the right community.
4. No recent reposts
- Everybody uses Arch btw, can't quit Vim, <loves/tolerates/hates> systemd, and wants to interject for a moment. You can stop now.
5. π¬π§ Language/ΡΠ·ΡΠΊ/Sprache
- This is primarily an English-speaking community. π¬π§π¦πΊπΊπΈ
- Comments written in other languages are allowed.
- The substance of a post should be comprehensible for people who only speak English.
- Titles and post bodies written in other languages will be allowed, but only as long as the above rule is observed.
6. (NEW!) Regarding public figures
We all have our opinions, and certain public figures can be divisive. Keep in mind that this is a community for memes and light-hearted fun, not for airing grievances or leveling accusations. - Keep discussions polite and free of disparagement.
- We are never in possession of all of the facts. Defamatory comments will not be tolerated.
- Discussions that get too heated will be locked and offending comments removed. Β
Please report posts and comments that break these rules!
Important: never execute code or follow advice that you don't understand or can't verify, especially here. The word of the day is credibility. This is a meme community -- even the most helpful comments might just be shitposts that can damage your system. Be aware, be smart, don't remove France.
founded 2 years ago
MODERATORS
Because I don't even have a fucking idea what you just said lol
Though I would if I did
Are you OP though?
No I just like sticking myself in places I shouldn't be I guess
As we all should
Ive been using for almost 20 years and I don't even fully know what that means. How are data partitions bulk-mounted? Why would rootfs be ro or rw? Why would anyone care?
I haven't tried any yet, but my understanding is that recently there's been a trend of immutable Linux distros, where the root filesystem is immutable (read-only). Instead of directly changing config files, install apps, etc, you instead update some sort of config that says how to set up the system, and rerun a script that rebuilds the root.
System updates are atomic - either the whole update is completed, or the whole update is rolled back. If the system breaks, you can revert back to an old config file and restore it to exactly the same state as it was before.
It's still not very common - the majority of Linux systems aren't doing this.
Small note: at least in the case of the rpm-ostree distros (Silverblue, Bazzite, etc), /etc is one of the few directories outside of /var that's mounted RW.
You use reproducible, read only rootfs (essentially what a "live" distro is, to some extent) because it's 1, reproducible, so you're not stuck when the system dies for some weird reason 2, it's read only meaning nothing will modify it. This gives you a base that is stable, easily reproduced on any host, and isn't up to the whims of what packages you installed and such.
NixOS is a good candidate for this approach but you can literally turn any distro into such a base. Though it's preferred to use one dedicated to such endeavours.
Nobody said anything about bulk mounting anything though? I said mount your data partitions, because presumably you'd have multiple disks holding your data thus multiple partitions...
And the fact you've been working with Linux for 20+ years and have no fucking clue about why someone would want their rootfs RO or RW makes me seriously worried about the very statement that you worked with Linux for 20 years without an understanding of such a basic OS function.
I mean, it sounds both tempting and terrifying at the same time, but even assuming it's a good idea, how to reproduce my data, then? Not just the data per se, but all these volatile stuff in /var and $XDG_{CONFIG,DATA,STATE}_HOME as well. I like the idea of being able to (re)produce the entire system from a tiny "seed", but my system is still not the same without those parts, as it will behave slightly differently. So I still have to backup all my data, haven't I?
Also, using different partitions might be less fragile, but also much less convenient in terms of free space management, especially when you only have a single medium-sized SSD. So I just use a single rootfs (with subvolumes instead of partitions) for the system and all kind of data.
Just because the root filesystem is RO, it doesn't mean you're left in an entirely read-only system - writeable partitions (either mounted directly to violate paths, such as /home, /var, et cetera, or via some kind of overlay FS approach) do exist.
The key differentiation is that the core OS - not including custom installed packages in most cases, albeit e.g. NixOS takes the atomic OS to a different level - is immutable aside from OS updates, therefore should any kind of shit hit the proverbial fan, restoring to default OS settings is as quick as a reboot without the write-enabled partitions being mounted (or simply wiping those on boot).
Your data, however, is your responsibility. You mount it separately from the OS because it is truly separate. You're modularising your workflow here - the OS provides simply the base software interface to your hardware, and does so in a separate layer, while your own software and data are another segment you don't want to mix with the OS.
Protecting that data is up to you - proper backups, 3-2-1 approach, etc. - the idea here is to separate concerns of the OS root fs and your data.
But by separating the two, and making the OS atomic, you've essentially locked yourself into a situation where, should anything go wrong, you can restore your data and your OS separately, and not be exposed to the very thing OP meme'd about - the rootfs being corrupted within days of restoration, taking all your data with it.
But out of curiosity... What exactly it looks like?
the OS provides simply the base software interface to your hardware, and does so in a separate layer, while your own software and data are another segment you donβt want to mix with the OS.
My own software? Sounds like a bunch of containers on top of a base system.
"Your own software" here refers to anything beyond the base OS. Don't take Ubuntu as example, as it ships a shitton of extras to be a "useful" OS for beginners.
And no, we're not necessarily talking about containerisation (albeit that IS the next step in atomic OS approaches, making every installed software precisely reproducible and separate from the OS, even with things like Flatpak or Snap packages), just separating an easily reproducible, atomic OS, and any software you put on top.
The idea is that you treat every computer like you'd a public one - it's an insecure thin client you build on top.
So, using an immutable system, one could achieve... having one less backup target, apparently? Which is good, but seemingly not good enough for this particular case. Β―_(γ)_/Β― As far as I understand, it could certainly save the day if I mess up its settings, but in case of FS corruption it effectively just adds a different kind of procedure that I'll have to execute for its full restoration? And splitting my system and data to a different partitions... well, this approach in itself have nothing to do with immutability, isn't it?
Meanwhile, I managed to recreate exactly the same system with all my data and stuff, down to ctimes, mtimes, hardlinks and reflinks, as if nothing happened at all. Just saying!
Your data ideally resides on a completely separate disk, not just a different partition.
and sure, you managed to recreate your system... how much time did it need? Vs booting an atomic image from another drive and continuing where you left off.
Oh daddy, no need to be worried.
I can't tell if this is a lead into Atomic like Silverblue, or a rugpull into NixOS lmao
Neither actually lol.
Embedded Linux style squashFS + UBI forever
That's what roborock has employed for their Vacuums haha.
That's what most embedded Linux devices will run today.
Then you find out the back up doesn't work.
Happened to me last weekend. I made a backup because I was going to wipe out linux temporarily. I decided to backup with timeshift instead of my typical rsync -aAXH because having a GUI was nice.
Timeshift refused to restore the backup. It first complained about my subvolume layout, when I made it happy it restored all my files then promptly deleted them. Fortunately backup is just rsync so I restored with rsync.
Thank you for the TL
Meh... If /home is on a separated partition that's no biggie. Reinstalling Linux, even Arch, takes half an hour at most.
I just run rsync to copy all important data to a secondary drive. I reinstall and copy the other way and I'm done
Being with Arch for like seven years or so, itβs only recently Iβve learned one neat trick, upon reinstalling the system I have on various Windows tablets. I start sshd, do passwd and connect from my main machine. Then I just quickly format disks, and pacstrap system by copy-pasting commands from my blog, where I have the instructions for my devices. Itβs not the very techy way, I guess, but I was able to reinstall my system within like 10 minutes, most of which was booting off the USB drive with Arch ISO, and then downloading the packages and waiting for them to be installed, and rebuilding Initramfs.
I start sshd Yes do passwd and connect from my main machine Yes yes Then I just quickly format disks, and pacstrap system Yeeesssss by copy-pasting commands from my blog Bah. Why not put them in an Ansible playbook? Save yourself the extra blog traffic!
Thanks for the suggestion of what the next steps might be! Youβre right, I definitely want to go with Ansible next! Just did not have a chance to need any system for installing the system the way I need.
I knew thatβs not optimal, to have it in a blog, but I also want to make a point a blog could be a notepad (that one of paper!), and it would be as easy still!
You could even skip Ansible and go for a regular shell script. That would take next to no time to put together, since you'd just be copy-pasting your commands into a text file and marking it executable.
EDITOR'S NOTE: "planned" means "θ¨η»γγγ"
How?
Ever heard of btrfs? It likes to kill itself
How do you know it was btrfs, are you living in my walls?!
Well, jokes aside, it was a power outage. In my defense, I've survived dozens of power outages while using btrfs with almost no negative consequences!
I wonder if the stability pros of btrfs outweigh the instability cons of btrfs; yes, snapshots might be nice, but if the filesystem gets easily corrupted, what kind of trade is that then? Call me wrong, I have no substantial opinions or expertise on filesystem stability.
Snapshots are surprisingly useful and it's kinda awesome that it immediately detects corruption, but it's so fragile because it doesn't really tolerate any corruption at all and is not very good at repairing it either.
I feel like btrfs is kinda like zfs but without the integrity and backup benefits.