Forgot your password?
typodupeerror
Linux

Fedora Introduces Offline Updates 287

Posted by samzenpus
from the while-you-sleep dept.
itwbennett writes "Thanks to a new feature approved this week by the Fedora Engineering Steering Committee, you won't hear Fedora 18 users bragging about systems that have been running continuously for months on end. 'Fedora's new Offline System Update feature will change the current system to something that is more Windows- and OS X-like: while many updates can still be made on the fly, certain package updates will require the system to be restarted so the patches can be applied in a special mode, according to the Fedora wiki page on the feature,' writes blogger Brian Proffitt."
This discussion has been archived. No new comments can be posted.

Fedora Introduces Offline Updates

Comments Filter:
  • by Swave An deBwoner (907414) on Thursday June 21, 2012 @08:43PM (#40406191)
    It's possible to convert to the new unified filesystem without using anaconda, as described here [gmane.org] and in the original reference here [fedoraproject.org].

    I can say from personal experience that the method described worked, without evidence of any problem, when I upgraded via yum from F16 to F17 on a hard drive dedicated to Fedora.
  • by Anonymous Coward on Thursday June 21, 2012 @09:29PM (#40406583)

    redhat (aka fedora) has always had a pathetic package mgmt system. They finally got something that didn't completely suck when they adopted yellow dog's, but really, RH's Not Invented Here mantra is really to its and its users detriment (I think since yellowdog was as RH derivative, and RH's pkg manager, uptodate, sucked sooooo bad, they made this one exception to NIH).

    Debian has handled updates and major upgrades flawlessly for decades (years before RH existed). Maybe fedora / redhat can base their distro on something that works. Just become yet another Debian based distro that just works.

    Debian just restarts the bits that are likely to break if they were not restarted. Config files that have been modified are always asked if you want to keep / replace / view diff and merge. I've got hosts that started on potato (mid 1990s) and are now running squeeze (current stable)-- uneventful upgrades, all (apt-get dist-upgrade; done.). Debian got it right, just use it.

    Redhat seems to attract windows users, so I guess they will accept this just like they accept not being able to do upgrades (yeah, redhat recommends a clean install rather than an in place upgrade WTF up with that?!).

  • Re:Again? (Score:4, Informative)

    by fnj (64210) on Thursday June 21, 2012 @09:56PM (#40406751)

    Assuming you don't want to RTFA, how about the the feature page [fedoraproject.org] itself.

  • Everyone calm down (Score:5, Informative)

    by Fnord (1756) <joe@sadusk.com> on Thursday June 21, 2012 @11:02PM (#40407159) Homepage

    Ok, you guys (and TFA) seriously missunderstand this feature, and yes it is a feature. This won't affect any update that doesn't already require a reboot. The difference is that currently if you update a critical system library, everything that depends on that library has the potential to act in an unstable manner until the next reboot occurs. This change says that if you're updating one of those libraries, the update doesn't actually happen at package install time, it gets scheduled to occur on the next reboot. That's it. No more extra reboots, just more stability and updates scheduled for boot time.

    The fact that windows has this feature isn't a problem, its the fact that it requires it on nearly every dll update. The reason for this is that windows locks files when they're in use, so its actually impossible to update the file until the services that use it (which are often core system services) are stopped, ie at boot time. Linux has avoided this by making its filesystem be refcounted. If a file is in use and you delete it, it stays there until the thing using it exits. So library updates just delete the old library and install a new one, while programs using the old library continue to until they're restarted. This works until you have something dynamically loading stuff, or when you have ipc between programs using the different versions of the library, or a million other modern techniques that unix designers didn't think of.

    Anyway, this really is not the travesty everyone here thinks it is.

  • Busting the myth (Score:5, Informative)

    by benjymouse (756774) on Friday June 22, 2012 @04:40AM (#40408993)

    ToasterMonkey is correct: The reason that you usually do not need to restart the system or applications on Linux is the fact that the potential problems of *not* restarting are simply *ignored* on Linux. It's a head-in-the-sand solution.

    Most of the time this does not present a problem. It is only when some application uses dynamic or delayed loading (and the suddenly loads an updated and binary incompatible library), uses on-demand loaded resources (what Firefox does) or have other types of dependencies between what sits in memory and what sits on disk.

    But there is no secret or magic sauce in Linux which makes this not a pronlem. It is simply assumed that it's not a big problem. But in the case of Firefox this is a regular occurrence. And we all what updating glibc can lead to.

    Java will also delay/demand load classes/libraries. Updating to the next version of a Java application while it is running may very well set the running application up for a crash. If a library/class has not yet been loaded (or has been evicted), the risk is that updating the disk files will lead to an incompatible class being loaded when it is required. While designing with backwards-compatibility in mind is good style, it is not reasonable to expect that the developer foresees all of the problems and complexities this can lead to.

    The same situation exists for binary modules and other types of runtime environments. As software is getting more complicated techniques such as dynamically or delay loaded libraries/resources, object serialization which depend on a specific binary format, pre-compiled scripts etc. all risk running afoul of the head-in-the-sand mentality.

    What is needed is a way for applications or services to register that they depend on certain files. The application may very well be able to survive (or even encourage) updating some of the files during normal operating (think plug-ins). But other files are expected to *not change* beneath the application. This is a reasonable expectation, but only the application (developer) can tell the update process which files it is ok to change on the fly and which files really only should be changed while the application or system is offline.

    At this time there is no way for applications or background processes to tell the Linux system or an installer what it should do prior to and after updating certain files. Individual updates may be written to look for certain processes it considers in-risk - but that is really getting it backwards.

    Windows has had the Restart Manager (http://msdn.microsoft.com/en-us/library/windows/desktop/cc948910(v=vs.85).aspx) since Vista. Applications, device drivers, system services etc can now register with the RM (for instance all of the files in its directory and certain system wide libraries) and tell it that certain files should not be clobbered during an update/installation if the application is running. When an installer wants to replace a file which has been registered with RM, it can ask (default if using MSI installers) the RM to ask applications with a registered interest if it would be ok to save their state and close. If all applications/services agrees, the RM will then send the actual save+close message to the applications/services. The RM will then relinquish control to the installer which will replace the files. After the installation, the installer invokes the RM again to let it restart all of the applications.

    When saving their state the applications/services can register how they want to be restarted to re-establish the state they left, i.e. Word and Excel opens the same documents, Chrome opens the same tabs re-establishing scroll positions etc.

    When the RM determines that a file is being held locked by an application which is *not* registered with the RM it backs off and does not ask any apps to stop (it wouldn't know how to ask them to restart). Instead the installer schedules *all* of the files to be replaced "off-line", i.e. you will not have a situation where some of the files have be

  • by Entrope (68843) on Friday June 22, 2012 @07:41AM (#40409711) Homepage

    I am not sure what distro you're using, but when Firefox gets updated on my Ubuntu machines, it does pop up a dialog box saying that Firefox was updated and needs to restart -- and then it waits for my permission to do so. When a low-level package (kernel, libc, etc.) gets updated, one of the menu bar icons changes to indicate that a restart is needed to complete the updates -- so also I have control over when that happens.

    My system doesn't initialize USB properly on reboot; about every other boot, Grub can't see keyboard input, so I can't select which partition to boot from. I only reboot a few times a year, though, so it would be a gross waste of money to replace components (starting with the motherboard) until the problem got fixed.

If you think nobody cares if you're alive, try missing a couple of car payments. -- Earl Wilson

Working...