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."
- Franky double clicks on the icon.
- 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.
- 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
- As time progresses, the items on the list are checked off. Meanwhile, Franky is free to do other tasks.
- 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.
- 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.
- As the items on the list are checked off, Franky is free to do what he wishes.
- 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.
- Franky chooses to reboot now.
- His system restarts, and runs the Anaconda installer.
- Once complete, Franky's machine reboots into the new Fedora release.
5a. Franky chooses to reboot later, and is returned to his regular desktop.
- 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.
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.
ReplyDeleteI'm not sure I understand.
ReplyDeleteWhat 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 wrote:
ReplyDelete> 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.
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.
ReplyDeleteA 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?
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).
ReplyDeleteSo 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.
You might need to consider how you handle it the two situations:
ReplyDelete1. 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).
Sounds good to me
ReplyDeleteThe 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.
ReplyDeleteI'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.
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."
ReplyDelete... or even a pre/post-reboot portion to 'dangerous' upgrades.
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.
ReplyDeleteJust 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 :)
ReplyDelete