On Wed, Feb 23, 2011 at 12:00 PM, James Laska <jlaska@xxxxxxxxxx> 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 -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
