offline updates may be followed by a reboot or a power-off. currently we always force reboot. it maybe useful to have a configuration option for this as users might prefer to apply updates on shutdown rather than boot up.
Kind of ties into bug #436924 as power-off requires that ksmserver redirects the UI option for power-off into an actual reboot combined with the setting the trigger word on packagekit to 'power-off' such that packagekit will poweroff after the update.
You're talking about in the Discover UI itself, right?
Ideally I think we would have two post-update options for the user:
- Reboot now
- Close the app and apply the updates on next shutdown/reboot, or not, as per Bug 436924.
(In reply to Nate Graham from comment #1)
> You're talking about in the Discover UI itself, right?
Yes, well, the KCM I suppose.
Depending on a specific user's way of using the system it may be more appropriate to set the offline update behavior to reboot (after update the system reboots) or power-off (after update the system powers off).
e.g. consider two office use cases:
User A has a system with SSD and tends to grab a cup of coffee after entering the office and turning on the PC. reboot is a reasonable system for this scenario because the user will be away from the machine for a while anyway. Meanwhile we start into the update target, apply the update, reboot. By the time the user is back we'd ideally be done and they can log in.
User B has a system with a HDD and doesn't drink coffee. power-off may be a more reasonable approach. They will power off the system when they leave the office anyway. We can simply set the offline trigger to power-off and instruct ksmserver/the greeter to perform a reboot instead of a power-off. The user leaves the office. The PC reboots into the update target, applies the update, powers off.
The two behaviours that PackageKit offers are:
- apply on startup then reboot with the new software
- apply it at shutdown where it reboots, applies the updates and shuts down
Now we're always going with the first one because the latter has weirdness when the user asks for reboot (it will shut down anyway, we'd need to hook onto the user's selection) and it asks the user for the bios/disk password when they're shutting down which feels very weird.
If we could get PackageKit to apply the updates in the used session before updating, that could be a useful alternative, as the next startup would already happen with the new kernel and all, but as is it feels very wonky.
Technically possible; needs talking to with upstream though: https://bugs.kde.org/show_bug.cgi?id=435971#c6
*** Bug 435971 has been marked as a duplicate of this bug. ***
*** Bug 438136 has been marked as a duplicate of this bug. ***
Workaround for those waiting on this feature:
With this script https://unix.stackexchange.com/a/621933 you can effectively "update and shutdown" but with the following caveat:
- The computer needs to restart to launch the offline updater, which means that it will boot grub/bootloader and everything related, as mentioned in another comment. If you need to manually choose an option when booting or you have bios/disk password, you will need to wait and enter them. Once the updater starts you can then leave your computer, it will properly turn off after finishing (instead of the currently hardcoded reboot).