Description of problem: when an unhandled exception has occurred,save the log and click "exit installer"system can not automatically reboot, system hangs up there.this happened on f12 beta TC Version-Release number of selected component (if applicable): anaconda 12.29 How reproducible: 100% Steps to Reproduce:
Created attachment 362653 [details] text mode text mode has the same issue.when we save the anaconda to local disk,press "exit installer", system hangs up there, can not reboot,keyboard does not work, see attached picture.
Liam can you please switch to tty2 (CTRL+ALT+F2) before choosing reboot system, and copy /tmp/storage.log /tmp/anaconda.log /tmp/program.log /tmp/syslog to another machine and attach them here? (you can use scp) Also is this machine special in anyway for example is it using BIOS RAID, and if it is, does this happen to be Intel BIOS RAID ?
Created attachment 363132 [details] /tmp I tar the /tmp, take any one you want :)
I get the same problem, using live cd rawhide 20091001.15.i386 Also is bug 526789 a dupe of this bug? Smolt: http://www.smolts.org/client/show/pub_a06b74a6-bd35-4178-87e7-ca58c6c533b4
Created attachment 363589 [details] anaconda.log
Created attachment 363590 [details] program.log
Created attachment 363591 [details] storage.log
I can confirm this bug is still present as of anaconda-12.39-1 (nightly 20091024.19 x86_64) If this can't be fixed for the F12, maybe the label on the button should be something other than reboot?
Thanks for the feedback Robert, this issue was the results of a failure to reboot the system after an exception occurred. The issue you described does indeed sound more like the issue posted to bug#526789
Liam, I believe this issue is the same as bug#531924. That bug involved reverting a patch which appears to affect proper shutdown of the live image. Can you confirm whether a live image built against the latest rawhide (as of 2009-11-03) corrects this issue? The procedure for creating a live image is documented at https://fedoraproject.org/wiki/QA/Test_Days/Live_Image.
This bug happened when unhandled exception occurred.I have no idea how to reproduce a unhandle exception during install on rawhide(11-03) right now,because almost all known bugs are fixed. I only clicked exit installer during install,system successfully rebooted. I also checked bug#531924 on 11-03 livdCD, issue fixed
I think I see your issue now Liam. Basically, just force a traceback and click "Exit" on the exception dialog. When testing with rawhide (anaconda-12.43) and clicking "Exit installer" on the exception dialog, on tty1 I see the following. Note, the shell on tty1 is still active. 15:27:20 Starting graphical installation. XKB extension not present on :1 XKB extension not present on :1 install exited abnormally [1/1] you may safely reboot your system When testing this on F-11-GOLD, I see the following behavior when clicking "Exit installer" on the exception dialog. 16:18:28 Starting graphical installation... XKB extension not present on :1 XKB extension not present on :1 install exited abnormally [1/1] disabling swap... unmounting filesystems... /mnt/runtime done disabling /dev/loop0 LOOP_CLR_FD failed: 16 /proc done /dev/pts done /sys done /selinux done sending termination signals...done sending kill signals...done you may safely reboot your system So this is certainly a change in behavior, but I'm not sure it represents a blocker issue as the end result of both tests (rawhide and F-11) is the same. The system is ready for a reboot and doesn't automatically reboot. I've documented how to force a traceback in the following test case https://fedoraproject.org/wiki/QA:Testcases_Anaconda_save_traceback_to_bugzilla Liam: Can you confirm this is the behaviour you were tracking with this bug report. Chris: Thinking this might be related to python-meh, are there any changes here that may have changed the behavior in F-12?
Created attachment 367591 [details] logs of anaconda 12.43 yes, it exactly is the issue I got. on tty3, I can see the following output: NameError: name 'TRACEBACKPLEASE' is not defined This can be reproduce on anaconda 12.43 with jlaska's method, again I will attached the logs
*** Bug 533123 has been marked as a duplicate of this bug. ***
*** Bug 532607 has been marked as a duplicate of this bug. ***
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle. Changing version to '12'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
*** Bug 538605 has been marked as a duplicate of this bug. ***
Ales - I believe you have fixed this one via a combination of your other shutdown work and the fix for bug 569071, so I'm going to reassign it to you and put it in MODIFIED. Since 569071 is proposed as a blocker, this should be taken care of for F13 once approved.
I'd be in favor of fixing this, as the issue is still present in F-13
I can see this issue on F13 beta too
Liam, can you please describe what happens? I tried reproducing this with anaconda-13.36 and after clicking 'exit' in the GUI exception handler, the terminal is switched to tty1 and the information about abnormal exit is printed. then there's a line saying that the system can be rebooted by pressing ctrl-c or c-a-d, which it does. Note that this is the expected behavior, Ales
james, liam, what is the status here? -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
The reported problem remains when testing F-13-Final-TC1 The test case to reproduce the problem is http://fedoraproject.org/wiki/QA:Testcase_Anaconda_save_traceback_to_bugzilla Run the steps in either text-mode, or a graphical install. After reporting the anaconda exception, the installer reports on tty1 ... install exited abnormally [1/1] QA is accustomed to seeing the above string whenever loader has a failure. I believe what needs to happen here is we can either confirm that the above string is now expected *whenever* an anaconda failure occurs, whether it is caught or not. Or, modify anaconda such that the string only displays during an unhandled loader failure (e.g. SIGSEGV).
James, Adam, what we are seeing now is what I believed was the intended behavior, i.e. any exception occurs->terminate abnormally so there is another chance to take a look at the output in the terminal. It would be a oneliner to make the *handled* exceptions cause normal reboot (which might not be a bad idea). Should I do that? Ales
This doesn't seem like a blocker to me, as described. You can report the failure and then safely quit the installer. What criterion is broken? -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Adam, I don't think this should make F13 either. I'm just asking whether is this something I should fix for rawhide/F14. Ales
okay, let's drop it from blocker list then.
This message is a reminder that Fedora 13 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 13. 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 '13'. 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 13'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 13 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 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 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.