Running abrt-cli in live isos for graphics test days?

[mike cloaked]

On Wed, Feb 23, 2011 at 12:00 PM, James Laska <jlaska at redhat.com> wrote:
> On Tue, 2011-02-22 at 20:18 +0000, mike cloaked wrote:
>> I am trying to get a backtrace or abrt report from a laptop which
>> cannot get to the gnome3 desktop due to bz 677842.
>>
>> I am able to use yum to install packages into the running live system
>> - and I can install abrt-cli - and I can get a list of crashes using
>> abrt-cli -l
>>
>> However when I run abrt-cli -r xxx where xxx are the first few
>> characters of the uuid it wants to download 94 debug files - is there
>> any way I can get a shorter way to a crash report from abrt-cli?
>
> I had this trouble also when attempting to report a crash using abrt-cli
> from the console.  The abrt-cli manpage suggests ...
>
>                -r, --report CRASH_ID   create and send a report
>        ...
>        CRASH_ID can be:
>                UID:UUID pair,
>                unique UUID prefix  - the crash with matching UUID will be acted upon
>                @N  - N'th crash (as displayed by --list --full) will be acted upon
>
> If I'm understanding the problem you noted, it seems like a valid bug if
> you enter the first 6 unique characters of a crash UUID, and it doesn't
> locate the matching crash.  Is that the behavior you were seeing?  It
> wasn't allowing you to report a crashing when attempting the documented
> short-hand notation for specifying a CRASH_ID?

The abrt-cli process seemed to start OK and essentially I was already
following the process you described above (provided the characters
from the crash uuid are unique out of the sets of crash uuid's listed
from "abrt-cli -l" then it works), but possibly because it is running
in a live system with limited or no write access to the live media
(usbkey) which seems to have been mounted read-only when it boots up,
I am guessing that the only memory it has access to is the RAM - and
at some point it fills up and again I am guessing but maybe at that
point with no more memory the kernel panics and the system grinds to a
halt. If there is a way to boot the key but still have write access to
the directories which are untouched when the liveusb was originally
written this would certainly help.

It may be possible to try to run the live iso but mount a partition on
the HD (not normally mounted when running the live iso), and then link
it from /var/cache or /var/spool in some way that will give sufficient
memory so that abrt can pull in all the files it needs to a directory
on the key (rather than RAM), and then analyse the coredump to create
a backtrace - but I have not had time to explore that route - the test
systems I am using have f14 installed and are in normal daily use -
but since it had the graphics hardware needed for the (radeon and
nouveau) graphics test day the easiest way to retain it as a working
system as well as run the test day system, was to use a live iso (and
written to a usbkey as a bootable live usbkey)

If you have any thoughts on this I would value any input which may
allow me to get the vital backtraces with all the debug stuff that
developers would need to get at the real underlying cause of the
gnome3 problems that are currently being investigated.
-- 
mike c