Slashdot Mirror
Fedora Introduces Offline Updates
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."
why is this a good thing exactly?
---Saying gnome 3 is better than windows 8 not so much a compliment as it is damning with light praise.
"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!)
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!
Democrat delenda est
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.
Spelling mistakes, grammatical errors, and stupid comments are intentional.
> Are Gentoo/Debian really that intertwined with whatever Fedora maintainers decide?
Not yet. But if GNOME and/or Firefox start requiring the feature other distros have a choice between two bad options. This new Linux only notion that started with systemd is increasingly Fedora only. You can have your distro if you want, if it behaves just like Fedora. One big monolitic blob of alien tech. Want the new udev? It is part of systemd. Want the new GNOME, wait for it to be unusable without udev which requires systemd. And so on.
Democrat delenda est
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.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
Also note that this feature is about implementing offline updates for GNOME. Other spins are not affected, although they could choose to use the same systemd and PackageKit infrastructure, and provide a similar experience.
[emphasis mine]
I guess you could just use a spin that doesn't require this or just not use GNOME.
No, no, you're not thinking; you're just being logical. --Niels Bohr
Not really, it's pretty easy.
I was under the impression that some cards needed all that "POST and BIOS stuff" in order to get back into a predictable state.
Not yet. But if GNOME and/or Firefox start requiring the feature other distros have a choice between two bad options.
Actually, I think it leaves with one good option. Give GNOME the boot, Firefox the finger, and ship with KDE and Chromium. I used to use both, until GNOME3 and Firefox's general suckiness pushed me off onto the alternatives.
Just because you're paranoid doesn't mean there isn't an invisible demon about to eat your face
It's possible to convert to the new unified filesystem without using anaconda, as described here and in the original reference here.
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.
No, preupgrade can handle it. It still requires a reboot into Anaconda but it does its work without any need for interraction and it does it fairly fast.
I was opposed to the merge on historical principle until I read all of the arguments and thought on it a bit.
The change does make sense. Existing practice is a solution to a problem that hasn't really existed for decades. The whole distro now fits into a tiny (by modern standards) partition and we have rescue media now so the importance of always being able to boot / to make repairs doesn't apply anymore. Meanwhile the benefits to nfs mounting of the OS and just generally putting all of the OS proper down that one /usr tree feels right.
It probably should be called /os instead of /usr but that is probably a bridge too far from the changing established practices p.o.v. But imagine a future where we fixed everything to no longer even need the symlinks to the old /bin /sbin /lib, etc. Then I wonder how much trouble it would be to work out sharing /etc and /var between two distros? Then instead of /usr you put Fedora 20 under /fedora-20 along with /debian-wheezy and the initrd sets up the default paths on boot. Suspect it would require too much standardization of things in /etc though for distict distros to even mean anything. Just thinking aloud, trying to get outside the box a bit.
Democrat delenda est
I actually took time to read the TFA and as many background freaking thing that are related that I can find on this thing, and tell you the truth, I am still trying to understand
I just do not understand why they want to take the thing offline, in order to run an update
I mean, what is wrong in keeping the system running while the patches run in the background?
I can understand it if the thing got a big hit - either from a worm attack or trojan or attacks from the outside - ... in real big emergency where the system can't just take it anymore, maybe, just maybe, take the whole thing offline (or power down the entire system), that makes sense
But ... just updating the damn thing you gotta take it offline, just like Windoze?
What's the freaking point?
Muchas Gracias, Señor Edward Snowden !
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â¦)
That's one thing OSX does right. It *shows* you if you need to reboot for EACH package. Microsoft _still_ can't get this right after how many years?? "This update may require to reboot." WTF you don't know?? Either it modifies kernel files or it doesn't? Either the resources provided by a .dll are in use or they are not. It's not fucking rocket science.
The headline made me think "Fedora will start sending patches and updates on CD through the mail."
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?!).
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'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 the support problems of users complaining about weird issues after updating a month ago.
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, so I'm waiting for the next power failure to reboot and for new kernel to actually be used.
*I'm perhaps not the only one confused by the use of "offline" in the title and TFA. In a different sense, Debian and friends can already do an "offline" update. There's a "--download-only" option in apt-get and an equivalent option in GUI package managers like synaptic. A more accurate but less sexy title would probably be "Reboot now needed to complete Fedora system updates" (if that's what it really is).
Assuming you don't want to RTFA, how about the the feature page itself.
> 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.
Democrat delenda est
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.
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.
Two roads diverged in a wood, and I - I took the one less travelled by. (Robert Frost, 1916)
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.
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 and more fragile, needing now this kind of "kludges" (in my personal opinion) to keep stuff running.
Fortunately the server side is very different and I hope this does not extend to the server stack, having to reboot because you updated apache, postgresql, php or whatever your stack includes; a good amount of server software is designed to keep working with minimum downtime, even on updates, like nginx that can reload itself without loosing connections (by keeping an instance to finish its work and exit when done while giving the new request to the new reloaded instances), even ssh can be updated without loosing you current session.
C-x C-c
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
Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
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.