Comments on: Another Fedora Upgrade Post

By: James Bowes

James Bowes — Mon, 22 Oct 2007 23:39:38 +0000

Just to put things into perspective, Jeremy has spend something like 6.5 years on Anaconda. So its pretty advisable to listen to him when he speaks about upgrades and installs

By: Jeremy Katz

Jeremy Katz — Mon, 22 Oct 2007 23:26:28 +0000

James — that’s a fair assessment. It’s all well and good to say “just put up a here there be dragons” warning, but the sad truth of the matter is “you ship it, you support it”. And I’ve gotten the angry comments in bugzilla to attest to it

And it’s not that I don’t hear the requests… I really do. And I’m not even saying that we don’t take some of the steps which make things work better than they do today (ie, someone needs to revive Seth’s remove-stuff plugin and then we need to get that metadata into at least a “point here for an online upgrade” repo).

But I honestly think that for long-term, sustainable support of upgrades, the *recommended* path for non-expert users always has to be reboot into the installer. With packages pre-cached, yep — did the first bits of that for F8 and it’ll actually be available if we want to advertise it some. With the second stage pre-cached so that you don’t have to download it, yep — bumped the size of the default /boot to 200 megs so it can contain the installer image.

By: James Bowes

James Bowes — Mon, 22 Oct 2007 22:58:46 +0000

The general feeling in the Fedora community (at least amongst those heavily involved in full installations and package management), from what I see, is that If we have two options, and one of them involves a warning about munching your system where the other does not, is to go with the safe one and not scare the bejesus out of Jane Q. User.

By: Ian

Ian — Mon, 22 Oct 2007 22:07:53 +0000

Well at that point couldn’t you just have the upgrade app just point out that “YOU SHOULD REBOOT OR FACE MAJOR BREAKAGE. HERE BE DRAGONS.”

… or even a pre/post-reboot portion to ‘dangerous’ upgrades.

By: Jeremy Katz

Jeremy Katz — Mon, 22 Oct 2007 14:58:53 +0000

The problem is that upgrades can and do introduce incompatibility. You can’t just sit and wait around for the user to reboot into the “new” system because as soon as the package changes, they’re already partially _running_ the new system. API for talking to something over dbus changed? Hope that the copy of that running in your desktop session restarted. Oh wait, we don’t have a way to do that. SELinux policy changed leading to a need to some app on your desktop needing to run as a different context? Nope. Config file format of dbus grew and now the running dbus falls over due to the new service files? More doom.

I’m all for preloading as much of the upgrade work as possible (hence, the preupgrade stuff), but actually *doing* the upgrade in a more isolated environment really is important to having the upgrade process work well.

By: Tim Lauridsen

Tim Lauridsen — Sun, 21 Oct 2007 06:25:12 +0000

Sounds good to me

By: Philip

Philip — Sun, 21 Oct 2007 05:47:53 +0000

You might need to consider how you handle it the two situations:

1. user has installed rpms from other repos (which might support the update, eg rpmfusion) and the repo has a file in /etc/yum.repos.d/
2. user has installed rpms from another source not identifiable (eg for checking for upgrade).

The best solution if an upgrade of Fedora would break an installed 3rd party ap is to prompt for removing the offending ap and suggesting the user reinstall it themselves (they must have been competent enough to have done it in the first place).

Also, it would be nice if the upgrade route could support X -> (X+1) test3 (or 4). I expect many people install the final test version to beta check the next fedora. Perhaps this could be available as an option (prompt for upgrade to Test release).

By: Karsten Wade

Karsten Wade — Sun, 21 Oct 2007 02:41:43 +0000

Would it be prudent to have /home be a separate partition? There is
some latitude with LVM, I suppose, but a separate partition is clean
and safe to work with. But if, as in your example, the user has
chosen defaults for the original install, that does not include having
/home as a separate partition. This is a long standing request:

https://bugzilla.redhat.com/show_bug.cgi?id=150670

Perhaps this needs to be raised as a dependency/blocker for Fedora
upgrades to work as you describe.

By: Jesus M. Rodriguez

Jesus M. Rodriguez — Sun, 21 Oct 2007 00:50:27 +0000

This is an excellent idea and one that is sorely needed. I am still running Fedora Core 6 at home primarily because upgrading to Fedora 7 required downloading the ISO, and doing all that work (yes I’m lazy).

So I’m now planning my Fedora 8 install, because an upgrade from FC6 to F8 doesn’t seem like a good idea. But if the idea of being able to upgrade via yum worked, I would probably upgrade every release

Another side effect is if this were to work, imagine being able to upgrade RHEL 4 to 5 or 5 to next release of RHEL. Probably not as popular a feature in the enterprise, but still a very useful one non-the-less.

By: Ian

Ian — Sat, 20 Oct 2007 18:11:14 +0000

What was so painful about the switch from dev to udev? Make sure the user isn’t using devfs names in fstab etc. or other config files, install udev, and uninstall anything devfs related.

A reboot is probably healthy.

Maybe I’m confused. There are plenty of changes that will require or at least encourage a reboot. When I think live upgrade, I think upgrading without having to boot off a cd or any other process that requires physical access.

… What are we talking about again?