Mailinglist Archive: opensuse-features (365 mails)

< Previous Next >
[openFATE 306966] [Beta2] No Shutdown/Suspend During Package Update
  • From: fate_noreply@xxxxxxx
  • Date: Wed, 3 Mar 2010 08:24:51 +0100 (CET)
  • Message-id: <feature-306966-34@xxxxxxxxxxxxxx>
Feature changed by: Jiri Srain (jsrain)
Feature #306966, revision 34
Title: [Beta2] No Shutdown/Suspend During Package Update

openSUSE-11.3: Evaluation
Requester: Mandatory
+ Projectmanager: Mandatory

Requested by: Andreas Jaeger (a_jaeger)
Partner organization:

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): If this feature is not implemented, people can get broken
systems - which might result in support calls.

#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

#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
* 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/ 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 ( ) 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
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:

< Previous Next >
This Thread
  • No further messages