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@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
