On Wed, 2007-01-03 at 16:54 -0500, Jeremy Katz wrote: > I can generally get them to work as well. But there are weird cases > that have been dealt with over time; sure they're work-aroundable if > you're pretty saavy. It's not, though, the experience that most users > want. Live upgrades can also lead to "really interesting" states if > you, say, unplug your machine in the middle[1]. Yeah, but a normal 'yum update' does that too, when you're just fetching errata. It tends to leave two versions of various packages installed, etc. > For a quick list of "off the top of my head weird problem" examples: > * Going from static /dev -> udev involved some interesting shenanigans > to avoid all of your devices disappearing mid-upgrade. > * Newer SELinux policy depending on a kernel supporting that policy > version. > * glibc being built with a dependency on newer kernels for some new > feature > * New rpm functionality used by packages requiring a new version of rpm > to install them Yeah, some of those can be fun -- you're reminding me of things I'd subconsciously blanked from memory :) But they're not that common -- I think that if we _wanted_ a live upgrade to work, it wouldn't be particularly hard to _make_ it work. And to a large extent it _does_ work already. One of the reasons I'm happy using Fedora on servers is because I _am_ entirely confident that I can do a live upgrade on an unattended remote system. I'm no more concerned about it than I am about any kernel update on those machines. > [2] Support for this specific case is in anaconda now Is it clever enough to switch back for F7? I already fixed the kernel :) -- dwmw2 _______________________________________________ fedora-advisory-board mailing list fedora-advisory-board@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-advisory-board _______________________________________________ fedora-advisory-board-readonly mailing list fedora-advisory-board-readonly@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-advisory-board-readonly
