[TriLUG] Here's an idea to make it easier to fix a Linux OS!!

[Brent Fox]

On Friday 02 November 2001 03:02 am, al johson wrote:
> I was thinking about the above comment and realized that this would be an
> excellent opportunity for the manufacturer to figure out where they
> weaknesses lie in their loaders!! in fact it would be very similar to what
> happens when a desktop application fails and a report for the author is
> created to help the author fix the problem. It is true that Red Hat or any
> other distribution cannot know about weaknesses or failures if they are
> never told. But the problem is an accurate description of the
> problem---esp. if the problem is encountered by a novice or newbie. But if
> the problem could be emailed to Red Hat or other distributors, it might be
> possible to fix it, just like the application crash reports. 

We have this already.  In anaconda, when a crash occurs, we capture the 
Python traceback and have a button to save the traceback to a floppy.  There 
are also instructions on the screen asking the user to file a bug in Bugzilla 
and to attach the file that the installer just wrote to the floppy.  Indeed, 
debugging the installer would be dang near impossible without that.

A typical Python traceback will look something like this:

Traceback (innermost last):
  File "/usr/bin/anaconda", line 620, in ?
    intf.run(id, dispatch, configFileData)
  File "/usr/lib/anaconda/gui.py", line 350, in run
    self.icw.run (self.runres, configFileData)
  File "/usr/lib/anaconda/gui.py", line 778, in run
    mainloop ()
  File "/usr/lib/python1.5/site-packages/gtk.py", line 2608, in mainloop
    _gtk.gtk_main()
  File "/usr/lib/anaconda/gui.py", line 497, in handleRenderCallback
    self.currentWindow.renderCallback()
  File "/usr/lib/anaconda/iw/progress_gui.py", line 135, in renderCallback
    self.intf.icw.nextClicked()
  File "/usr/lib/anaconda/gui.py", line 399, in nextClicked
    self.dispatch.gotoNext()
  File "/usr/lib/anaconda/dispatch.py", line 143, in gotoNext
    self.moveStep()
  File "/usr/lib/anaconda/dispatch.py", line 208, in moveStep
    rc = apply(func, self.bindArgs(args))
  File "/usr/lib/anaconda/packages.py", line 434, in doPreInstall
    method.mergeFullHeaders(id.hdList)
  File "/usr/lib/anaconda/image.py", line 26, in mergeFullHeaders
    hdlist.mergeFullHeaders(self.tree + "/RedHat/base/hdlist2")
  File "/usr/lib/anaconda/comps.py", line 161, in mergeFullHeaders
    rpm.mergeHeaderListFromFD(self.hdlist, fd, 1000004)
rpm.error: match tag mismatch

Local variables in innermost frame:
self: <comps.HeaderListFromFile instance at 8756050>
file: /mnt/source/RedHat/base/hdlist2
fd: 28

So just from looking at this traceback (from bug #55422), I can tell that 
there is corruption on the cdrom.  The installer is looking for a file on the 
cd (/mnt/source/RedHat/base/hdlist2) and it can't find it.  Since that file 
absolutely must be on the disc, the installer won't work without it.  The 
cdrom must be corrupted somehow.  Bad cdrom reports are our most common bug.

Now, if the bug is in the loader (which is a tiny C program that kicks off 
Anaconda, the main installer (written in Python), it's not possible to retain 
the kind of debugging information that we can with Anaconda.  Fortunately, 
the loader is pretty small and is pretty reliable.  The loader doesn't change 
much and we don't get many bug reports against it.

Also, if the user has a bad cd that prevents the cd from booting correctly, 
there's no way to trap much data here.  If the kernel can't even boot, you 
can't get much meaningful data.

Brent