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)
  • 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)

---

• 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)

• 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)

• 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)