Re: Improving the offline updates user experience

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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





[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux