On Fri, 12.09.14 10:46, Stephen Gallagher (sgallagh@xxxxxxxxxx) wrote: > It is very common for users to have systems with encrypted root > partitions (or even just /var and /etc). This may be due to a > personal Nitpicking: we currently do not support split-off /etc on Fedora/Dracut. /var may be split out though. > We could significantly improve this situation by allowing the system > to drop directly from the interactive system into the updater > environment without doing a full reboot or relaunching the kernel. > > Lennart, would it be possible to set up a special systemd target for > performing updates that would essentially stop all processes except > for systemd and then apply the updates? Well, the entire logic we have in place for offline updates is to ensure that they are applied in a well-defined very clean, minimal environment. Actually, that's not just the logic that is in place, that's the whole reason for having them at all! I mean, if it is OK to allow leaking runtime state into the upgrade process we could just run the updates in parallel to normal runtime, how we always did things. Or in even otherwords: offline updates are supposed to make update strictly reliable, and for that I figure a full reset and fresh boot, with everything initialized to the boot-up defaults is the closest if not only option. That all said, we have been discussing supporting a new reboot-mode in systemd, which would essentially shut down userspace, until only PID 1 remains, and then immediately start userspace again on the same kernel. This would be pretty close to what you are asking for here... However, so far we have quite some concerns about adding this, precisely for the reason that it pretends to be a reset of everything to the boot-up defaults, but actually isn't, as a ton of runtime state is retained in /sys and /proc/sys and other runtime objects. > [1] I'm told that this might not be necessary; that systemd can > re-exec itself to pick up its own updates. That would reduce the scope > presumably to "only the kernel" forcing reboots. Well, you cannot really do this atomically. Offline updates are about reliability. But you cannot restart userspace reliably during runtime. Think about this: daemons talk to each other, supporting a variety of APIs and API versions. If we want to do an update, then we'd have to restart all daemons at the same instant to ensure that no daemon starts talking with another daemon at the wrong time where it might be confused by either a too old or too new daemon. However, restarten them all at once is not possible. Moreover, some daemons cannot be restarted at all (for example dbus-daemon; and journald is difficult too, as it will lose connections to all other daemon's stdout/stderr if you do, even though it other works fine). Hence: I'd really recommend leaving offline updates as is. I see the problem though and acknowledge the fact that entering the passwords multiple times is annoying. Interestingly hw hdd encryption is nicer there as the keys are not flushed out on resets... Maybe that's actually a strategy to adopt here: upload the encryption keys into the firmware as efi vars, and then pull them out on next boots or so (assuming that efi vars can be marked to survive soft reboots without making them fully persistent...) I understand this is all unsatisfying. Maybe fixing related problems might improve the situation a bit though. For example, I find it quite annoying if we always ask for both a hdd passphrase and a user passphrase at boot. It has been a long-time todo list item for systemd to add the hdd passphrases (with strict expiry) to the kernel keyring and then optionally pull them out there for gdm's autologin mode, so that they can be used for decrypting the gnome keyring and such. However, so far we haven't worked on that yet... Lennart -- Lennart Poettering, Red Hat -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
