Bug 465387 - saving exception trace not working
saving exception trace not working
Status: CLOSED DUPLICATE of bug 442457
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
All Linux
medium Severity low
: ---
: ---
Assigned To: Anaconda Maintenance Team
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2008-10-02 22:03 EDT by David
Modified: 2008-10-09 12:27 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-10-09 10:18:13 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
requested picture of tty1 (176.58 KB, image/jpeg)
2008-10-08 21:36 EDT, David
no flags Details

  None (edit)
Description David 2008-10-02 22:03:36 EDT
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-02 22:56:20 EDT
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.
Comment 2 Chris Lumens 2008-10-03 11:39:37 EDT
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 19:43:23 EDT
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 11:57:22 EDT
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 12:20:13 EDT
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 17:35:27 EDT
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-08 21:36:01 EDT
Created attachment 319818 [details]
requested picture of tty1
Comment 8 Chris Lumens 2008-10-09 10:18:13 EDT
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 11:42:29 EDT
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 11:54:30 EDT
Yes I do believe so.
Comment 11 David 2008-10-09 12:27:43 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.