Description of problem: Hello, First of all, thanks *a lot*: preupgrade fills a *very* necessary niche in the Fedora software ! However, please consider adding (or document the existing) a few key procedures of doing things: 1. Suppose one completes (partially or totally) the first phase of preupgrade - until reboot. Than it changes mind and don't want to perform the upgrade. Could you please explain how to revert system in the old *clean* state (delete all packages, images and grub entries that preupgrade has created, freeing disk space) ? 2. Preupgrade should provide a way to check it has enough free disk space to complete the upgrade *to the last phase*. I've already arrived in the situation when preupgrade downloaded the packages, the anaconda couldn't complete the upgrade due of lacking disk space, leaving the system in an bad state (disk 100% full, a default boot entry to perform the impossible upgrade, etc.). 3. Preupgrade should consider the case in which the upgrade is done *remotely*, via ssh (really, this is the *main* reason for which one attempts to upgrade a system via yum and not via bootable media). So preupgrade will need a way to complete the upgrade *without human intervention after reboot*. The scenario is: - the administrator logs remotely, as root, to the (functional) system to be upgraded via "ssh -X system.example.com" - the administrator invokes preupgrade - the system reboots - the upgrade should be completed without user intervention Best regards, Razvan
Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
I also had 2 above, but recovered nicely. Preupgrade told me how much memory it needed, I booted into the old OS, I removed packages that had that much memory, rebooted into the anaconda entry, and everything went fine after that. On point 3 above, I would say that the main reason I upgraded using preupgrade is so that I would only upgrade the things I wanted without the hassle of downloading an iso and burning it. Rather than open a completely new bugzilla, I'll just add my 2 cents here as this ticket expresses the spirit of what I want. I'm not sure what the etiquette is, so if this isn't correct let me know. I just went through a very successful use of preupgrade from F7 to F9 and have some suggestions. Integrate bit torrent into this and prioritize the basic packages for download first (glibc, kernel, hal, etc.) so that while the downloads are occurring the basics can be sharing out to others. It took 18 hours to download the packages. If 10000 people are doing this, it would really speed up the transfer for everyone to use a torrent. Also, for those of us who don't use torrent regularly, it would ensure that the security aspects were handled correctly. I've read posts about people whose machine was compromised because they didn't do it properly. Install the basic items necessary to boot first so that if there are problems the system is bootable so the problems can be resolved from within it. Give people the option of keeping the packages from the anaconda install so they can do other upgrades. I intend to use them for all of my upgrades. Because of the error I didn't see the end game so this might already be there. When the updates are completed and the message box comes up saying, this could take a little while, it would be great if there was some kind of progress indicator or explanation. It took a few hours, as long as the install did. Because everything else worked so well, and I could see the hard disk light going, I gave it the benefit of the doubt and presumed it hadn't hung. But it would be nice to see some feedback.
Hello, I totally agree with comment #2. IMHO, the main limitations of preupgrade (in its present form) are: - point 3 in comment #1 above (inability to perfor upgrades remotely); - sometimes, after reboot, preupgrade tries to re-download some packages (and it fails, especially when packages are large or network connectivity is not very good). However, I consider preupgrade an excellent idea. Could you please give us any news about this ? Regards, Răzvan
Triage here. Marking ASSIGNED because there's enough definition to the bugs -- but really these need to be split, one issue per bug. Leaving that to the maintainer and the reporter to work it out amiably.
As instructed in comment #4, I've splitted this in bug #459328, bug #459329 and bug #459330 respectively. I'll try to close this. Many thanks, Răzvan