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.

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.