Follow Slashdot stories on Twitter

 


Forgot your password?
Close
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 More

Fedora Introduces Offline Updates

Comments Filter:

  • um... (Score:5, Insightful)

    by lister king of smeg ( 2481612 ) on Thursday June 21, 2012 @06:51PM (#40405665)

    why is this a good thing exactly?

    • Re:um... (Score:5, Interesting)

      by smash ( 1351 ) on Thursday June 21, 2012 @08:07PM (#40406399) Homepage Journal
      I *suspect* it is perhaps due to securing system files in a manner so they can't be modified when running multi-user (thus immune to exploit by user code) - kinda like freebsd securelevels perhaps. At least, thats the only reason I can see for it.

    • in order to avoid problems related to conflicts of libraries and services that are currently running with those on disk...

      Installing updates while the session is running causes havoc with some apps like Firefox that have file resources that have not been locked (just try updating xulrunner when Firefox or Thunderbird is openâ¦)

      • I have read TFA, and I still CAN NOT understand the whole thing !!

        If it's the FF, they can kill FF and re-launch the thing after the patch are done

        What's the freaking need to take the whole system down?
         

      • First off i did read the artical

        Installing updates while the session is running causes havoc with some apps like Firefox that have file resources that have not been locked (just try updating xulrunner when Firefox or Thunderbird is openâ¦)

        but i am also a regular Linux desktop user and as for firefox needing to be shut off when ever i run update i am simply informed that i need to restart firefox. no reboot ever. occasionally i may have to logout and back in for a update/install but still no reboot needed. this is still a pointless bad idea.

    • Re: (Score:2)

      by slazzy ( 864185 )
      I think Fedora is intended to be "bleeding edge" technology wise, so they are trying something new (for Linux) and I guess they'll see how it works?

      • Re: (Score:2)

        by arth1 ( 260657 )

        I think Fedora is intended to be "bleeding edge" technology wise

        No, cutting edge. Bleeding edge is cutting edge gone wrong.
        Like we have here.

  • Wrong area of focus. (Score:5, Insightful)

    by elysiuan ( 762931 ) on Thursday June 21, 2012 @06:51PM (#40405669) Homepage

    "Installing updates while the session is running causes havoc with some apps like Firefox that have file resources that have not been locked (just try updating xulrunner when Firefox or Thunderbird is open)," blogged Fedora developer Richard Hughes.

    Seems to me adding features to the package system that can determine and possibly correct such things (ie, closing Firefox or Thunderbird) would be the better way to go rather than force me to have to reboot. Hopefully it will retain the capability to install new software while updates are pending. I'd hate to have to reboot to install some tiny dependency. (A restart is required before you can install libfoo. Ugh!)

    • Re: (Score:3, Insightful)

      by silas_moeckel ( 234313 )

      So a bunch of gui apps are breaking things? Step A tell them there idiots and to fix there broken bits. Step B go down to text mode and back lets the X sessions figure themselves out. Why would you need a reboot for any of this. Server apps should be restarted if needed and user apps should not be so broken.

    • Re:Wrong area of focus. (Score:4, Insightful)

      by tuffy ( 10202 ) on Thursday June 21, 2012 @07:16PM (#40405935) Homepage Journal

      Seems to me adding features to the package system that can determine and possibly correct such things (ie, closing Firefox or Thunderbird) would be the better way to go rather than force me to have to reboot.

      This is exactly right. Look at the Flash updater on other systems. If a browser is running, Flash closes it down during an update. Fedora could easily detect Firefox is running and close that down during an update. If X11 needs an update, bounce the user to the console until it completes. And so forth. A whole boot mode just for installing "extra important" updates feels like the wrong approach to a more general problem.

      • Re:Wrong area of focus. (Score:5, Interesting)

        by serviscope_minor ( 664417 ) on Thursday June 21, 2012 @07:50PM (#40406253) Journal

        If X11 needs an update, bounce the user to the console until it completes.

        Or, update X, and the user gets the new version when X is next restarted. This is what Arch does: the old files (binaries) are deleted, but remain on disk until the program exits. I've had uptimes of many months and not had trouble with X being updated.

        • Do that, and 4 months later, -one- of the many successfully applied updates will screw things up, and you'll have to figure out which update exactly was the culprit. Don't get me wrong, it's a fine strategy, it's just one of the reasons I dread reboots..

          • Do that, and 4 months later, -one- of the many successfully applied updates will screw things up, and you'll have to figure out which update exactly was the culprit.

            Problem is, it still does NOT make any sense !!

            Okay, they took the whole system down and do a reboot

            Does that provide any guarantee that 4 months from now one of the updates will not fuck up and leave you scratching your head?
             

            • Re: (Score:2)

              by DeSigna ( 522207 )

              It's still best practice to pull systems from production for updates and restart after patching to test for issues.

              Rebooting makes sure everything is using the new version, making it quite obvious if there's any big problems with the updates.

              Having the updates process force-kill dependant applications on a multi-user or server system isn't going to make the sysadmin any friends unless they are taking it out of production first. Enforcing this for Fedora makes sense (it's upstream of RHEL), and it reduces th

        • The problem is, is that X doesn't get updated until you actually restart the process. If you don't restart for many months, you haven't really updated anything. This is especially true if, for instance, you are updating Apache. If you leave it running, and don't restart it, the updates never actually get loaded, and your system is still vulnerable. Same goes for things like Kernel updates. I know that it's possible to swap the kernel out while running, but I don't think most distributions do that. To relo

          • Fedora has never been aimed at the general public. I've always seen it as aimed at power users who don't want to tweak things to get a working desktop. A middle ground between Ubuntu and Arch.

            As far the rebootin, that's just silly. If the Fedora devs think the user should reboot after applying an update, then they can present that as a message to user after they apply updates. Then the user can reboot if they want to.

            • I use Fedora on two of my computers and that's what happens now. Most times a set of patches doesn't require any action at all after they've installed. Sometimes it requires a log out and log back in. It is unusual to need a reboot but it happens occasionally - indeed it happened yesterday with the new kernel, but even then it leaves the reboot up to my discretion and my choice of when.

              This really doesn't look like it's going to change anything too radically.

          • Restarting apache post-upgrade is what the post-upgrade scripts for the rpm package are for.

            Package Maintainer Fail. File a bug report.

      • Or rather make programs not care if their files get updated. It should all be in memory anyway.

        I can do a full system update (Gentoo) without any programs caring that their files have been replaced by newer ones. Restart a program, say Firefox, and its the new version.

        • Then you get somebody who things 'woohoo, I'm all up to date!' and doesn't wind up actually restarting the program in question for however long, and is vulnerable.

    • Re: (Score:3, Interesting)

      by Anonymous Coward

      The correct solution seems to be how Gentoo does it: Install BOTH versions of the library. Until nothing is accessing the old version anymore, it won't get uninstalled. So in this case, until FireFox is restarted it will keep having the old version of XULRunner around all the live-long day.

      Or is using library versioning really such a foreign concept to newer Linux developers? Hell, my Gentoo box right now has four different versions of Python installed: 2.4, 2.6, 2.7, and 3.2, so I can do cross-version deve

    • Re:Wrong area of focus. (Score:4, Insightful)

      by bill_mcgonigle ( 4333 ) * on Thursday June 21, 2012 @07:31PM (#40406083) Homepage Journal

      "Installing updates while the session is running causes havoc with some apps like Firefox that have file resources that have not been locked (just try updating xulrunner when Firefox or Thunderbird is open)," blogged Fedora developer Richard Hughes.

      When Ubuntu noticed this same problem, they included a Firefox extension to tell the user to restart. Fedora tries to re-plumb the OS and re-invent the behavior Windows is moving away from instead?

      Fortuantely, it looks like this is constrained to the GNOME environment at the moment, so most of us may be safe - for now. I'll have to surf over to the KDE list to see if there's some righteous indignation going on there.

  • The stupid! It hurts! (Score:5, Insightful)

    by jmorris42 ( 1458 ) * <jmorris@[ ]u.org ['bea' in gap]> on Thursday June 21, 2012 @06:51PM (#40405673)

    Good grief, the Stupid coming from Fedora and the GNOMEs is making my head hurt. We managed to update running systems with package management for how long? Leave it to the GNOMEs to fudge things up.... or just have Mac/Windows envy and convince themselves that this isn't a bug, it is a feature!

    • Next up: All the niceties of DLL hell.

      If anything, people should be working towards not having to restart for all updates, even kernel patches. Instead, in the fevor to be more like iOS/OSX and Windows, Linux is regressing.

      • Re:The stupid! It hurts! (Score:4)

        by arth1 ( 260657 ) on Thursday June 21, 2012 @09:49PM (#40407097) Homepage Journal

        If anything, people should be working towards not having to restart for all updates, even kernel patches. Instead, in the fevor to be more like iOS/OSX and Windows, Linux is regressing.

        It's not Linux that's regressing, it's Fedora.

        RHEL, the non-community release based on Fedora, doesn't ever require restarts. You can, if you like, but they actually test that the updates don't require the new kernel they provide. If the Fedora guys present a community release that's completely unusable for RHEL, I expect that Red Hat will pull support of Fedora, and spend that money on in-house development instead. When Red Hat said they wanted to support visionaries, I'm quite sure they didn't mean the kind of visions you only get through illegal substances, and where you end up wearing underwear on your head.

    • As parent said, this is a terrible outcome.

      Moving on constructively, I would suggest fedora should just be a minimal package set and a system for managing VMs. A good way to partition each VM would be for example, each system that manages it's own packages (eg. ruby, perl, firefox). Because of the rise of multi core computing this would have no performance impact at all. The advantages of a system like this include easier system management, better security, and convenience. There will be better upgrade-abil

    • Re: (Score:2, Informative)

      by Anonymous Coward

      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 distr

      • Re:The stupid! It hurts! (Score:4, Interesting)

        by jmorris42 ( 1458 ) * <jmorris@[ ]u.org ['bea' in gap]> on Thursday June 21, 2012 @09:39PM (#40407027)

        > redhat (aka fedora) has always had a pathetic package mgmt system.

        No, rpm is a better system than deb. It had signed packages years before Debian and nice all in one file .srpm/.src.rpm files that build from pristine sources plus patches and a .spec. And rpm specifically forbids (although clueless commerical vendors sometimes ignore it) interactive install/update, absolutely required for mass installs or unattended update. I think you are getting confused over the update systems built atop them. There I would agree that Debian's apt family was better than what Red Hat was shipping until fairly recent versions of Yum and even then I would note that Yum is still a P.I.G. And delta rpms absolutely rock if you aren't sitting on the wire with a local mirror.

        > Debian has handled updates and major upgrades flawlessly for decades

        Not exactly. It took far longer to update my Mythtv system from Debian 5.0 to 6.0 following the directions at debian.org than I have ever spent doing a single version upgrade on a RH/Fedora system. Admitted that was my first time doing a version update on Debian on a machine I cared about and was taking pains to avoid pooching the system so that probably accounts for some of the extra time. Along with the fact that it was connected to a TV and the console was not easily visible so I was also taking care to keep it available over the network at all times during the process, something I haven't tried yet on RH. Point is neither one does version upgrades 100% hands off.

        > (years before RH existed)

        Obviously you weren't actually using Linux way backthen or you wouldn't have said something so ignorant. Debian saw first light Aug 1993 and got it's first primitive package system with 0.01 in Jan 1994. It didn't hit 1.x until years later. RH released 1.0 Oct 1994 and got rpm in 1995.

        > Debian just restarts the bits that are likely to break if they were not restarted.

        Like RH up until this idiotic new notion.

        • It had signed packages years before Debian

          I don't know who got what first but as you said, Debian has this too.

          and nice all in one file .srpm/.src.rpm files that build from pristine sources plus patches and a .spec.

          Same as Debian, you have a [package-source].orig.tar.gz, [package-description].dsc and [debian-specific-patches].diff.gz.

          And rpm specifically forbids (although clueless commerical vendors sometimes ignore it) interactive install/update, absolutely required for mass installs or unattended update.

          You can do unattended installs or updates in debian with

          DEBIAN_FRONTEND=noninteractive apt-get -q -y dist-upgrade

          I think it's pretty safe to assume that the systems are equivalent nowadays.

      • First, yum is superior technically to debians packaging system. Not going to bother explaining, because I seriously doubt it would do any good.

        Next, this idea of rebooting (technically, two boots - download updates, reboot into a small system, apply updates, reboot into complete environment) is an idea that won't matter much soon.

        Hard drives are already in the 3TB territory. btrfs or zfs will become necessary for reliability. When this happens, snapshots will be available to solve the problem properly.

        Now,

        • Re: (Score:2)

          by grcumb ( 781340 )

          First, yum is superior technically to debians packaging system. Not going to bother explaining, because I seriously doubt it would do any good.

          By all means, please do.

          I've worked professionally with the RPM build system and at one time was far too intimately aware of its shortcomings. I haven't built nearly as many .deb packages, but what exposure I've had to them sure made me feel good about their packaging toolkit.

          From a sysadmin's perspective, I don't particularly hate yum, but I don't see anything that makes it more compelling than apt. In fact, I don't see a lot of daylight between them any more, except for yum's tendency to go online and up

    • Implemented for a small set of critical system packages, an offline[*] update makes sense. By "critical system packages", I exclude user applications like Firefox. At worst (or at best) the policy should be limited to kernel upgrades, the way it's been done in a typical Unix or Unix-like system.

      Which strictly isn't necessary. For example, I've already "updated" my running kernel since two weeks ago, while my system continues to run under the old kernel. I know this has security issues, but I'm not a server

  • What? (Score:2)

    by Anonymous Coward

    Bad things are features now?

  • Finally, the Fedora guys have listened to its customers and fanbase! People have been clamouring for years to be able to restart their computers needlessly after updating and now these long years of loyalty have been rewarded. Bravo, Fedora. Bravo.

  • They should use soft reboots with kexec, so the downtime is minimized. It really makes a difference by skipping all the POST and BIOS stuff.

    • Re: (Score:3)

      by tepples ( 727027 )
      I was under the impression that some cards needed all that "POST and BIOS stuff" in order to get back into a predictable state.
  • what's the most annoying feature Windows has? Nice one Fedora.

  • per-package filesystems (Score:4, Interesting)

    by bill_mcgonigle ( 4333 ) * on Thursday June 21, 2012 @07:17PM (#40405947) Homepage Journal

    It's too bad btrfs still has such performance problems with common applications (BTDTBTEXT4).

    We really ought to have each package on its own filesystem. When there's an update, snapshot the filesystem, let currently running processes reference the old stuff so they don't crash, but new processes can have the new stuff. When the old version on longer has any references left, it can go away. This might not always make sense, but for a desktop it's a lot better than what we have now.

    Yeah, there's some plumbing work that needs solving (rpm, containers interaction perhaps, VersionKit or whatever) but this idea of rebooting a linux system to get consistent updates is just picking at a scab, and indicative that a real solution is still necessary.

    • That's an interesting proposition. A similar idea has been realized in the research Linux (and Hurd) distibution NixOS.

      "In NixOS, the entire operating system — the kernel, applications, system packages, configuration files, and so on — is built by the Nix package manager from a description in a purely functional build language. The fact that it’s purely functional essentially means that building a new configuration cannot overwrite previous configurations. Most of the other features follow

      • That's good stuff. Linux distributions need to stay nimble and borrow liberally from other good ideas.

        I experienced rollback upgrades with nexenta, and liked that quite a bit. ZFS >> BTRFS right now, though.

        I'm using Puppet to describe a test cluster, and I absolutely love that (at least the ideas if not the expression necessarily). Functional declaration is absolutely the right way to do things. I've been wondering about how something like Puppet (if not Puppet) should become integral to Fedora

    • Btrfs performance is bad due to a lot of seeks. With a SSD and Facebook's Flashcache to cache your rotating clunkers it performs very nicely.

      • Re:per-package filesystems (Score:4, Interesting)

        by bill_mcgonigle ( 4333 ) * on Thursday June 21, 2012 @10:46PM (#40407399) Homepage Journal

        Btrfs performance is bad due to a lot of seeks. With a SSD and Facebook's Flashcache to cache your rotating clunkers it performs very nicely.

        Don't apologize for bad performance. ZFS has a very similar feature set to BTRFS but it doesn't have all these problems. Maybe BTRFS just isn't ready yet - I wonder if the developers ever feel like they'd wish people stopped rushing it into production.

        Anyway, I use SSD+Flashcache on some servers - it works great. But that shouldn't be the minimum system requirement for a Fedora machine.

  • 1. This feature was in other distributions for years if not decades -- if kernel or libraries used by everything are updated, the updater asks the user to reboot, otherwise only affected programs are restarted.
    2. It's Brian Proffitt, an anti-Linux attack dog again.

    • Re: (Score:2)

      by fnj ( 64210 )

      FAIL. That's not the same as what this MIS-feature does. This abortion actually APPLIES the updates during the bootup process - like -hack- Windows -spit-.

      This feature was in other distributions for years if not decades -- if kernel or libraries used by everything are updated, the updater asks the user to reboot, otherwise only affected programs are restarted.

      • [citation needed], and Brian Proffitt does not qualify.

      • Looked through Fedora wiki page he referenced. It's an experimental feature that may end up not even being used, applicable to a very small subset of packages, to make sure that updater itself won't get broken or confused halfway through the update process. What may say a lot about the expected quality of the package manager/updater, but with no real effect on anything.

        To be fair, Gentoo occasionally suffered from the very kind of breakage they are trying to prevent, but Gentoo has an excuse of package mana

        • Re: (Score:2)

          by fnj ( 64210 )

          I looked at the page too. The word "experimental" does not occur there. It's targeted at Fedora 18 and is 85% complete already.

          While I might not care if Fedora gets screwed up by this abortion, Fedora is the source for Redhat Enterprise Linux, and I care VERY MUCH if RHEL 7 gets screwed up come 2013 or 2014.

  • Awwww... (Score:3)

    by Guppy06 ( 410832 ) on Thursday June 21, 2012 @08:19PM (#40406519)

    The headline made me think "Fedora will start sending patches and updates on CD through the mail."

  • users will just deprioritize updates (Score:5, Insightful)

    by ffflala ( 793437 ) on Thursday June 21, 2012 @08:29PM (#40406587)
    A lot of Windows users have been burned enough to have learned the lesson that updates will not only interrupt your work flow, but risk dumping your unsaved files and/or the tabs that they were in the middle of reading when the update dialog popped up. These users are taught that the responsible thing to do is to keep their systems up to date, but what seems worse: an action that risks dumping all of your unsaved progress, or a "security update" that fixes something that hasn't been a visible problem on their end?

    The workaround to the focus-stealing forced-reboot update is, of course, is simply *not to apply the updates in a timely fashion.* As long as their applications are up and running, and they'd prefer to leave them up and running, why would they?

    With this move FC is just setting itself up for the deprioritization of updates, and this could ultimately lead to worse security and stability.
  • It appears to me that the real problem is that these libraries are not versioned.

    Surely a neater solution would be to have some type of version number associated with them so that multiple copies of a library could co-exist peacefully on the same system.

    • Re: (Score:2)

      by vux984 ( 928602 )

      Surely a neater solution would be to have some type of version number associated with them so that multiple copies of a library could co-exist peacefully on the same system.

      Because you want the old defective buggy one with security holes lying around indefinitely?

  • Everyone calm down (Score:5, Informative)

    by Fnord ( 1756 ) <joe@sadusk.com> on Thursday June 21, 2012 @10: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.

    • The fact that windows has this feature isn't a problem, its the fact that it requires it on nearly every dll update.

      Is that really true anymore?

      • Re: (Score:2)

        by Fnord ( 1756 )

        Its semi-true. Since XP they've gone through and tried to untangle the mess of dll dependencies, and there's a lot that doesn't require a reboot. But if you look at the dependency graph of windows core libraries its still a big circular mess.

        The file lock on open is still definitely true though, its core to the way windows filesystems work and changing it would break compatibility with decades of software.

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

      Holy CRAP, please don't paint it like Linux does what it does to "avoid a problem" - Linux does what old Unix systems always have done EXCEPT urge people to update from single user mode or reboot after any patch set - unless you read every patch's release notes and take redial action. Linux vendors just skipped that part, and shame on them.

      Windows does what _it_ does to avoid the EXACT problem you go on to explain, the results of what Linux does is undefinable!

  • As others have commented, the wiki is not very clear on all implications on this, but as far as my use of linux (12 years now), I have never had to reboot for any kind of update or security patch that is not kernel related or glibc, that is why I use Linux, because once it works it just keeps working, I really hated the times when even installing an application on Windows would reboot the entire system, WTF?

    Seems to me that the upper level of the Linux desktop stack is getting more and more complex and more

Slashdot Top Deals

As you will see, I told them, in no uncertain terms, to see Figure one. -- Dave "First Strike" Pare

Close