James Bowes

Purveyor of Pre-eminent Programmes

Another Fedora Upgrade Post

with 13 comments

Devan and I were chatting a bit about Fedora upgrades this morning. Given that he and I are both recovering debian users, we do miss (apparently) seamless live upgrades between releases. So following on the heels of Doug and Devan, here is my take on upgrades.

First, offline upgrades will always be required for some cases. There’s always going to be some cruft we need to drop, and can’t do it on a live system.

Second, allowing upgrades from release X to X+2, etc is too risky and would need more QA than I think we’d be willing to commit. Likewise for rawhide to stable, or stable to rawhide. These all should be possible for the intrepid, but not defaults options.

A use case for upgrades

Franky Fedora is a Fedora user. He uses a default install, and is not familiar with the command line. Whenever the update applet appears at the top right of his screen, he launches it and updates his system. One day, instead of the regular update icon, a different one appears with a popup message “A new version of Fedora is available! please click to upgrade.”

  1. Franky double clicks on the icon.
  2. Franky is presented with information about the upgrade, including release notes and an advisory to back up any important data before continuing, as well as a choice to continue or cancel.
  3. Franky selects continue, and is presented with a list of tasks, as they complete, they are checked off. The list looks like:
    • Updating current release
    • Downloading software for upgrade
    • Preparing system for upgrade
    • Upgrading system
  4. As time progresses, the items on the list are checked off. Meanwhile, Franky is free to do other tasks.
  5. Once all items on the list are checked off, Franky is presented with a message telling him that his upgrade is complete, and advised to reboot his system. He is given the choice to reboot now, or not to reboot if he wishes to complete other tasks.
  6. Frankly chooses to reboot. His system restarts, and he is presented with the next Fedora release, and all of its wonderful new artwork.

Extension Points:

2a. Franky selects cancel, and is returned to his regular desktop.

3a. Franky’s system requires a new filesystem, so he is presented with the following tasks instead:

  • Updating current release.
  • Downloading software for upgrade.
  • Rebooting system info upgrader.
  1. As the items on the list are checked off, Franky is free to do what he wishes.
  2. When the final item is checked off, Franky is presented with a message telling him his system must be restarted to continue the upgrade. He can select to reboot now, or to do so on his own later.
  3. Franky chooses to reboot now.
  4. His system restarts, and runs the Anaconda installer.
  5. Once complete, Franky’s machine reboots into the new Fedora release.

5a. Franky chooses to reboot later, and is returned to his regular desktop.

  1. Later he reboots, and moves on to step 6.

Proposed implementation details

  • An upgrades metadata file added to the main repository metadata. This file will contain a pointer to the new Fedora release, as well as some caveats for upgrading. For instance, that the i386 version of dbus must be removed before upgrading.
  • The upgrades file will specify whether a live or offline upgrade should be done.
  • The caveats will run during the ‘Preparing system for upgrade’ step.
  • The updating current release step is just a ‘yum update’ after it is completed, the upgrade tool shall restart, if it has been updated during this process.
  • The caveats metadata will be updated over time if any new issues arise.

Interaction between the upgrades metadata and other repos may get hairy. How does the system know what do to when you are running updates versus updates-testing? Perhaps each repo should have upgrades metadata.

This is all an extension to the F9 PreUpgrade feature. Getting the Anaconda reboot working is a great first step. Once that’s done, we can move on to the optional live upgrade, a command line interface, etc.

Comments/flames appreciated.

Advertisements

Written by jbowes

October 20, 2007 at 11:44 am

Posted in fedora, tech

Tagged with , , , ,

13 Responses

Subscribe to comments with RSS.

  1. Sounds pretty good to me. I don’t know much about the specifics of upgrade issues but I’m down to give writing this up a go.

    dgoodwin

    October 20, 2007 at 11:57 am

  2. I’m not sure I understand.

    What cruft can’t you drop? What cruft can’t you drop when you allow a reboot? A reboot is prudent anyway, since paths may have changed, libraries may have changed, daemons may have changed. I mean, Ubuntu managed to replace init with upstart as part of an upgrade, and do it painlessly (at least in my experience.)

    Also, while I agree that X->X+2 is probably too big a jump to support (and then someone’s going to want X->X+3 etc.), presumably you could offer upgrade paths from X->X+1 and then X+1->X+2? I happily made it from Ubuntu 6.06 -> 6.10 -> 7.04 -> 7.10.

    I guess I just don’t get it. Ubuntu has meta-packages that contain everything. Upgrading the meta-package pulls in any new packages the system requires that weren’t in the previous release, and removes any others. Why can’t Fedora do the same?

    Side note, maybe it’s just me, but the font in the comment box (under Safari anyway) is a real pain to read.

    Ian

    October 20, 2007 at 12:31 pm

  3. Ian wrote:
    > I’m not sure I understand.
    > What cruft can’t you drop?

    There is always a chance that something will require your root partition to be unmounted when it runs. For instance, the switch from dev to udev. Sure, you could possibly get around these with a series of reboots, runlevel switches, etc. But why bother with all that complexity when Anaconda can already handle it?

    Wrt metapackages, proper dependencies on packages will/already do the same thing. Requiring a reboot into anaconda isn’t for packages, but for the larger changes.

    James Bowes

    October 20, 2007 at 12:54 pm

  4. 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?

    Ian

    October 20, 2007 at 1:11 pm

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

    Jesus M. Rodriguez

    October 20, 2007 at 7:50 pm

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

    Karsten Wade

    October 20, 2007 at 9:41 pm

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

    Philip

    October 21, 2007 at 12:47 am

  8. Sounds good to me

    Tim Lauridsen

    October 21, 2007 at 1:25 am

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

    Jeremy Katz

    October 22, 2007 at 9:58 am

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

    Ian

    October 22, 2007 at 5:07 pm

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

    James Bowes

    October 22, 2007 at 5:58 pm

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

    Jeremy Katz

    October 22, 2007 at 6:26 pm

  13. 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 🙂

    James Bowes

    October 22, 2007 at 6:39 pm


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: