Description of problem: Running the QA:Testcase_Anaconda_rescue_mode test on a PPC64 LPAR with the FC21 Alpha RC1 ISO image. I was able to reach the screen asking to scan the disks for existing installations. But selecting the "Continue" option raised the error. Content of the storage.log: =============================================================================== An unknown error has occurred =============================================================================== anaconda 21.48.8-1 exception report Traceback (most recent call first): tail: cannot open ‘/tmp/storage.log’ for reading: No such file or directory tail: ‘/tmp/storage.log’ has appeared; following end of new file 12:29:16,334 INFO blivet: ISCSID is /sbin/iscsid 12:29:16,334 INFO blivet: no initiator set 12:29:16,404 INFO blivet: Failed to read FCoE EDD info: No such file or directory 12:29:16,404 INFO blivet: no /etc/zfcp.conf; not configuring zfcp 12:29:16,486 DEBUG blivet: trying to set new default fstype to 'ext4' 12:29:16,512 DEBUG blivet: Ext4FS.supported: supported: True ; 12:29:16,512 DEBUG blivet: getFormat('ext4') returning Ext4FS instance with object id 0 12:29:16,513 DEBUG blivet: Ext4FS.supported: supported: True ; Content of the program.log: =============================================================================== An unknown error has occurred =============================================================================== anaconda 21.48.8-1 exception report Traceback (most recent call first): tail: cannot open ‘/tmp/program.log’ for reading: No such file or directory tail: ‘/tmp/program.log’ has appeared; following end of new file 12:29:16,131 INFO program: Running... udevadm trigger --action=change --subsystem-match=block 12:29:16,150 DEBUG program: Return code: 0 12:29:16,150 INFO program: Running... udevadm settle --timeout=300 12:29:16,333 DEBUG program: Return code: 0 12:29:16,334 INFO program: Running... modprobe fcoe 12:29:16,392 DEBUG program: Return code: 0 12:29:16,393 INFO program: Running... /usr/libexec/fcoe/fcoe_edd.sh -i 12:29:16,403 ERR program: Error running /usr/libexec/fcoe/fcoe_edd.sh: No such file or directory Version-Release number of selected component: anaconda-21.48.8-1 The following was filed automatically by anaconda: anaconda 21.48.8-1 exception report Traceback (most recent call first): File "/usr/lib64/python2.7/site-packages/snack.py", line 348, in run return self.trans[which] File "/usr/lib64/python2.7/site-packages/snack.py", line 693, in run return self.form.run() File "/usr/lib64/python2.7/site-packages/snack.py", line 673, in runOnce result = self.run(x, y) File "/usr/lib64/python2.7/site-packages/snack.py", line 833, in ButtonChoiceWindow return bb.buttonPressed(g.runOnce(x, y)) File "/usr/lib64/python2.7/site-packages/pyanaconda/rescue.py", line 299, in doRescue [_("Continue"), _("Read-Only"), _("Skip")] ) File "/sbin/anaconda", line 1310, in <module> rescue.doRescue(anaconda.intf, anaconda.rescue_mount, ksdata) KeyError: 639884848 Additional info: addons: com_redhat_kdump cmdline: /usr/bin/python /sbin/anaconda cmdline_file: BOOT_IMAGE=/ppc/ppc64/vmlinuz rescue ro executable: /sbin/anaconda hashmarkername: anaconda kernel: 3.17.0-300.fc21.ppc64 product: Fedora" release: Cannot get release name. type: anaconda version: Fedora
Created attachment 945588 [details] File: anaconda-tb
Created attachment 945589 [details] File: anaconda.log
Created attachment 945590 [details] File: environ
Created attachment 945591 [details] File: lsblk_output
Created attachment 945592 [details] File: nmcli_dev_list
Created attachment 945593 [details] File: os_info
Created attachment 945594 [details] File: program.log
Created attachment 945595 [details] File: storage.log
Created attachment 945596 [details] File: syslog
*** Bug 1152014 has been marked as a duplicate of this bug. ***
I tried to reproduce it by cutting down the rescue.py code, but it seems to work. Is there a standalone reproducer for this? Is the anaconda rescue code called only on ppc64 or the newt code only fails on ppc64?
It seems there is an unhandled return code from newtFormRun(). It's NEWT_FORM_EXIT_ERROR, which means that read() called on stdin in SLang_getkey() returned 0 (EOF) or EIO. I can fix the snack code to raise a different exception in this case, but the underlying problem seems to be somewhere else.
I hit a similar traceback trying same QA:Testcase_Anaconda_rescue_mode test but for ppc64 kvm guest with fc21 Alpha RC2 http://ppc.koji.fedoraproject.org/stage/f21_Alpha_RC2/
Proposing as a BetaBlocker: The rescue mode of the installer must start successfully and be able to detect and mount any installation performed according to the applicable criteria, and provide a shell with access to utilities capable of performing typical recovery operations.
Reassigning back to anaconda, without stdin there is not much newt or slang can do.
Has it yet been confirmed that this affects a primary arch? Bugs in PPC cannot block the primary release.
So far it has been reproduced on ppc64 (Big Endian) only.
(In reply to Miroslav Lichvar from comment #15) > Reassigning back to anaconda, without stdin there is not much newt or slang > can do. 1) anaconda isn't getting an IOError, or anything even resembling it. It's getting a KeyError with a key of what I assume is uninitialized data, because something isn't handling an error return somewhere. 2) stdin is working fine before newt+slang get a hold of it. After the newt window has been displayed, if I exit the process then I get "_pSLsys_getkey: EIO error" on the console whenever I hit a key. So I would say there probably are some things that newt or slang could do.
(In reply to David Shea from comment #18) > 1) anaconda isn't getting an IOError, or anything even resembling it. It's > getting a KeyError with a key of what I assume is uninitialized data, > because something isn't handling an error return somewhere. Yes and that was fixed in newt git, but it's not related to the problem discussed here. When newt is updated in Fedora, it will be a RuntimeError instead of KeyError. > 2) stdin is working fine before newt+slang get a hold of it. After the newt > window has been displayed, if I exit the process then I get "_pSLsys_getkey: > EIO error" on the console whenever I hit a key. How many slang applications are running there and how are they started? Is there anything ppc specific? > So I would say there probably are some things that newt or slang could do. Well, I don't see how is this related to newt/slang or what they should do to recover from it. Suggestions are welcome.
The following will reproduce the problem after installation on a ppc64 machine. If you go to #fedora-ppc we can get you access to a machine for debugging. [root@ppc64lehamzytest2 ~]# (cat << '__EOF__' | python -; stty sane) #!/usr/bin/env python # Based on https://github.com/dougsland/python-snack-by-examples/blob/master/entryWindow.py import snack screen = snack.SnackScreen() ret = snack.EntryWindow(screen, 'Title', 'test', ['value']) screen.finish() status = ret[0] values = ret[1] # OK or Cancel print "Pressed %s" % (status) # Print every single item for item in values: print item __EOF__ Traceback (most recent call last): File "test6.py", line 5, in <module> ret = snack.EntryWindow(screen, 'Title', 'test', ['value']) File "/usr/lib64/python2.7/site-packages/snack.py", line 871, in EntryWindow result = g.runOnce() File "/usr/lib64/python2.7/site-packages/snack.py", line 673, in runOnce result = self.run(x, y) File "/usr/lib64/python2.7/site-packages/snack.py", line 693, in run return self.form.run() File "/usr/lib64/python2 return self.trans[which] KeyError: 946631456 Also, I've tried the C version at http://www.opensourceforu.com/2011/11/spicing-up-console-for-fun-profit-2/ with no problems. So maybe it is a python issue? Although I do not think that is a license to automatically transfer it without further investigation.
I reproduced the problem trying peanuts.py code on a f20 ppc64. No problem with: python.ppc64p7 0:2.7.5-9.fc20 and newt-python-0.52.16-1.fc20.ppc64.rpm No problem if a update python to python.ppc64p7 0:2.7.5-13.fc20 But problem is triggered when a update newt with: newt-0.52.16-2.fc20.ppc64.rpm newt-python-0.52.16-2.fc20.ppc64.rpm It seems to me that the "widget.w.key" value is not correct in code class Form: ... def add(self, widget): ... elif 'w' in widget.__dict__: self.trans[widget.w.key] = widget return self.w.add(widget.w) widget.w.key value is 256 and it not looks like a the value expected given thru KeyError.
It seems that removing git change "add python3 support (#963839)" ba3eb78a2c8536ff01150a6c4b75ca0d777cf549 make the problem disappear.
(In reply to Menanteau Guy from comment #22) > It seems that removing git change "add python3 support (#963839)" > ba3eb78a2c8536ff01150a6c4b75ca0d777cf549 > make the problem disappear. That's interesting. Can you please run the reproducer in strace with and without this commit and attach the logs?
Created attachment 949387 [details] traces when problem occurs note that I am now on a f21 ppc64 machine with python.ppc64 2.7.8-4.2.fc21 python3.ppc64p7 3.4.1-15.fc21 and based on newt.ppc64 0.52.17-4.fc21
Created attachment 949389 [details] traces when no problem I applied changes relative to "add python3 support (#963839)" on snack.c manually.
(In reply to Menanteau Guy from comment #25) > Created attachment 949389 [details] > traces when no problem > > I applied changes relative to "add python3 support (#963839)" > on snack.c manually. please, replace "applied" by "removed", correct sentence is: I removed changes relative to "add python3 support (#963839)" in snack.c manually.
(In reply to Menanteau Guy from comment #24) > Created attachment 949387 [details] (In reply to Menanteau Guy from comment #25) > Created attachment 949389 [details] Hm, these don't look like strace output. Can you please run it as "strace -o log ./reproducer"?
Created attachment 949395 [details] traces when problem occurs sorry, should be better now...
Created attachment 949396 [details] traces when no problem
It turned out there are two bugs that result in the KeyError exception. One is the missing case for the EIO/EOF error and the other is a collision/mismatch in the widget keys on 64-bit systems, which is very easy to hit on big-endian archs (e.g. ppc64). I'll make an f21 update shortly.
newt-0.52.18-1.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/newt-0.52.18-1.fc21
Package newt-0.52.18-1.fc21: * should fix your issue, * was pushed to the Fedora 21 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing newt-0.52.18-1.fc21' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-13543/newt-0.52.18-1.fc21 then log in and leave karma (feedback).
newt-0.52.18-1.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.