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
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ desktop mailing list -- desktop@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to desktop-leave@xxxxxxxxxxxxxxxxxxxxxxx
