Bug 568814 - live install exceptions include /tmp/syslog, but /var/log/dmesg should be used instead
Summary: live install exceptions include /tmp/syslog, but /var/log/dmesg should be use...
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 13
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Chris Lumens
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-02-26 17:04 UTC by Steve Tyler
Modified: 2010-03-01 22:06 UTC (History)
3 users (show)

Fixed In Version: anaconda-13.33-1
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-03-01 22:06:39 UTC


Attachments (Terms of Use)

Description Steve Tyler 2010-02-26 17:04:34 UTC
While testing installation from a live ISO on a USB stick, disk partitioning failed (Bug 568556), and I was presented with a confusing message about there being a possible bug, a text box with a python backtrace, and instructions to save this info. Since I was booted off a USB stick, there was no place to save it outside of ram disk.

What I had to do was mount a hard drive -- but the hard drive partition that I wanted to mount had been partially corrupted by the failed partitioning, so it could not be mounted! So first I had to format the drive with the gnome-disk-utility, mount it, copy the failure report, reboot, file a bugzilla report.

After all that trouble, I was asked to upload a specific log file (/tmp/syslog), because whatever was in the failure report was insufficient. I declined, because this test installation was to the same drive as a working F11 installation that I did not want to risk trashing.

In a possibly related report (Bug 568460), the reporter attached a zip file (Attachment 396358 [details]) containing a number of log files. The reporter did not include /tmp/syslog, however.

Obviously, most users should not be asked to do all this. Anaconda should do it automatically. Fedora ships with the Automatic Bug Reporting Tool (ABRT) which is specifically designed to automatically report bugs and and file reports in bugzilla. Since anaconda is running with a kernel, networking, and, at later stages, a graphical UI, it should be possible to use ABRT. Further, it should be possible to systematically collect all needed log files into the report (while respecting user privacy and security). ABRT also gives users the option to decline to send a report. One drawback I have noticed is that ABRT requires users to be registered with bugzilla.

http://fedoraproject.org/wiki/Features/ABRT

Comment 1 James Laska 2010-02-26 17:28:32 UTC
Greetings Steve.  Thanks for the bug report, you have a lot of information on different topics in this one report.  

(In reply to comment #0)
> While testing installation from a live ISO on a USB stick, disk partitioning
> failed (Bug 568556), and I was presented with a confusing message about there
> being a possible bug, a text box with a python backtrace, and instructions to
> save this info. Since I was booted off a USB stick, there was no place to save
> it outside of ram disk.

Got a screenshot of the confusing dialog?  

Please note, ever since Fedora 10, anaconda has had support for reporting failures directly into bugzilla (see https://fedoraproject.org/wiki/Anaconda/Features/SaveToBugzilla).

> What I had to do was mount a hard drive -- but the hard drive partition that I
> wanted to mount had been partially corrupted by the failed partitioning, so it
> could not be mounted! So first I had to format the drive with the
> gnome-disk-utility, mount it, copy the failure report, reboot, file a bugzilla
> report.
> 
> After all that trouble, I was asked to upload a specific log file
> (/tmp/syslog), because whatever was in the failure report was insufficient. I
> declined, because this test installation was to the same drive as a working F11
> installation that I did not want to risk trashing.

Sometimes a bug report doesn't always introduce a crash or traceback.  I was asked to provide a log file in bug#568460 because the nature of the bug was not a crash.  It was unexpected output in the user interface.  So that's not too unusual of a request.

> In a possibly related report (Bug 568460), the reporter attached a zip file
> (Attachment 396358 [details]) containing a number of log files. The reporter did not
> include /tmp/syslog, however.

When using anaconda in a live image, /var/log/dmesg provides the same information that /tmp/syslog from a normal install offers.  Those files are included in bug#568460 (attachment#396358 [details]).

If i look at the attachment provided in your dump file from bug#568556, it includes the following log files if available:

  mehConfig.fileList: [/tmp/syslog, /tmp/anaconda.log, /tmp/lvmout, /tmp/resize.out, /tmp/program.log, /tmp/storage.log, /tmp/yum.log, /mnt/sysimage/root/install.log, /mnt/sysimage/root/upgrade.log, /proc/cmdline]

However, since running the installer in a live environment doesn't use /tmp/syslog, I wonder if python-meh should be changed to include /var/log/messages and /var/log/dmesg?

> Obviously, most users should not be asked to do all this. Anaconda should do it automatically. Fedora ships with the Automatic Bug Reporting Tool (ABRT) which
> is specifically designed to automatically report bugs and and file reports in
> bugzilla. Since anaconda is running with a kernel, networking, and, at later
> stages, a graphical UI, it should be possible to use ABRT. Further, it should
> be possible to systematically collect all needed log files into the report
> (while respecting user privacy and security).

A great idea, unfortunately ABRT cannot be used for automated installer bug reporting in all cases.  You're welcome to explore options in this space.  However, bugzilla is not the best forum for gaining traction on those ideas.  Please use the anaconda-devel mailing list or fedoraproject wiki for additional communication on that topic.  For additional information on automated bug filing during the install process, please see the old feature proposal at  https://fedoraproject.org/wiki/Anaconda/Features/SaveToBugzilla.

Let's use this bug report to track the specific issue that the reported dumpfile from the live installer should include /var/log/messages and /var/log/dmesg (in addition to the existing list of files included in automated bug reports).

Comment 2 Steve Tyler 2010-02-26 19:02:17 UTC
(In reply to comment #1)

Thanks for your informative comments, James.

> Got a screenshot of the confusing dialog?  

Thanks for asking. No. I was all set to get a screenshot, but I clicked the "Save" button in the dialog first. The dialog was replaced by another message, and there was no way to go back. I don't remember a thing about that message, because I was getting very annoyed ... :-)

> Please note, ever since Fedora 10, anaconda has had support for reporting
> failures directly into bugzilla (see
> https://fedoraproject.org/wiki/Anaconda/Features/SaveToBugzilla).

That looks like a nice feature.
Why wasn't I prompted to send a bug report?
(I'm familiar with ABRT by now, though ...)

> Sometimes a bug report doesn't always introduce a crash or traceback.  I was
> asked to provide a log file in bug#568460 because the nature of the bug was not
> a crash.  It was unexpected output in the user interface.  So that's not too
> unusual of a request.

OK. I was wondering why you attached those log files.

> When using anaconda in a live image, /var/log/dmesg provides the same
> information that /tmp/syslog from a normal install offers.  Those files are
> included in bug#568460 (attachment#396358 [details]).
>
> If i look at the attachment provided in your dump file from bug#568556, it
> includes the following log files if available:
> 
>   mehConfig.fileList: [/tmp/syslog, /tmp/anaconda.log, /tmp/lvmout,
> /tmp/resize.out, /tmp/program.log, /tmp/storage.log, /tmp/yum.log,
> /mnt/sysimage/root/install.log, /mnt/sysimage/root/upgrade.log, /proc/cmdline]
> 
> However, since running the installer in a live environment doesn't use
> /tmp/syslog, I wonder if python-meh should be changed to include
> /var/log/messages and /var/log/dmesg?

Just booted the live ISO on USB, and it doesn't have any log files in /tmp.
Maybe that exception report was from the netinst ISO.
Is there a way to tell from looking at the report?

> A great idea, unfortunately ABRT cannot be used for automated installer bug
> reporting in all cases.  You're welcome to explore options in this space. 
> However, bugzilla is not the best forum for gaining traction on those ideas. 
> Please use the anaconda-devel mailing list or fedoraproject wiki for additional
> communication on that topic.

Thanks for your suggestion, but I'm not that ambitious. :-)

> For additional information on automated bug
> filing during the install process, please see the old feature proposal at 
> https://fedoraproject.org/wiki/Anaconda/Features/SaveToBugzilla.
> 
> Let's use this bug report to track the specific issue that the reported
> dumpfile from the live installer should include /var/log/messages and
> /var/log/dmesg (in addition to the existing list of files included in automated
> bug reports).    

Will comment on the exception report separately.

Comment 3 Steve Tyler 2010-02-26 19:17:51 UTC
The exception report has a one-line header:
anaconda 13.31 exception report

The header does not have:
1. timestamp
2. ISO file name
3. environment (live, netinst, etc.)
4. kernel version (the kernel args. are at the end)

Some sections do not appear to be delimited.

Some sections have headers:
/tmp/anaconda.log:

However, it is difficult to search for these sections,
because they are not tagged, e.g.
== /tmp/anaconda.log ==

Comment 4 James Laska 2010-02-26 19:29:16 UTC
(In reply to comment #2)
> Why wasn't I prompted to send a bug report?

Hard to say.  The installer should prompt you, but sometimes the prompt isn't
obvious.  I'd need to see what you saw.  If you can reproduce the failure, a
screencast or screenshots during the process will help us understand what you
are experiencing.

What should happen ... when a failure occurs that is properly handled, a dialog
appears allowing you to save the failure.  This dialog defaults to saving the
failure to your local filesystem (which may not be what you wish).  The dialog
offers two other options, 1) Reporting the failure directly to bugzilla, 2)
Copy the failure information to another system using SSH

> <snip>

> > However, since running the installer in a live environment doesn't use
> > /tmp/syslog, I wonder if python-meh should be changed to include
> > /var/log/messages and /var/log/dmesg?
> 
> Just booted the live ISO on USB, and it doesn't have any log files in /tmp.
> Maybe that exception report was from the netinst ISO.
> Is there a way to tell from looking at the report?

Those files won't exist until you run the live installer.  The live installer
creates those log files to aid in problem determination. 

> <snip>

> > Let's use this bug report to track the specific issue that the reported
> > dumpfile from the live installer should include /var/log/messages and
> > /var/log/dmesg (in addition to the existing list of files included in automated
> > bug reports).    
> 
> Will comment on the exception report separately.    

Great! Let's use this bug to track updating the list of files python-meh
includes in the failure dump whenever an unhandled exception is caught.

(In reply to comment #3)
> The exception report has a one-line header:
> anaconda 13.31 exception report

Nice!  Looks like you were able to produce an exception report.

> The header does not have:
> 1. timestamp
> 2. ISO file name
> 3. environment (live, netinst, etc.)
> 4. kernel version (the kernel args. are at the end)
>
> Some sections do not appear to be delimited.
> 
> Some sections have headers:
> /tmp/anaconda.log:
> 
> However, it is difficult to search for these sections,
> because they are not tagged, e.g.
> == /tmp/anaconda.log ==    

The intended audience for the anaconda exception reports is anaconda developers.  The information you note above is included in the report.  So while the information may not be formatted to your liking, it is suited to the team of people who process this information.

Again, I think it's best to keep this bug report focused on why '/tmp/syslog' was not included during automatic bug filing.

Thanks for the report!

Comment 5 Chris Lumens 2010-02-26 19:31:56 UTC
Exception reports are not made for general public consumption, therefore it's understandable you're having difficulty reading it.

> The header does not have:
> 1. timestamp
> 2. ISO file name

These aren't specifically in the exception report, because I've not usually found them all that useful to have.  We could probably pull in the .treeinfo and .discinfo files if necessary, though.

Incidentally, including all this stuff in the header would result in quite an unwieldy large piece of text to have to process.  Automatically filed bugs have the complete python traceback as the first comment, with the whole exception dump as an attachment.  Just having the traceback in the comment is enough for us most of the time.

> 3. environment (live, netinst, etc.)

This information is most definitely in the exception report, given that you know what to look for.  "livecd", "method", and "stage2" are all good things to look for.

> 4. kernel version (the kernel args. are at the end)

This is included in the syslog, when it's pulled into the exception report.  In your case this was not included because we're not looking in the right place on liveinst.

> Some sections do not appear to be delimited.
> 
> Some sections have headers:
> /tmp/anaconda.log:
> 
> However, it is difficult to search for these sections,
> because they are not tagged, e.g.
> == /tmp/anaconda.log ==    

In general we know what we're looking for here, so delimiters are not all that important to us.

Comment 6 Steve Tyler 2010-02-26 19:36:41 UTC
(In reply to comment #2)

> Just booted the live ISO on USB, and it doesn't have any log files in /tmp.
> Maybe that exception report was from the netinst ISO.
> Is there a way to tell from looking at the report?

It helps to start anaconda ... :-p

Comment 7 Steve Tyler 2010-02-26 19:56:13 UTC
James and Chris: Thank-you both for your additional comments (and patience). I believe that James has identified the problem that prompted my original complaint about being asked to upload a second file after submitting the exception report. Glad all this was good for something ... :-)

Comment 8 Hans de Goede 2010-03-01 10:38:05 UTC
Chris, assigning to you as you have a patch for this.


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