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 tmpfs). > > > > 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 it's > > 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" topic... Yeah ;( > I know there's a fair amount of subtley here but I would hope at least > 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 read-only-by-accident scenario, > > i.e. about the system behaving gracefully when the disk is ***unexpectedly*** > > read-only. > > 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 than trying > 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. Zbyszek _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
