Bug 439160

Created attachment 299309 [details]
/var /tmp /etc from the failed attempt to upgrade

Float division?  Not sure where that'd be bubbling up from.  Going to make my
first guess rpm ;-)

Is this by any chance a Xen host? See bug 435309...

No, unfortunately this was not Xen host, and anaconda screwed it up so much that
I have only today made it working again. ;-)

I have a system where I installed a new 2nd hard drive (XP is on the first) and
I installed Fedora 9 Beta.

Not knowing better, I selected to boot from the new drive (I think is was sdb)
but  found after install and reboot that I could not get into Fedora. I think
should have selected to boot from sda so I tried a reinstall/upgrade from the
CDROM and no matter what change I make to change the bootloader (update_existing
or create_new) I get the same "float division" error.

Hope to have better luck with a 2nd attempt of a new install as the upgrade
option seems broken.

OK, I can reproduce this with the latest Fedora 9 Preview release thus:

1. Install Fedora 9 Preview from scratch (i.e. not an upgrade) on a hard drive.
I didn't really select anything out of the ordinary - I did it from the x86_64 DVD.

2. Boot back into the install DVD and this time choose Upgrade and select the
drive you installed Fedora 9 Preview (aka 8.93) on.

3. Confirm that you want to update the bootloader (which is the first/default
option anyway).

4. Let the installer churn for a few seconds and *bing* you get a "float
division" error.

5. Attempts to go "Back" result in a warning about the filesystems already being
active - if you choose "Continue" at that point, it just hangs on an (empty)
installation progress bar and I had to reboot.

Workaround:
Boot yet again into the install DVD, but choose rescue system (or you can go
back into the installer and press F2 to get a shell prompt). You should have
/mnt/sysimage as your mounted installed drive. I then removed one package (grub)
that I knew would have to re-installed:

rpm -r /mnt/sysimage -e grub

I then rebooted and repeated steps 2, 3 and 4 above - this time, it didn't get a
"float division" error at step 4 and grub was indeed re-installed and then the
"upgrade" finished.

Conclusion:
"Float division" suggests that the upgrade code had calculated that there were
zero packages that could be upgraded and it did some calculation with
X/<num_packages_to_upgrade> - hence the float division error. As soon as
num_packages_to_upgrade=1 after I deleted grub, no division problem.

Shouldn't this be resolved before GA?

This is unrelated to bug 435309 although both are division by zero errors. The
"float division" here is a Python exception, if it happened in rpm you'd hardly
get a nice gui popup for it ;) And here's where it comes from, easily reproduced
with the procedure from comment #6 (ie there are no packages to upgrade):

class DownloadHeaderProgress:
    def __init__(self, intf, ayum=None):
...
        if self.ayum is not None and self.ayum.tsInfo is not None:
            self.numpkgs = len(self.ayum.tsInfo.getMembers())
            self.incr = (1.0 / self.numpkgs) * (1.0 - self.loopstart)
                         ^^^^^^^^^^^^^^^^^^ 

...and over to anaconda.

*** Bug 443243 has been marked as a duplicate of this bug. ***

Fixed in git

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