On 10/25/2016 11:46 AM, Zbigniew Jędrzejewski-Szmek wrote:
On Mon, Oct 24, 2016 at 11:47:55AM -0400, Stephen Gallagher wrote:
On 10/24/2016 09:21 AM, Michael Catanzaro wrote:
It sounds to me like your single-reboot work is worth continuing. We don't need to support strange edge cases.
My remaining concern is this statement from Lennart that I haven't had an opportunity to understand better:
"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."
I don't know what runtime state he's talking about here or whether the risk is greater than the advantages to avoiding an extra reboot.
For example, writing stuff to /proc/sys is not entirely idempotent: depending on the order, you might get slightly different results. And of course there's no way to reset the state to kernel defaults. If a sysctl.d file is removed, that setting will not be "undone" during an upgrade, until after a reboot. In 99% of cases this doesn't matter.
If we skip the reboot *before* the upgrade, that should be fine. Skipping the reboot *after* the upgrade is probably not worth the uncertainty.
So, good news! This is in fact already possible to do today, as I just tested. The following set of commands does exactly this:
``` pkcon refresh force pkcon update --only-download pkcon offline-trigger systemctl isolate system-update.target ```
This all runs in the current boot and will trigger a reboot immediately after the update completes. All of this should be easily possible to do for Workstation within GNOME Software if we agree that's easier on the end-user.
For Server, should we provide a couple scripts for simplicity? One for caching the pending updates and another to trigger the update-and-reboot?
There's also kexec: with recent kernels kexec does not work for me anymore (graphics crash). Nevertheless, kexec is something worth considering too: the state is reset quite thoroughly, and we avoid the potentially very slow POST.
2.0