SUMMARY 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. https://github.com/hughsie/PackageKit/blob/master/docs/offline-updates.txt
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).
Harald Sitter's *User B* is definitely the desired mode around here. (i prefer to get updates as soon as possible - even if it causes some system instability - but for all other workers here, User B is perfect) Is there any PackageKit bug report on the issue Aleix Pol describes about applying updates on shutdown?
*** Bug 467145 has been marked as a duplicate of this bug. ***
Bug 452820 is possibly a duplicate of this (needs confirmation)
Richard Hughes, collaborator of PackageKit, said on Oct 2021 [1] >> Apply updates while shutting down instead of when turning on > Also not possible as you need a pristine boot to apply updates safely, rather than a system that has been futzed with. [1] https://github.com/PackageKit/PackageKit/issues/510#issuecomment-935732482
systemd v254 introduced a new reboot type: soft-reboot. [1] Do you think this could help here? [1] https://media.ccc.de/v/all-systems-go-2023-184-soft-reboot-atomically-replace-rootfs-and-reboot-userspace-without-kernel-restart
^ I meant in order not to need entering the luks encryption password on the reboot to apply the offline-update.
Maybe it's worth noting here that, according to user "Phil O", this may serve as a workaround: > sudo dnf update -y && poweroff || { sleep 30 ; poweroff ; } from: https://pointieststick.com/2023/11/24/this-week-in-kde-the-plasma-6-feature-freeze-approaches/#comment-38562
*** Bug 483896 has been marked as a duplicate of this bug. ***
I have opened a "dedicated" issue for this at: https://github.com/PackageKit/PackageKit/issues/770 Anyone aware if gnome has this working? (or if it's just for "regular" software - e.g.: just for non-critical software) this was brought up in the issue...
Relevant merge (it fixes this): https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/4596
Not quite; Bug 452820 is what's (half) implemented by that merge request. This one technically is something different.
(In reply to Nate Graham from comment #18) > Not quite; Bug 452820 is what's (half) implemented by that merge request. > This one technically is something different. Can you elaborate more on this? From Thomas' reply I got the impression that whenever we got updates, even not doing any action about it, if we went on into kicker to shutdown the computer, the logout greeter would show users the option to install the updates and shutdown! Is that not the case? Can you please clarify (for dummies)? Tks
As I understand it, bug 452820 is about being able to have the computer turn off after applying an offline update (even though technically there's a reboot involved). And that's now implemented for Plasma 6.2. This one is about being able to apply offline updates without any rebooting involved. Though probably for most people, the difference is inconsequential, and anyway, it's blocked by stuff needed from PackageKit. What do you think Harald and Aleix, is there any value in keeping this open anymore?