Feature changed by: Scott Reeves (sreeves1) Feature #306966, revision 33 Title: [Beta2] No Shutdown/Suspend During Package Update openSUSE-11.3: Evaluation Priority Requester: Mandatory Requested by: Andreas Jaeger (a_jaeger) Partner organization: openSUSE.org Description: During a package update, it should not be possible to shutdown or suspend the system. Such requests should be delayed until the package update is finished. You do not want to bring the system in an inconsistent state. I consider this a desktop feature, so if somebody runs halt/shutdown on the console, this might not need to work - but if the GNOME/KDE shutdown/suspend options are used, it should finish the update first. Note: Windows does not allow shutdown during an update. What happened and let me to report this as feature: A user installed a kernel update and thought the update was finished. But only one out of the three kernel packages was updated and therefore after a reboot, the system did not came up completely. Business case (Partner benefit): openSUSE.org: If this feature is not implemented, people can get broken systems - which might result in support calls. Discussion: #1: Matthias Nagorni (mnagorni) (2009-08-24 17:42:52) Seems obvious since system integrity should be a primary goal. #3: Ralph Ulrich (ulenrich) (2009-08-25 15:14:58) make critical time as short as possible: 1. firstly download all packages (not critical) 2. after finished download start installing (critical phase) Don't make download and install in parallel an option! #21: Robert Davies (robopensuse) (2009-12-18 11:18:40) (reply to #3) No! The critical time would be minimised, if only a subset of packages with impact for resume were treated specially. The real cause of the system not coming up properly, was "only one out of the three kernel packages" being updated, so inflicting pre-download of potentially nearly a GB of data is not a good solution. Use of a fallback kernel ie the traditional sysdmin practice of not removing the working running kernel until the newer one proves good. Critical system packages like kernel, glibc ought to be updated together as a transaction. The unsafe kernel update method was justified on grounds of avoiding extra disk space usage, so the change to download first of potentially much more data seems inconsistent. #22: Robert Davies (robopensuse) (2009-12-18 11:29:48) (reply to #3) The request to inhibit Suspend during update does not require minimising cirtical sections. Increasing availability of Suspend, during system update actually goes against the requester's wish "should be delayed until the package update is finished", after all the system is busy and doing important work. (point seperate to previous reply as it's logically distincit) #5: Duncan Mac-Vicar (dmacvicar) (2009-09-23 11:05:08) This feature has two parts. First, PackageKit already supports inhibiting the suspend and probably we need only to review it. First part is: * Gnome applet does a session inhibit to gnome-power-manager to prevent suspend. * Daemon inhibit code is in src/pk-inhibit.c, it talks to HAL, according to Richard this does not do anything in modern devicekit-power systems. In theory, in the gnome/HAL world this should work, and therefore I wonder why it did not work when PM evaluated it. * The above two parts needs to be reviewed by Gnome and Mobile teams. (adding engmgrs) * KDE applet needs to do an inhibit too. We can do that (if it is not there), however this is the part that we lack more resources too. I could promise the KDE part for 11.3, but not for SP1. We will try to get it for SP1 if time allows. Second part is to make it safer, for which we need to switch PackageKit libzypp backend to use the default policy of download first, and then install for all update operations. That can also be done in my team and should be trivial. #20: Robert Davies (robopensuse) (2009-12-18 10:57:26) (reply to #5) Does this address automatic updates done in background, that the GUI user may not be aware of? Rather than downloading every single update first, the concept of critical package sets ought to be used, and the inhibition done at a lower level, which would then be implemented once for all desktops and CLI rather than changes to applets. Most application updates are not needed to resume system from RAM or disk; so why force all updates including KDE, OOo & Mozilla to be done as slow as possible risking failure due to disk full, as if they were kernel, glibc/ld.so and early system boot code? Installing oS-11.1 a year after release and running updates results in a huge amount of patches and downloads, which if done by download first requires diskspace on every client system! The "download first" is likely to incovenience very many users, and make a poor impression of update on new installers, leading to reluctance (like most Windows users) to update. Fate #120340 : Run download and install in parallel ( https://features.opensuse.org/120340 ) is the most popular item for a good reason! Putting a monster serialisation into every update, when most likely simply fixing the long running kernel update to be done right, like it always should have been done, as one logical transaction would solve 99% of the support problem. #6: Duncan Mac-Vicar (dmacvicar) (2009-09-23 11:09:44) If all involved stakeholders agree with the above, this can be set to "ready". My team can commit to fix the ZYpp part (and the KDE one for SP1, or 11.3). #8: Stefan Behlert (sbehlert) (2009-09-29 13:45:42) (reply to #6) Uwe, could you comment, too? #10: Holger Macht (hmacht) (2009-10-05 16:18:48) First some questions: * What is meant by gnome-applet? The PolicyKit gnome applet? * What is the daemon inhibit code in src/pk-inhibit.c? At least the PolicyKit in SLE11 doesn't have this The suspend part at the desktop level should be quite less work, if not even working already. Do we really have a method to inhibit a shutdown/restart, which is also part of this feature? I'm also not sure if it is a good idea to prevent the user from shutting down if he explicitly asks to (with pressing the shutdown button). For doing this right, the action would need to be buffered and performed as soon as the update is finished. This sounds like quite more work. #23: Robert Davies (robopensuse) (2009-12-18 13:49:13) (reply to #10) The point about physical shutdown and sudden power withdrawal is a very good one! Resorting to update on shutdown/reboot like Windows would not generally be necessary however. Multi-version packages solve issue for kernel. Convenience feature like removing unwanted kernels (say not tagged as Fallback in GRUB configuration) can follow later. Critical system packages only could be batched for update (pre- downloaded) when going down or coming up (ideally special purposed single-user run level to avoid slow BIOS), so it gracefully shuts down daemons, updates, and then cleanly restarts afterwards. When rpm(8) supports transactions better then consistency issues can be reduced further. Interrupted updates could be handled by GUI notification, suggesting resumption via applet or CLI if that fails. #11: Scott Reeves (sreeves1) (2009-10-08 07:39:52) The gnome-applet is the gnome-packagekit updater applet (gpk-update- icon) and the pk-inhibit.c code is part of PackageKit. The basic infrastructure is available for the gnome updater applet to support this just some of the parts still need to be hooked up and some additional support added in the PackageKit zypp backend (it currently does not issue the inhibit calls because it depends on cancel support). This can be done for the gnome updater for SP1 #19: Stefan Behlert (sbehlert) (2009-12-17 14:34:59) Scott, any update? Is beta 2 doable? + #24: Scott Reeves (sreeves1) (2009-12-19 01:07:40) + Submitted for Beta2. Concerns and sugestions about critical package + sets and parallel installation (comments 20-23) would need to be + addressed separately by PM and libzypp policy team -- openSUSE Feature: https://features.opensuse.org/306966