Red Hat Bugzilla – Bug 493271
need more than 0 values to unpack
Last modified: 2010-06-28 07:37:21 EDT
The following was filed automatically by anaconda: anaconda 11.5.0.38 exception report Traceback (most recent call first): File "/usr/lib64/python2.6/site-packages/rhpl/executil.py", line 93, in execWithRedirect except OSError, (errno, msg): File "/usr/lib64/python2.6/site-packages/rhpl/keyboard.py", line 129, in activate executil.execWithRedirect(argv[0], argv) File "/usr/lib/anaconda/textw/keyboard_text.py", line 59, in __call__ anaconda.id.keyboard.activate() File "/usr/lib/anaconda/text.py", line 674, in run rc = win(self.screen, instance) File "/usr/bin/anaconda", line 1029, in <module> anaconda.intf.run(anaconda) ValueError: need more than 0 values to unpack
Created attachment 337466 [details] Attached traceback automatically from anaconda.
host system Intel E6750 6GB DDR800 Asus striker extreme - nvidia 680i chipset 2x WD 74GB raptors fakeraid0 2x seagate 750GB fakeJBOD 2x MSI 8800GT GFX method: 1. boot from verified x86_64 beta dvd media <X can not start as it doesn't recognise either gfx card - I tried both gfx install options> 2. text mode prompts for language and keyboard selection <anaconda crash>
Can you think of anything unusual that happened during the install process? I've seen this bug come up a couple times, but I have never been able to reproduce it and there's very little helpful in anyone's tracebacks. The only thing I saw of any interest in yours was this: 18:51:00 ERROR : closetray failed on device /dev/sr0: Input/output error
ok, i did some elimination and the results are as follows on my nvidia sli system: dual gfx: * selecting either std gfx install or vesa boot option: # x can not start with either neuvo or vesa driver (see attached xlogs.tgz) # anaconda falls back to text mode and crashes after KB selection single gfx: * selecting either std gfx install or vesa boot option: # x starts with either vesa or neuvo and i can get past KB selection and accepting the beta warning (for the crash that happens after beta selection please see #493293) comparing the text mode to gfx mode the text mode seems to crash where the gfx mode is prompting with the beta warning... how can i force the installation to start in text mode? none of the F{1,2,3,4} help screens document how to do this, only how to manually enable the vesa option which is one of the standard boot options anyway..
Created attachment 337668 [details] TGZ of /tmp/*
Phil: Text mode can be enabled by typing "text" at the end of the line after hitting [TAB]. I have the same issue on my Intel D945GCLF2 board. Text mode installs properly, but I do not get any TTYs to login to, nor do I get any kind of output. Plymouth boot splash screen stays up as well. Is this an upstart problem?
Ok, the issue of anaconda crashing was caused by the pyblock issue #489148. So the real issue here is no longer with anaconda but with X and the Neuvo driver not recognising or being able to handle an nVidia SLI setup properly. hopefully i can successfully change this bug to the correct component :p
*** Bug 494156 has been marked as a duplicate of this bug. ***
*** Bug 494636 has been marked as a duplicate of this bug. ***
*** Bug 495160 has been marked as a duplicate of this bug. ***
I've pushed a potential fix to rhpl for this issue, though I'm not very optimistic. I've never been able to reproduce this bug so it's impossible for me to tell whether my change actually fixes anything.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
*** Bug 496503 has been marked as a duplicate of this bug. ***
This is still broken in Fedora 11 Preview
Created attachment 341644 [details] Traceback from Anaconda
(In reply to comment #14) > This is still broken in Fedora 11 Preview Seva -- the traceback you're seeing is in a different place (although it's the same syntactically). And Chris has pushed a fix to change the way we catch OSError throughout anaconda since the anaconda build in the preview release
If I'm reading all of this right, it seems like these crashes happen after X falls back to text mode. It continues normally until an anaconda subprocess finishes - e.g. /usr/bin/loadkeys - and then traces back with an OSError. That would be consistent with the SIGCHLD handler problem mentioned in bug 497388, which should be fixed in the next build of anaconda (git show fc643049). The traceback in comment #15 seems to be from a Live image, which would be a completely different problem.
Chris Lumens pointed me to this bug in #fedora-qa, I boot from a Live CD x86_64 (including Beta, Snapshot1, and Preview), X fails to start, I login as root on console and type either anaconda or liveinst and get the above traceback.
Please see my traceback from bug number 496503. I have had this a few times when trying to install from both the netinst and CD1 of the x86-64 edition. From what I can see, anaconda is failing to start X and then, after the "This is a preview release" warning, anaconda crashes. I understand that there may be a newer anaconda version than that on the Preview release, so I'll try a net install. It may be useful if we had a look at the hardware that this is failing on. There seems to be a connection between the nVidia cards and anaconda failing, from what I can see. My setup is a Q6600, GA-X38-DS5 mobo, 8GB RAM and an nVidia 8800 GTS graphics card. Does it look like there is any common hardware problems? Andy
Bug #494636 (marked "same as bug #493271" [this one]) is on Apple Macintosh mini PowerPC which has Radeon 9200, which is definitely not an nVidea chip.
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
This issue appears to be fixed in rawhide 12 but there are some side effects. With my sli setup when the power turns on both gfx fans spin at 100% making a whooole lot of noise. When the BIOS initialises the video device the first card's fan idle's but the second stays at 100%. Once the nvidia driver/firmware is loaded the second card settles to idle, this behaviour survives warm reboots but not cold. but this is all normal. The bug is when I do a warm reboot in to the fedora 12a installation over pxe the second fan spins back up to 100%... This does not impact the installation adversely and only lasts until you can get to the desktop and install the binary driver, which for a giglan install isn't too much more than 10 to 15 minutes :D.
This message is a reminder that Fedora 11 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 11. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '11'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 11's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 11 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 11 changed to end-of-life (EOL) status on 2010-06-25. Fedora 11 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.