Bug 245691 - anaconda bails out from an upgrade with a "No module named keysyms" traceback
anaconda bails out from an upgrade with a "No module named keysyms" traceback
Status: CLOSED CANTFIX
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
11
All Linux
low Severity low
: ---
: ---
Assigned To: Anaconda Maintenance Team
Fedora Extras Quality Assurance
: Reopened
: 461934 497226 502020 681191 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-06-25 23:15 EDT by Michal Jaegermann
Modified: 2013-01-09 23:21 EST (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-07-09 15:35:08 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
anaconda log from an attempted upgrade (15.87 KB, text/plain)
2007-06-25 23:15 EDT, Michal Jaegermann
no flags Details
anacdump.txt (29.93 KB, text/plain)
2007-07-07 09:01 EDT, peterschueller
no flags Details
anaconda-traceback.png (11.20 KB, image/png)
2009-05-14 08:13 EDT, Matt Domsch
no flags Details
got attached anacdump.txt while upgrading using preupgrade (5.77 KB, text/plain)
2009-06-17 15:29 EDT, Need Real Name
no flags Details
Screen after the traceback, while the update was seemingly still working in the background (122.71 KB, image/jpeg)
2009-07-07 08:50 EDT, oliver
no flags Details
/root/upgrade.log (71.04 KB, application/octet-stream)
2009-07-07 08:56 EDT, oliver
no flags Details
/root/upgrade.log.syslog (1.99 KB, application/octet-stream)
2009-07-07 08:58 EDT, oliver
no flags Details
/tmp/anacdump.txt (5.62 KB, text/plain)
2009-07-07 08:59 EDT, oliver
no flags Details

  None (edit)
Description Michal Jaegermann 2007-06-25 23:15:43 EDT
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.
Comment 1 Michal Jaegermann 2007-06-25 23:15:43 EDT
Created attachment 157847 [details]
anaconda log from an attempted upgrade
Comment 2 peterschueller 2007-07-07 09:01:41 EDT
Created attachment 158716 [details]
anacdump.txt
Comment 3 peterschueller 2007-07-07 09:07:08 EDT
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).
Comment 4 peterschueller 2007-07-08 12:34:18 EDT
After starting the upgrade again all remaining 581 packages where installed 
without error messages.
Comment 5 Michal Jaegermann 2007-07-08 14:22:13 EDT
> ... 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. 
Comment 6 Chris Lumens 2008-04-22 10:56:45 EDT
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.
Comment 7 Andy Lindeberg 2008-09-11 16:16:35 EDT
*** Bug 461934 has been marked as a duplicate of this bug. ***
Comment 8 Andy Lindeberg 2008-09-11 16:18:54 EDT
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.
Comment 9 Bug Zapper 2008-11-25 20:55:55 EST
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
Comment 10 Chris Lumens 2009-04-22 17:26:01 EDT
*** Bug 497226 has been marked as a duplicate of this bug. ***
Comment 11 Jesse Keating 2009-04-23 16:20:58 EDT
I seem to be able to reproduce it in all of my installs, not sure how.
Comment 12 Chris Lumens 2009-04-28 13:23:17 EDT
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.
Comment 13 Matt Domsch 2009-05-14 08:13:12 EDT
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.
Comment 14 Chris Lumens 2009-05-21 16:45:41 EDT
*** Bug 502020 has been marked as a duplicate of this bug. ***
Comment 15 Chris Lumens 2009-05-27 16:35:24 EDT
That reproducer doesn't work for me.
Comment 16 Bug Zapper 2009-06-09 05:15:48 EDT
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
Comment 17 Paul Milliken 2009-06-11 19:37:45 EDT
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.
Comment 18 david avery 2009-06-13 00:28:53 EDT
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
Comment 19 david avery 2009-06-13 00:36:12 EDT
more info:

PIII
512M
scsi disk
Comment 20 Need Real Name 2009-06-17 15:29:15 EDT
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.
Comment 21 Bernard Fouché 2009-06-22 09:34:43 EDT
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.
Comment 22 oliver 2009-07-07 08:47:07 EDT
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.
Comment 23 oliver 2009-07-07 08:50:46 EDT
Created attachment 350785 [details]
Screen after the traceback, while the update was seemingly still working in the background
Comment 24 oliver 2009-07-07 08:56:33 EDT
Created attachment 350787 [details]
/root/upgrade.log
Comment 25 oliver 2009-07-07 08:58:01 EDT
Created attachment 350789 [details]
/root/upgrade.log.syslog
Comment 26 oliver 2009-07-07 08:59:59 EDT
Created attachment 350790 [details]
/tmp/anacdump.txt
Comment 27 Andy Lindeberg 2009-07-09 15:35:08 EDT
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.
Comment 28 Andy Lindeberg 2009-07-09 15:37:09 EDT
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.
Comment 29 oliver 2009-07-10 06:21:33 EDT
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...
Comment 30 Chris Lumens 2011-03-01 09:38:27 EST
*** Bug 681191 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.