Bug 444979

Summary: Preupgrade - a few missing pieces
Product: [Fedora] Fedora Reporter: Răzvan Sandu <razvan.sandu>
Component: preupgradeAssignee: Seth Vidal <skvidal>
Status: CLOSED DEFERRED QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: low    
Version: rawhideCC: katzj, marius.stracna, stanl, wwoods
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-08-16 12:15:17 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Răzvan Sandu 2008-05-02 11:15:02 EDT
Description of problem:


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,
Comment 1 Bug Zapper 2008-05-14 06:31:18 EDT
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
Comment 2 stanl 2008-05-18 09:22:30 EDT
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.
Comment 3 Răzvan Sandu 2008-07-25 09:37:42 EDT

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 ?

Comment 4 Paul W. Frields 2008-08-10 16:54:14 EDT
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.
Comment 5 Răzvan Sandu 2008-08-16 12:15:17 EDT
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,