Hi,

this is partially an outgrowth of the discussion about btrfs as
default, but makes sense independently too...

It would be great if we could fairly reliably boot with a read-only
root file system, all the way to the graphical environment. Obviously,
such a machine will not be fully functional, but for users, debugging a
disk problem when they have the normal environment with windows,
tabbed terminals, graphical editors, and internet is vastly easier.

It also creates an image of robustness. Imagine that instead of being
rudely dropped to a terminal prompt, the user is instead able to log in
as usual and see a popup like
> Your home directory is read-only. Do this and that. See https://...

Is the goal to have *everything* working? No. Some services will and
should fail. If I have a database or anything else which only makes
sense with permanent storage, failing early and loudly is appropriate.
But services which need writable storage only tangentially or not at
all should be robust and not fail. Journald behaves in a fashion where
it stores logs to /run during early boot and them flushes them to /var/log
when that becomes available. If /var/log never become available, we
have a functional logs, with journalctl showing previous and current boot
just fine. The only caveat is that logs for current boot will be lost
upon reboot. Such graceful failure should be the norm.

systemd upstream recently gained a cool feature [1] which allows all
block devices to be toggled read-only as soon as they are detected by
udev. The primary use case is forensics and recovery, but it is also
great for testing read-only boot ;)

It turns out that systemd itself is not very good in this situation.
For example, any unit with PrivateTmp=yes would fail to start :(
But it turns out that this is fairly easy to solve. I opened two
PRs today [2, 3], and with that, systemd boots to a working
multi-user.target with no services bundled with systemd failing!

But I was not able to go all the way to a gnome session :(
I have been opening bugs as I went along: dnf [4], python [5], sssd [6],
gssproxy [7], gdm [8], btrfs [9], xfs[10]. The good new is that the
first is almost solved, the second is already solved, the next two
seem fairly easy, and the btrfs one is being handled. The one for gdm
unfortunately looks tougher :(

I hope we can all cooperate to make read-only boots nicely robust and
functional. Please play with this and report bugs. I'll try to solve any
that relate to systemd. The systemd version with udev.blockdev-read-only
is not released yet, but is available from koji ci builds [11].

[1] https://github.com/systemd/systemd/commit/95ac523030
[2] https://github.com/systemd/systemd/pull/16340
[3] https://github.com/systemd/systemd/pull/16344
[4] https://bugzilla.redhat.com/show_bug.cgi?id=1852365
[5] https://bugzilla.redhat.com/show_bug.cgi?id=1852941
[6] https://bugzilla.redhat.com/show_bug.cgi?id=1853261
[7] https://bugzilla.redhat.com/show_bug.cgi?id=1853293
[8] https://bugzilla.redhat.com/show_bug.cgi?id=1853409
[9] https://bugzilla.redhat.com/show_bug.cgi?id=1851608
[10] https://bugzilla.redhat.com/show_bug.cgi?id=1829792
[11] https://src.fedoraproject.org/rpms/systemd/pull-request/29

Zbyszek

_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-leave@lists.fedoraproject.org
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@lists.fedoraproject.org