Talk:Features/OfflineSystemUpdates

• package maintainers who try to test their updated package works now should do that twice, in the regular and in the offline mode. --Akozumpl 14:08, 15 June 2012 (UTC)
  • No, why ? The updated package is installed in just the same way. The only difference with offline mode is that there is a reboot before and after the installation of the new packages. --mclasen 00:19, 16 June 2012 (UTC)

• can we get examples of packages that don't update through the regular process and reasons why not? --Akozumpl 14:08, 15 June 2012 (UTC)

• how do people update problematic packages from terminal/non-gnome envs? --Akozumpl 14:08, 15 June 2012 (UTC)
  • Not sure I understand these questions. We generally don't ship packages that 'don't update'. The gist of this feature is that by doing the update in the middle of your running system, you end up in a subtly inconsistent state. E.g. if you update a library, all the running applications will still use the old version of the library, while newly started applications will use the new one. Your system will limp along most of the time. Except for when it breaks in mysterious and hard-to-understand ways. The goal of this feature is to eliminate the risk of such breakages. --mclasen 00:19, 16 June 2012 (UTC)
    • Even if the newly started application uses the new library while the old instance still uses the one loaded in memory, why is this expected to create an issue? Can we have a specific example here? --kaustav 15:10, 22 June 2012 (UTC)
    • Even if I assume the above, can't the affected application simply display a prompt asking the user to save all work and re-start the application? That's the way many applications work today. If this can't be done through the application, even the Package Manager can pop up a box (or yum can pause at the end of all the transactions) listing the affected applications and provide a simple option to restart all those applications at a button press (if the user doesn't want to continue working at his own risk), while allowing the user to save all the data they want to? Rebooting the whole system is totally an overkill! --kaustav 15:10, 22 June 2012 (UTC)
  • You can either use "pkcon update foo --only-download" or use yum to download the packages to a cache and then do /usr/libexec/pk-trigger/offline-update. It's also expected than Daniel will add support for this to Apper, for KDE support. --rhughes 07:15, 16 June 2012 (UTC)

• is there a chance packaging will become more sloppy after this feature is live and we will se increase in a number of packages requiring the offline mode for non-legit reasons? --Akozumpl 14:08, 15 June 2012 (UTC)
  • Not a serious question, is it ? In case it is: my answer would be 'no'. --mclasen 00:19, 16 June 2012 (UTC)

• "Note that this feature does not prevent you from using yum to install updates whenever you want to. We also differentiate updates of 'OS components' (which we want to do in this offline fashion) from application updates and installations, which should still be possible from the UI without restarting the system. " I thought Firefox was a driver for this change: is that counted that as an OS component or an application? --Akozumpl 14:08, 15 June 2012 (UTC)
  • I've now put some information about the heuristics for 'OS component' vs application in the feature page. --mclasen 00:19, 16 June 2012 (UTC)
  • According to mclasen's info Firefox is an application. --Cwickert 11:01, 18 June 2012 (UTC)
  • Will it be possible to install these updates from the UI through a configuration setting or some other means without restarting the system? --Rharrison 17:02, 22 June 2012 (UTC)

---

• shouldn't there exist an API to even allow rpm/yum to schedule an offline update? --Jnovy 14:38, 15 June 2012 (UTC)
• if yes, shouldn't there be a lower level mechanism to do that? Not only on PackageKit level? --Jnovy 14:38, 15 June 2012 (UTC)
  • The API is at the systemd level, can't get much lower than that. If rpm/yum want to grow an 'offline update' mode, they can. --mclasen 00:19, 16 June 2012 (UTC)
  • There's a simple API for this, see https://gitorious.org/packagekit/packagekit/blobs/master/contrib/systemd-updates/README.txt for details. I think it's logically on level higher than yum, tho. --rhughes 07:15, 16 June 2012 (UTC)

• use case: What if future RPM will check if a library to be updated doesn't conflict with library which is currently used by a running binary? If so, RPM could postpone update to Offline updates. --Jnovy 14:38, 15 June 2012 (UTC)
  • PackageKit is doing that today. See CheckSharedLibrariesInUse and UpdateCheckProcesses in /etc/PackageKit/PackageKit.conf --mclasen 00:19, 16 June 2012 (UTC)
  • I don't think that's in the remit of rpm. rpm certainly doesn't want to be doing this process parsing stuff. --rhughes 07:15, 16 June 2012 (UTC)

---

• Are we actually doing 2 full reboots (incl. BIOS and grub) or will systemd only change to the special update target? ----Cwickert 18:06, 15 June 2012 (UTC)
  • 2 reboots. Lennart was in favour of the extra separation we gain by installing updates in a clean, minimal, freshly booted system. And we want to reboot after installing the updates to ensure that all the newly updates components are actually used. --mclasen 00:19, 16 June 2012 (UTC)
  • The "first" reboot is super quick, and we boot straight into system-update.target. Getting to system-update target and back to rebooting takes me a fraction of a second. Posting the BIOS is the longest bit, but that only takes me a couple of seconds. --rhughes 07:15, 16 June 2012 (UTC)

• Why are updates installed during boot and not while shutting down? An "Install updates and shut down" option makes more sense than reboot because the system is idle anyway (the user is not waiting for it to become available again). ----Cwickert 18:06, 15 June 2012 (UTC)
  • I discussed this on the systemd mailing list, here's the archive: http://lists.freedesktop.org/archives/systemd-devel/2011.../003190.html , TLDR, basically Lennart wants a known-good environment to do the updates in, rather than having dozens of random processes running. --rhughes 07:15, 16 June 2012 (UTC)
    • If one switched to the update target, there shouldn't be dozens of random processes any longer, all services and units are stopped. --Cwickert 11:01, 18 June 2012 (UTC)
      • But we don't actually know if the system state is sane, for instance running tainted from a kernel module or selinux labelling messed up. Using a known-good environment (ideally partition, but we can't do that) makes real sense in my opinion. --rhughes 14:50, 18 June 2012 (UTC)

• How does the differentiation between 'OS components' and applications work? ----Cwickert 18:06, 15 June 2012 (UTC)
  • I've now put some information about the heuristics for 'OS component' vs application in the feature page. --mclasen 00:19, 16 June 2012 (UTC)
    • Thanks, but I think the logic "Whatever doesn't show up in the menu is considered an OS component" is flawed and will lead to a high number of unnecessary reboots. --Cwickert 11:01, 18 June 2012 (UTC)
      • Better ideas welcome. For a different future feature we're planning to add more hints to .desktop files in GNOME 3.6 for the app installer, although that won't help the cases where we need to identify an "application" without a desktop file (which I think isn't something that's super-interesting) --rhughes 14:50, 18 June 2012 (UTC)
      • IMHO, it is a really bad heuristic. Doing an offline update for "OS Components" like aria2c and vim is overkill. Also, "kernel" is an OS component but it really doesn't need to be installed in an isolated environment! It can be installed SAFELY while I'm using my system. Instead, Firefox MUST be restarted after an update (but it should not require a reboot also: just prompt me to restart it after installing an update. IMHO, "offline update" should be restricted to a very few hard-coded packages which really need it (maybe systemd itself). Most others should be installed when I'm using my system and do one of the following: 1. For most of "system daemons", they can just restart themselves. 2. Applications might need to be restarted, or they might go with the next option 3. Some others might suggest log-out (e.g. some Gnome components) 4. It might be installed and suggest a reboot (e.g. kernel). -- Hedayat 13:17, 24 June 2012 (UTC)

• We already have updates that suggest a reboot or log out, but we have a lot of false positives that don't actually require this. How to avoid this in the future? ----Cwickert 18:06, 15 June 2012 (UTC)
  • We want to do the majority of updates offline, rather than in the running session. It also makes sense from a snapshotting point of view to have as little other stuff running as possible. --rhughes 07:15, 16 June 2012 (UTC)

• What about reboot vs. log out? We only have reboot available in bodhi. ----Cwickert 18:06, 15 June 2012 (UTC)
  • At the moment, the new updater application doesn't use this data from bodhi at all as most updates are going to be done offline. --rhughes 07:15, 16 June 2012 (UTC)

• The checkbox in bodhi reads "Suggest Reboot". Will reboot/log out still be suggested or become mandatory? (Read: Will one still be able to update 'OS components' with gkp-update-viewer or only on reboot? ----Cwickert 18:06, 15 June 2012 (UTC)

• How does the system determine if an update requires a reboot or not? How does a package maintainer provide this information? ----Cwickert 18:06, 15 June 2012 (UTC)
  • I feel this was answered in the meantime: The package maintainer has no way to trigger a reboot, PackageKit decides it. --Cwickert 11:01, 18 June 2012 (UTC)

• What infrastructure is needed on the server side to provide this information? How is it transported? ----Cwickert 18:06, 15 June 2012 (UTC)
  • This feature is not about fine-grained control of when to reboot / logout like these questions seem to assume. We want to broadly say 'OS updates are done offline'. If you know what you are doing and think you don't need to reboot, you can (and most likely already are) just use the commandline. --mclasen 00:19, 16 June 2012 (UTC)

• What happens if one installs updates that are already downloaded and scheduled for installation through yum? Will the menu item disappear and the offline update cache be cleaned? ----Cwickert 18:06, 15 June 2012 (UTC)
  • I can't say in detail how the cleaning of the downloaded packages will be organized, but the offline update cache is only put in place when you actually trigger it by hitting 'Restart and install updates' in the menu. --mclasen 00:19, 16 June 2012 (UTC)
  • Yes, a PackageKit plugin clears the prepared-update flag if the user does any update operation manually. It's only reset when the next idle GetUpdates is done, which I think is going to be once a day. --rhughes 07:15, 16 June 2012 (UTC)

• Obviously only PackageKit will be able to understand the reboot requests. Wouldn't it be better to do this on a yum level, say with a plugin, to avoid situations like the one I described? ----Cwickert 18:06, 15 June 2012 (UTC)
  • See my answer above - there are no 'reboot requests' per se. PackageKit just uses heuristics to decide how to treat available updates. --mclasen 00:19, 16 June 2012 (UTC)
  • YUM could implement the OfflineOSUpdates thing if it wants, but it was done in PK so to work for all the distros, not just Fedora. --rhughes 07:15, 16 June 2012 (UTC)

• Will downloading updates in the background without user interaction become the default? Will it become configurable or not? Is there a way to avoid unnecessary traffic? Say you are on a train connected through a tethered GPRS installation. In this case you don't want to waste your precious bandwidth for updates, but PackageKit has no way to figure out you are connected only through GPRS. ----Cwickert 18:06, 15 June 2012 (UTC)
  • Yes, it does have a way. And in fact, gpk-application has had a 'Check for updates when on mobile broadband' option for a long time. --mclasen 00:19, 16 June 2012 (UTC)
    • Please read my questions more carefully. I said that I tether to my mobile, so NetworkManager only knows about Wifi but not that I'm online over GPRS only. So is there is a way to prevent unnecessary traffic or to configure the automatic downloads in the background? --Cwickert 11:01, 18 June 2012 (UTC)
      • NetworkManager has no idea that you're using a tethered connection (i.e. GPRS-via-USB), to the kernel it just looks like a ethernet USB dongle was inserted. If NetworkManager was patched to somehow (?) know that the ethernet connection is a slow/expensive data link then PK would DTRT. Note: PK is going to be idle downloading updates for you in current Fedora releases, and other stuff like evolution isn't going to know any better either. If you want this, NetworkManager patches are required. --rhughes 14:50, 18 June 2012 (UTC)
        • I've filed recently upstream bug to NetworkManager so that apps know when they should save bandwidth. --Djasa (talk) 21:46, 7 December 2012 (UTC)

• What happens if the system is shutdown while downloading updates in the background? Is there a mechanism to detect broken downloads? ----Cwickert 18:06, 15 June 2012 (UTC)
  • Again, not sure if this is a serious question - worst case, the same thing will happen that happens today when you shutdown while yum is downloading updates. --mclasen 00:19, 16 June 2012 (UTC)
    • Both yum and gpk-update-viewer need to be started by the user, so he is aware there is a transaction going on. This is not true for automatic downloads in the background. So is there a mechanism to detect broken downloads before starting the offline update or not? --Cwickert 11:01, 18 June 2012 (UTC)
      • Well, the file is only written at the end of the download transaction (not at the start), but if somehow a download is broken, it won't be GPG signed, and the update will not complete. PK replies on yum checking that kind of stuff. --rhughes 14:50, 18 June 2012 (UTC)

• What happens with broken updates (testcase 3)? will the complete update fail or will the system behave like --skip-broken? ----Cwickert 18:06, 15 June 2012 (UTC)
  • I don't know this for a fact, but I would assume that we don't pass 'break my system' options like --skip-broken when the goal of the feature is to reduce the potential for updates-induced breakage... --mclasen 00:15, 16 June 2012 (UTC)
  • Updates will fail to be applied, and the prepared-update file will be removed, with an error log written than can be read from the session. --rhughes 07:15, 16 June 2012 (UTC)

---

• From https://live.gnome.org/GnomeOS/Design/Whiteboards/SoftwareUpdates : "If the app is running it would ask if it is ok to restart the app for you after it installs the update." How is that supposed to work? --Mitr 18:13, 15 June 2012 (UTC)
  • This isn't part of this feature -- it would require more work to other parts of our stack first. --rhughes 07:15, 16 June 2012 (UTC)

• If the update fails and btrfs snapshot is reverted, how will logs ( http://freedesktop.org/wiki/Software/systemd/SystemUpdates mentions journal) be preserved?
• Related to that, what changes _not_ caused by the update attempt can happen during the bootup and will be incorrectly reverted? (e.g. AD machine account passwords) - in general, the reverts do sound risky. The first reboot makes it a little better, but still worrying. --Mitr 18:13, 15 June 2012 (UTC)
  • The btrfs snapshot isn't implemented in this feature, so we've not looked at all the details yet. We can't realistically work on the snapshotting until Fedora uses btrfs for / by default. --rhughes 07:15, 16 June 2012 (UTC)

• Bikeshedding - Why isn't the /system-update file in /etc? --Mitr 18:13, 15 June 2012 (UTC)
  • Lennart wanted it in /, just like the other flags like the selinux relabel flag. IIRC, putting it in root makes the generator easier to write as we're sure the directory is mounted. --rhughes 07:15, 16 June 2012 (UTC)

---

• Wouldn't it make more sense to check the transaction before rebooting, so the user won't need to reboot twice just to be informed the update failed? --Elad 16:09, 19 June 2012 (UTC)

• What happens if PackageKit downloaded updates in the background, and then I shut down my computer without clicking "reboot and install updates"? Will it install the updates on the next reboot anyway? will there be an option to skip the updates if I want my computer really urgently, that will not reboot the machine again but rather just stop the process and tell systemd to load the default target? --Elad 16:09, 19 June 2012 (UTC)
  • As for the first part of your question: This cannot happen. The menu entry is only shown when all updates are downloaed successfully. As for the second part: Dunno, ask the feature owners.
    • check the transaction = preform transaction test, this happens after the download, and not part in veryifing the downloaded files in the current package manangement system we use, it is when we check GPG signatures, and conflicting files. according to previous threads in this talk page, this will not be part of the pre-reboot check. I wonder why. Elad 17:45, 19 June 2012 (UTC)
  • When we download the updates, we don't just download packages. We depsolve, download and then check the packages, and then write a list of packages that are ready to go. This can fail if the repos are churning, but there's not a lot we can do about undepsolvable repos other than --skip-broken. --Rhughes 07:52, 18 July 2012 (UTC)
    • What about things like file conflict, which yum for example won't be aware of until it finished downloading all packages and then start running the RPM transaction test? Will it be possible to run the transaction test before rebooting? Elad 12:28, 18 July 2012 (UTC)

---

• How will this be disabled system wide? In F16, disabling auto updating required creating various files under /etc/dconf to change the default value for the org.gnome.settings-daemon.plugins.updates key, will this be same for F18? ac000 11:10, 25 June 2012 (UTC)
  • That's a good question. I'll add a key in /etc/PackageKit.conf to disable writing the prepared-updates file. --Rhughes 07:52, 18 July 2012 (UTC)

---

• Is there a list of bugs this feature resolves or at least list of packages that are known to break under the conditions this feature is aiming to prevent? I know that you intuitively believe that this feature *will* solve some issues, but it cannot be assessed by others nor correctly tested. What if this feature did not actually help? --Mordae 06:41, 16 July 2012 (UTC)
  • Generally speaking features don't fix bugs but enhance the system. Please have a look at the feature definition or the F17 feature list and ask yourself what bugs they fixed. --Cwickert 07:51, 16 July 2012 (UTC)

• tl;dr Link to a concrete bug that will be resolved by this, please. --Mordae 06:41, 16 July 2012 (UTC)
  • Again, this is based on the false assumption that features fix bugs. We have plenty of bugs that are caused by incomplete updates (usually indicated by packages that don't verify cleanly), but at this point it's impossible to prove that one of them will be fixed for sure. I am optimistic that we will see a decrease of bugs that are caused by half installed packages and if this is not enough, think of all the bugs that cannot with an update because we have no way to restart a service or program running in the background. I just looked through evolution-data-server bugs: 50 crashes were fixed for only for a single binary (evolution-alarm-notify) but we have no way to apply this fix, we can just install the fixed package and wait. --Cwickert 07:51, 16 July 2012 (UTC)
    • Agreed. I have to close many bugs every week as CANTFIX when the rpm database is corrupted or a system refuses to boot as a core system file is corrupted. --Rhughes 07:52, 18 July 2012 (UTC)

• Can you please follow Lennart's example when making these extremely unpopular changes and start a discussion with your users? I am sure you have read http://0pointer.de/blog/projects/systemd.html back in 2010. Thank you. --Mordae 06:41, 16 July 2012 (UTC)
  • While I am not a friend of this feature, I don't think that blogging can be a mandatory requirement for the feature process. There was a broad and controversial discussion on f-d-l in which the feature owners participated. Same in the FESCo meetings. --Cwickert 07:51, 16 July 2012 (UTC)
  • Blogging for permission never ends well. There are lot of highly opinionated people on the internet that get very upset when a feature is added that isn't focused on their specific use case. Design on the other hand, when taking into account our key stakeholders seems to work well. --Rhughes 07:52, 18 July 2012 (UTC)
• PackageKit already works great in Fedora 17! It even restarts daemons that were updated. I am really impressed by the metadata that Fedora has for updates, and that it only requires a "Log out, Log in" for many libraries. This change would make it more difficult to stay up to date with security updates, as users will just delay doing the reboot. If the offline update mode is only for packages marked as "Suggest reboot", then I can't see any negative about this. (I am a user of ZFS, and currently it's impossible to generate the entries in grub.cfg automatically, and I have to build the modules for every new kernel before booting into it. This would probably mean that I can't use PackageKit on F18, but I realise that I'm not the main target audience) --fa2k

added to release notes

https://fedoraproject.org/wiki/Documentation_Boot_Beat Immanetize (talk) 15:49, 26 October 2012 (UTC)

unconfigurable feature?

Am I interpreting description right? - this "feature" does not have user-accessible killer-switch: the only way to completely disable it is to use some Fedora respin which do not implement it (like xfce for example)?

I've migrated from gnome anyway but I do wonder why feature which radically changes user experience do not have configuration option to preserve old behavior.