Description of problem: I was updating FC5 installation to F7. Anaconda found around 900 packages to update and after around 640 bombed out with the following: CRITICAL: Traceback (most recent call first): File "/usr/lib/python2.5/site-packages/gtk-2.0/gtk/_lazyutils.py", line 32, in __getattr__ File "/usr/lib/anaconda/gui.py", line 1169, in keyRelease ImportError: No module named keysyms leaving me with a nasty cleanup job as I was left with tons of duplicates. Results turned out to be bootable but very messy. I was using "http method" when this nastinies happened. In a retrospect I should likely to restore rpm database from backups and try the whole process again (or even run 'yum update'). Sigh! Unfortunately I forgot about 'upgrade.log' and it got clobbered later when I was trying to cleanup that system. 'anaconda.log' is attached.
Created attachment 157847 [details] anaconda log from an attempted upgrade
Created attachment 158716 [details] anacdump.txt
I have the same error during upgrade from FC 6 to FC 7 using the ISO file on a partition (see anacdump.txt above). It happens right after the update of man-pages - 2.44-1.fc7.noarch (package 271 of 852).
After starting the upgrade again all remaining 581 packages where installed without error messages.
> ... all remaining 581 packages where installed ... Now try 'yum install yum-utils', if you do not have that already installed, and with this in place package-cleanup --dupes I wonder what you will see. 'package-cleanup --cleandupes' unfortunately is not as straightforward as one would like. After that 'rpm -Va' will likely report tons of missing files.
I haven't seen any reports of this in a long time. I'm going to close it out, though I have a feeling closing it is the fastest way to reproduce.
*** Bug 461934 has been marked as a duplicate of this bug. ***
It would seem that this traceback is still showing up in rawhide. We would love it if anybody could come up with a reliable way to reproduce this.
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle. Changing version to '10'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
*** Bug 497226 has been marked as a duplicate of this bug. ***
I seem to be able to reproduce it in all of my installs, not sure how.
Without a reproducer, there's nothing we can do. We've never been able to reliably reproduce this thing enough to get a handle on tracking it down.
Created attachment 343952 [details] anaconda-traceback.png I reproduced this today, during an upgrade from an F10 i686 livecd-installed image (plus all updates) to rawhide, using preupgrade. When it failed, I was trying to press Right ALT+CTRL to get the mouse back from KVM, though I may have accidentally pressed a different key nearby that.
*** Bug 502020 has been marked as a duplicate of this bug. ***
That reproducer doesn't work for me.
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle. Changing version to '11'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
I've just had this problem occur while attempting to update a Fedora 10 system (fully up to date) to Fedora 11 using preupgrade. The error was the same a lack of module keysyms. Unfortunately, I was unable to save the complete traceback as choosing the save option resulted in anaconda freezing while trying to detect storage devices (possibly a separate issue). The problem occurred when the update was about 10% complete. After a reboot, the upgrade option is still present in the grub menu, but attempting to use it results in a message that the original install could not be found. The original install is still present in the boot menu. It boots an -fc10 kernel, but reports itself to be Fedora 11 once it reaches the login prompt. The machine is therefore in an indeterminate state somewhere between Fedora 10 and Fedora 11. Guess I'll be doing a clean install then.
same here , fully up-to-date F10 install, upgrading via preupgrade, system booted to anaconda and was installing glibc when anaconda died with this exception. trying to save traceback locked up anaconda. keysym.py _is_ in the python dir
more info: PIII 512M scsi disk
Created attachment 348330 [details] got attached anacdump.txt while upgrading using preupgrade was reading newspaper on the keyboard. so it was most likely i hit a key or two... now the system is between F10 and F11. I can boot into F10 but cannot use rpm. rpm --rebuilddb show db error.
Just got it yesterday night while upgrading from F9 to F11 using preupgrade. I did similar upgrades on other computers without problems. Unfortunately I was not able to save the traceback. Because of the size of the window showing the error and the poor CRT screen connected to this computer, I was not able to know the percentage of installation. (too bad the system did not offer a text only upgrade). I did a second try without more success. The RPM db is now broken (seems to have partially moved from db3 to db4 format), the login prompt shows 'fedora 11 (Leonidas)' but I have no means to know its exact state and I guess the only clean solution will be to perform a fresh install. The computer was first installed with FC1 about 6 years ago (then got FC3, FC5, F7, F9). It had a very minimal set of X11 features (at one time I was in need of space and tried to remove everything I could since X-windows was not needed on this machine for years). For instance 'startx' was non functional however preupgrade worked (I would love a tui preupgrade!). I did a 'yum -y update' before launching preupgrade and no problem was reported, F9 was stable and running for months. Some other strange things occurred while doing the upgrade, I don't know if there are related: first preupgrade warned that there was not enough room on /boot and the install image would have to be downloaded after the reboot (ok, that's usual). But using the Ethernet interface directly connected to our Internet access, the computer wanted to get its IP address from DHCP even if 'eth0' had "BOOTPROTO=static" set and correct definitions for IP, netmask, gateway, etc. So I had to set up some DHCP server... Then even with this, I had to alter the URL to be able to fetch the image since obviously the DHCP client was still not able to resolve 'ftp.lip6.fr' where it was trying to get the image. And once the image was downloaded, at some later point I got the 'keysym module' message.
Got the same error when upgrading from F10 to F11 after using preupgrade. I did not encounter problems on another machine with an almost identical set of installed packages. The machine with problems had a German keyboard with German language settings. After the initial traceback "ImportError: No module named keysyms" I tried to save it via the dialog that popped up. Save to local disk failed as it "could not read disk" (or something similar), I had no network connections set up at the time to try the other options. Then I selected "Diagnose error" (again the actual text may have been different, but similar) and got thrown back into text mode with another traceback. I attache a photo of the screen at this stage of the misbehavior. No further screen output was shown, but the disk was busy for another hour or two and finally automatically rebooted into a seemingly complete F11. After issuing # yum-complete-transaction # yum clean all which returned almost instantaneously, I could also install further packages and have not encountered any damage to the installation (yet). I will also attach the relevant anaconda log files.
Created attachment 350785 [details] Screen after the traceback, while the update was seemingly still working in the background
Created attachment 350787 [details] /root/upgrade.log
Created attachment 350789 [details] /root/upgrade.log.syslog
Created attachment 350790 [details] /tmp/anacdump.txt
This bug has been around for a while, and nobody has ever been able to provide a way to reproduce this bug - we ourselves have run into it a grand total of once (and it was just this week), and couldn't make it reappear. If anybody who has posted here (or who recreates this bug in the future) can provide a step by step method that will work to cause the bug every time on every machine, please please post it and reopen the report. But until then, I'm afraid I have to close this as CANTFIX.
As an addendum to my previous comment, even someone who can reliably reproduce it only on their own machine and is willing to work with us to figure out what the heck is going on is invited to reopen the bug. But all of these isolated, one-time reports... there's unfortunately nothing we can do.
I have been thinking about this a bit (really just uneducated guesses as I am not expert on the internals of anaconda and python gtk programming). From the reports above and my own experience, it seems that * it is unlikely that the error is triggered by a particular package * it seems that the installer loses one or all disk partitions, as the reported modules appear to be present and, moreover, save to disk of the error trace does not work (unless there is a separate bug in that part of the code) Could it be that handling certain types of disk IO errors is broken (e.g. tries to read from erroneous disk without clearing error condition first)? At least the incidence pattern of this error is sufficiently sparse and random to be attributable to hardware malfunction...
*** Bug 681191 has been marked as a duplicate of this bug. ***