Red Hat Bugzilla – Bug 465387
saving exception trace not working
Last modified: 2008-10-09 12:27:43 EDT
Description of problem:
Version-Release number of selected component (if applicable):
Every time (on my system, with the exception I'm seeing)
Steps to Reproduce:
1. Attempt to install f10beta
2. See an unhandled exception dialog pop up
3. Try to save with scp
Save does nothing
File transfers to designated system or an error is displayed
Smolt profile for this system is here:
Only about 30% of the screen is used and the mouse pointer is invisible which makes it more difficult to try to store the profile, but I've tried scp (after using asknetwork), bugzilla, local disk, and local storage. The local storage didn't have any options even though I had a USB disk connected. The local disk seemed to be volatile storage, not a disk partition.? scp and bugzilla did nothing... clicking ok doesn't give an error or an acknowledgement.
I think adding "nomodeset" as a boot parameter is supposed to fix the screen issue.
When it doesn't save, are there any messages on tty1 or tty3 indicating an additional exception? It's a little hard to display exceptions that happen in the top-level exception handler.
I didn't see any messages that looked related to not saving on tty1 or tty3.
The cancel button doesn't work either. It acts like it sees the click in that
the button shading changes, but there is no other sign that the click is seen.
Escape gets rid of the save menu (since cancel doesn't work), but the save
menu doesn't pop up again the next time save is clicked. I followed a similar
procedure on a different system for a different anaconda crash (the one at the
end of installation), and that time the save worked fine.
What kind of install are you doing? I wonder if this has anything to do with boot.iso and not being able to bring up the network.
A hard drive installation. I think I had the problem even when I used asknetwork
and I was able to ping the system from the system that I was trying to scp to.
I'll try to verify this tonight when I have access to the system.
Everything you said in comment #3 is a symptom of an exception happening in the bug saving UI - those are the exact things I see when I'm working on that code. I don't have any idea what else could be going on here. Could you please attach a picture or something of whatever's on tty1 for our own confirmation?
Created attachment 319818 [details]
requested picture of tty1
Okay I see what's going on here now. In the save exception dialog, one thing we do is probe the attached drives to see if any are valid to save to (for instance, are there any USB drives that might be a good place to save an exception?). In the process of doing that, we're hitting a very common HAL-related bug. Duping to that one. Thanks for the picture.
*** This bug has been marked as a duplicate of bug 442457 ***
Hmmm... I thought it was the HAL bug that caused the original exception for
which I was trying to save the trace. You're saying the same bug got me a
second time when I tried to save the trace?
Yes I do believe so.
Perhaps the probe for attached drives should be done only after the user selects something that would need attached drives. scp and bugzilla don't need
attached drives. If you want to ignore this suggestion and leave this closed
as a duplicate, that's fine... this is a weird corner case. Thanks for looking