Also, wouldn't mounting /var, /home etc. RW on top of a RO-mounted / require that they were actually on different file systems? I don't think you can have a RW bind mount on a RO-mounted file system. (Haven't tried it, though.)
You could use two partition update scheme as ChromeOS. I am working on Linux distribution that have rootfs as a squashfs image and I want to have as painless updates as on ChromeOS.
> Also, wouldn't mounting /var, /home etc. RW on top of a RO-mounted / require that they were actually on different file systems? I don't think you can have a RW bind mount on a RO-mounted file system. (Haven't tried it, though.)
You can mount RW fs on RO fs. Distributions on Live-CDs do it all the time.
Right, but that's with OverlayFS and such, right? (I.e. not just straight bind mounts.)
Seems awfully complicated to solve what essentially should be a non-problem... (I'm aware OverlayFS has other uses, but in this instance it seems like overkill.)
EDIT: I'll just note, I did say "separate filesystem" (i.e. non-bind), but I guess it might have been easy to miss.
Most probably yes, but there are probably distributions using ro rootfs + specific mounts. I think that in many cases embedded devices would use such a scheme instead of OverlayFS.
EDIT: But you probably have to mount workdir and upperdir somewhere over this ro rootfs for OverlayFS to work.
> EDIT: I'll just note, I did say "separate filesystem" (i.e. non-bind), but I guess it might have been easy to miss.
I was hoping that you could read between the lines also :) I mentioned my WIP distribution. I have mounted:
- squashfs ro on /
- ext4 rw on /mnt/rw
- /mnt/rw/var bind on /var
- /mnt/rw/home bind on /home
Oooh, burn! :) I honestly didn't see any relevant mention of the WIP-distro you're talking about... but now that you mention it I had a look back. "I am working on Linux distribution" (etc.).
> I have mounted:[snip]
So... separate file systems.
Surely there's a lot of horrible software out there that Makes Assumptions.
It doesn't make much sense anymore but before the turn of the century a meg of doc files might cost you a buck per machine, which might add up to a lot of money given a lot of machines and a lot of software... And usually you don't need /usr/doc but when you do need it you REALLY need it and don't mind if its a little slower to access via NFS than on a local drive.
In the same old days, some brave people exported /usr/src. Oh and X window fonts too.
The Linux "community" have a bad habit of turning solutions for special scenarios into generic ones by hook or by crook.
Never mind that this was addressed to the busybox mailing list, a project aimed at reimplmenting the unix coreutils as a single static binary.
You also had people who would build a Linux box out of any old hardware they had left over. That's how I ended up with my first firewall.
http://lists.busybox.net/pipermail/busybox/2010-December/074...
Some fragment:
> When the operating system grew too big to fit on the first RK05 disk pack (their root filesystem) they let it leak into the second one, which is where all the user home directories lived (which is why the mount was called /usr). They replicated all the OS directories under there (/bin, /sbin, /lib, /tmp...) and wrote files to those new directories because their original disk was out of space. When they got a third disk, they mounted it on /home and relocated all the user directories to there so the OS could consume all the space on both disks and grow to THREE WHOLE MEGABYTES (ooooh!).
> Of course they made rules about "when the system first boots, it has to come up enough to be able to mount the second disk on /usr, so don't put things like the mount command /usr/bin or we'll have a chicken and egg problem bringing the system up." Fairly straightforward. Also fairly specific to v6 unix of 35 years ago.
It was discussed here few times:
https://news.ycombinator.com/item?id=3519952
https://news.ycombinator.com/item?id=9554134