On Thu, Jul 2, 2020 at 11:54 AM Zbigniew Jędrzejewski-Szmek < zbys...@in.waw.pl> wrote:
> 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 > +about a billion or so! Particularly fun if you forget to set the root password after install and can't even get to the prompt. langdon > _______________________________________________ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@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 >
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
