Offline updates should be installed during the shutdown-process instead of during the boot. That way a) users don't have to wait when they need to use the system until updates are installed (which can take quite long on old systems), but instead, they would be installed calmly when the system isn't needed anyway. b) the system doesn't have to be booted twice: to install updates now, the system has to be rebooted once to install the updates and then again for some reason. Installing the updates during the shutdown-process would solve that c) additionally to b) users with encrypted systems profit, as they don't have to enter the password twice in order to boot the device. I think especially a) is a huge issue right now (at least for me and other users in forums as well), as I don't want be in a situation where I'm in a hurry and want to quickly start my system, but just find me in the installing updates screen and having to wait AND having to see my system reboot AGAIN afterwards. (I already was in that situation, can't recommend) That will also be the reason why I'll deactivate offline updates in Plasma 5.22, even though it may sacrifice system stability. If it was possible to apply updates during the shutdown process, I'd keep it activated. Is there a reason why it's not done yet? I mean, after installing the update during the boot process, the system has to be shut down and rebooted again ANYWAY, so stability wise doesn't seem to be a disadvantage. It could be added as option, so the user could choose whether he wants updates installed during boot or during shutdown, but I can't believe users would choose during boot, except they want to reboot their system to boot another one (which would also be one of two cases I can think of currently where the boot installation method would be beneficial, the other situation would be e. G. On a notebook with low battery) But to solve that, when updates are pending, two more shutdown options could be shown in the power menu like Windows does, with "install updates and shutdown" and "install updates and reboot" next to normal shutdown and reboot, which would then not install the updates (a install updates and reboot option should be added as users might want to reboot just to install the updates or because they have the time to wait and then it's useful to be able to directly install them) That way, the user can choose if he wants his updates to be installed with the next shutdown or maybe the next time. With the current model, this addition wouldn't really solve the issues stated above, as I don't always know if I might need the system instantly the next time I boot it, but when I turn my PC off or reboot it, I know if I need quickly afterwards or not. I think making this change, users would stop complaining about a "Windows-like" behavior and would really prefer this method as it brings system stability benefits. What are your thoughts? Have I missed something important here? PS: my mom would prefer this shutdown-installation-procedure as well, if that's worth something. ;)
In Neon with the new deafault "offline updates" Plasma/Discover does not allow you to install updates when shutting down the system. For example: Fedora/gnome you can install "offline updates" in two different ways: 1-. restart -> install -> restart -> boot finally. (like discover now) 2.- Go turn off -> restart -> install -> shutdown finally. I add an screenshot with the option to install updates before confirm the turn off on Fedora. EXPECTED RESULT I want install offline updates while turn off my computer becasue It has less impact in my work. I need a fast start, but I don't care an slow shutdown.
Created attachment 138008 [details] Fedora/gnome turn off dialog with option to install "offline updates"
Yeah, this would be more user-friendly for sure.
(In reply to francisco_t from comment #1) > In Neon with the new deafault "offline updates" Plasma/Discover does not > allow you to install updates when shutting down the system. > > For example: Fedora/gnome you can install "offline updates" in two different > ways: > 1-. restart -> install -> restart -> boot finally. (like discover now) > 2.- Go turn off -> restart -> install -> shutdown finally. > > I add an screenshot with the option to install updates before confirm the > turn off on Fedora. > > > EXPECTED RESULT > I want install offline updates while turn off my computer becasue It has > less impact in my work. I need a fast start, but I don't care an slow > shutdown. Yeah OK, that would be better, but won't solve the main issue I have with the current implementation, as I'd then have to enter the password when it reboots, as my system is encrypted (at least when it's a normal reboot to "install updates mode" :D) It then would be the same update behavior as Windows (which is also encrypted) and annoying because of the same reason. I want to shutdown my system, but instead it waits infinitely for me to enter the password to install the updates. Wouldn't it be possible to install the updates without the need of a reboot or the ability to cache the system password somehow? (even though I wouldn't know how that might be implemented securely).
*** This bug has been marked as a duplicate of bug 436924 ***
Huge caveat: this is entirely not fit for production. Technically one could do a poweroff update without any reboot. If packagekit-offline-update.service grew an additional rule Requires=dbus.service (in addition to dbus.target, which will on its own not prevent ordering problems) one can simply isolate into the update target instead of doing a poweroff. - pkcon update -d - sudo qdbus --system org.freedesktop.PackageKit /org/freedesktop/PackageKit org.freedesktop.PackageKit.Offline.Trigger power-off - sudo systemctl daemon-reload - sudo systemctl isolate system-update.target at this point the system should shut down all units that aren't part of the dependency tree of system-update.target and fire up packagekit-offline-update.service (which is part of that target) and packagekit-offline-update.service will then issue the final system power-off once its done. This is however also a fair amount less reliable because isolation doesn't necessarily ensure that everything else has been killed by the time the update starts. Working under the assumption that the update cannot make systemd or dbus fall over that shouldn't really matter though. Anyway, mostly posting this for academic purposes.
(In reply to Harald Sitter from comment #6) > Huge caveat: this is entirely not fit for production. > > Technically one could do a poweroff update without any reboot. If > packagekit-offline-update.service grew an additional rule > Requires=dbus.service (in addition to dbus.target, which will on its own not > prevent ordering problems) one can simply isolate into the update target > instead of doing a poweroff. > > - pkcon update -d > - sudo qdbus --system org.freedesktop.PackageKit /org/freedesktop/PackageKit > org.freedesktop.PackageKit.Offline.Trigger power-off > - sudo systemctl daemon-reload > - sudo systemctl isolate system-update.target > > at this point the system should shut down all units that aren't part of the > dependency tree of system-update.target and fire up > packagekit-offline-update.service (which is part of that target) and > packagekit-offline-update.service will then issue the final system power-off > once its done. > This is however also a fair amount less reliable because isolation doesn't > necessarily ensure that everything else has been killed by the time the > update starts. Working under the assumption that the update cannot make > systemd or dbus fall over that shouldn't really matter though. > > Anyway, mostly posting this for academic purposes. Oh wow, even though it's mostly academic, I like the approach here. But since this bug has been marked as a duplicate of a newer report of today, this should maybe be written under the other one,so the discussion is all in one place, though, most/all of the discussion happened here already
It's something that'd need taking to the respective upstream projects really. Neither systemd nor packagekit actively support this use case, which is why the hack to bring dbus.service into the requirement tree is necessary. We are bound by the rules set forth elsewhere. If the options are reboot and power-off and power-off means reboot-then-power-off then that is what we, discover/plasma, have to work with for now.
*** This bug has been marked as a duplicate of bug 436928 ***