Bug 465387

Summary: saving exception trace not working
Product: [Fedora] Fedora Reporter: David <idht4n>
Component: anacondaAssignee: Anaconda Maintenance Team <anaconda-maint-list>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: medium    
Version: rawhideCC: anaconda-maint-list, dcantrell
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-10-09 14:18:13 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
requested picture of tty1 none

Description David 2008-10-03 02:03:36 UTC
Description of problem:


Version-Release number of selected component (if applicable):


How reproducible:
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
  
Actual results:
Save does nothing

Expected results:
File transfers to designated system or an error is displayed

Additional info:

Comment 1 David 2008-10-03 02:56:20 UTC
Smolt profile for this system is here:
http://www.smolts.org/client/show/pub_abb6f79f-3059-43f7-93be-2c2df82d7e16

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.

Comment 2 Chris Lumens 2008-10-03 15:39:37 UTC
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.

Comment 3 David 2008-10-06 23:43:23 UTC
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.

Comment 4 Chris Lumens 2008-10-07 15:57:22 UTC
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.

Comment 5 David 2008-10-07 16:20:13 UTC
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.

Comment 6 Chris Lumens 2008-10-08 21:35:27 UTC
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?

Comment 7 David 2008-10-09 01:36:01 UTC
Created attachment 319818 [details]
requested picture of tty1

Comment 8 Chris Lumens 2008-10-09 14:18:13 UTC
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 ***

Comment 9 David 2008-10-09 15:42:29 UTC
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?

Comment 10 Chris Lumens 2008-10-09 15:54:30 UTC
Yes I do believe so.

Comment 11 David 2008-10-09 16:27:43 UTC
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
into it.