On Fri, Jul 03, 2020 at 09:56:03AM -0400, Colin Walters wrote:
On Fri, Jul 3, 2020, at 9:32 AM, Zbigniew Jędrzejewski-Szmek wrote:
> On Fri, Jul 03, 2020 at 09:18:42AM -0400, Colin Walters wrote:
> > On Thu, Jul 2, 2020, at 11:53 AM, Zbigniew Jędrzejewski-Szmek wrote:
> > > It would be great if we could fairly reliably boot with a read-only
> > > root file system,
> > Eh, just mount a tmpfs for /var, and an overlayfs for /etc (backed by a
> I see that this thread is one massive communication failure on my part :(
> I wrote about "booting successfully with a read-only file system", but I
> see that I didn't say "... when the disk cannot be mounted rw because of
> file system errors". I thought it'd be clear from the context, but
> clearly not. Anyway, while I'm a big fan of coreos and read-only-on-purpose,
It's really unfortunate how much confusion there is on the "read only"
I know there's a fair amount of subtley here but I would hope at
a few more people in the Fedora community take the time to actually
dive in to the ostree model and understand things.
What I was pointing at is the Fedora CoreOS *LIVE* ISO, which is definitely
fully read only (or phased more usefully), does not support persistence
at all because physical ISOs don't - same as any other "Live" system
from Anaconda to all the others.
But that's a totally distinct thing from merely having /usr mounted ro
by default, while still supporting persistence for /etc and /var (i.e. the ostree model).
Right, so IIUC, if /var is read-only, ostree will have the same problems.
> I was writing about traditional systems in a
> i.e. about the system behaving gracefully when the disk is ***unexpectedly***
That is an important detail indeed =)
To be clear I agree with the effort! I think it's going to get really messy
to take it very far...and that's what I was getting at in arguing for
using overlayfs backed by tmpfs basically.
This would be another approach. E.g. we systemd could detect that root
cannot be remounted rw and insert the overlay. But I don't think this
as useful as it sounds, because it would create a fake impression that
the storage is rw. The patch for systemd to deal with ro /var/tmp for
PrivateTmp=yes is careful to set things up so that the service actually
gets a real EROFS error from the kernel when it writes to /var/tmp. It
also gets the real EROFS when it uses StateDirectory=foo and /var/foo is ro.
I think such real errors are good — they allow services which can do
a graceful fallback to do it, and services which should fail to fail.
So systemd-update-utmp.service may just write to utmp and warn about
wtmp being inaccessible, but postgresql.service should fail to start and
not accept any transactions that would then be lost upon reboot.
An overlay would also make it hard to go back to normal operation.
Maybe that's not so important since one can always reboot, but I think
the current property of being able to fix the fs and remount it rw is
quite nice. (Also, less risky then trying to reboot and realizing that
there are more errors which have caused the fs to be mounted ro again.)
Or maybe it should be more like a "recovery shell" - rather
to log in as your regular user and watch e.g. Firefox fail because it can't
write to /home and wonder just how much of the next years of your
life is going to involve patching software to make this work ;)
get enough to get the a desktop launched for a separate ephemeral
"live" user with sudo rights or so.
I'm not sure if this is such a remote goal. Programs *should* already
be prepared for reasonable read-only operation, because this can
already happen for a few different reasons: apart from the fs being
mounted read-only, the disk may be full or the user may exceed quota.
For an application the effect is similar. And those conditions can
happen at any point at runtime. Disks may also be remounted ro at
runtime if errors are detected. So any applications which falls flat
on its face if it cannot write to the disk is problematic already.