DebuggingUbiquity

Differences between revisions 48 and 49
⇤ ← Revision 48 as of 2012-02-24 16:29:46 →
Size: 5652
Editor: jibel
Comment:
← Revision 49 as of 2012-02-27 10:08:25 → ⇥
Size: 4585
Editor: jibel
Comment:
Deletions are marked like this. Additions are marked like this.
Line 6: Line 6:
Many Ubiquity bugs arrive in the form of cut-and-pastes from its crash helper dialog. In simple cases, these are often enough to completely diagnose the bug and allow a developer to fix it, which is why the crash dialog exists. However, if the crash occurs in `install.py` (the component of Ubiquity that actually constructs and configures the newly-installed system), then in Dapper a combination of technical awkwardness and lack of developer time means that the traceback from the crash dialog often ends like this: If you're running the development release, most Ubiquity bugs are reported by apport and the right log files are attached to the bug report.

If the log files are not attached and want to analyze them locally logs are:

 * During installation or from a Live Session:
{{{
/var/log/syslog
/var/log/partman
/var/log/installer
}}}

 * After installation from running system installer log files are stored in the directory ```/var/log/installer/```

These are often enough to completely diagnose the bug and allow a developer to fix it.

Sometimes, the developer will need more information than what is actually in the log files. In this case, if you know and can reproduce the defect you can run Ubiquity in '''debug mode'''. To run Ubiquity in debug mode, from a Live Session, open a terminal (On Unity Press <Super> to display the dash then enter '''terminal''' in the search field then <Enter>) and start Ubiquity with:
Line 9: Line 24:
RuntimeError: Install failed with exit code 1; see /var/log/installer/syslog and /var/log/syslog $ ubiquity -d
Line 12: Line 27:
(Edgy installations will produce a more verbose traceback.)

This traceback is moderately useless on its own, and you must not mark bugs as duplicates on the basis that they both contain a traceback such as this. In Dapper, the real error is hidden in /var/log/installer/syslog, so if the reporter didn't attach that, ask for it, and for /var/log/syslog and /var/log/partman as well for good measure. Look for the traceback from the crash dialog in /var/log/installer/syslog and then trace up a little bit; the real error should be there, often in the form of a subprocess exiting non-zero.

Standard text for asking for log files in Dapper: {{{
Could you please attach /var/log/installer/syslog, /var/log/syslog, and /var/log/partman to this bug, following the directions in http://wiki.ubuntu.com/DebuggingUbiquity/AttachingLogs? Thanks in advance.
}}}

Standard text for asking for log files in >= Edgy: {{{
Could you please attach /var/log/syslog and /var/log/partman to this bug, following the directions in http://wiki.ubuntu.com/DebuggingUbiquity/AttachingLogs? Thanks in advance.
}}}

Don't ask for `/var/log/installer/syslog` if the version of ubiquity in the log is `1.1.12` or greater (Edgy or later). Those versions of ubiquity send all log messages apart from certain detailed partitioning log messages to `/var/log/syslog`, and `/var/log/installer/syslog` no longer exists.

Debugging Central

This page is part of the debugging series — pages with debugging details for a variety of Ubuntu packages.

Crash report handling

If you're running the development release, most Ubiquity bugs are reported by apport and the right log files are attached to the bug report.

If the log files are not attached and want to analyze them locally logs are:

  • During installation or from a Live Session: 

/var/log/syslog
/var/log/partman
/var/log/installer

  • After installation from running system installer log files are stored in the directory /var/log/installer/

These are often enough to completely diagnose the bug and allow a developer to fix it.

Sometimes, the developer will need more information than what is actually in the log files. In this case, if you know and can reproduce the defect you can run Ubiquity in debug mode. To run Ubiquity in debug mode, from a Live Session, open a terminal (On Unity Press <Super> to display the dash then enter terminal in the search field then <Enter>) and start Ubiquity with: 

$ ubiquity -d

Please do not assign ubiquity bugs to anyone unless you're a ubiquity developer or you manage a ubiquity developer. Please don't reject ubiquity bugs unless you're a ubiquity developer. In general, please try to refrain from causing unnecessary extra bug mail noise for ubiquity developers or from taking items off their to-do lists without consulting them first.

Known bugs

Before filing new bugs, check that it is not already listed in Launchpad

Non-bugs

Certain hardware failures can often be reported as installer bugs. This includes faulty CDs, CD drives hard drives and memory.

You can check if your hardware is faulty from kernel's error message in /var/log/syslog or the output of the command dmesg

You'll find messages such as: 

Feb 18 22:01:41 ubuntu kernel: [ 1976.481211] ata3.00: exception Emask 0x0 SAct 0x1 SErr 0x0 action 0x0
Feb 18 22:01:41 ubuntu kernel: [ 1976.481230] ata3.00: irq_stat 0x40000008
Feb 18 22:01:41 ubuntu kernel: [ 1976.481257] ata3.00: failed command: READ FPDMA QUEUED
Feb 18 22:01:41 ubuntu kernel: [ 1976.481281] ata3.00: cmd 60/08:00:58:5c:0c/00:00:00:00:00/40 tag 0 ncq 4096 in
Feb 18 22:01:41 ubuntu kernel: [ 1976.481286]          res 51/40:08:58:5c:0c/00:00:00:00:00/40 Emask 0x409 (media error) <F>
Feb 18 22:01:41 ubuntu kernel: [ 1976.481296] ata3.00: status: { DRDY ERR }
Feb 18 22:01:41 ubuntu kernel: [ 1976.481304] ata3.00: error: { UNC }
Feb 18 22:01:41 ubuntu kernel: [ 1976.484953] ata3.00: configured for UDMA/133
Feb 18 22:01:41 ubuntu kernel: [ 1976.485000] sd 3:0:0:0: [sda] Unhandled sense code
Feb 18 22:01:41 ubuntu kernel: [ 1976.485012] sd 3:0:0:0: [sda]  Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Feb 18 22:01:41 ubuntu kernel: [ 1976.485029] sd 3:0:0:0: [sda]  Sense Key : Medium Error [current] [descriptor]
Feb 18 22:01:41 ubuntu kernel: [ 1976.485048] Descriptor sense data with sense descriptors (in hex):
Feb 18 22:01:41 ubuntu kernel: [ 1976.485058]         72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 
Feb 18 22:01:41 ubuntu kernel: [ 1976.485106]         00 0c 5c 58 
Feb 18 22:01:41 ubuntu kernel: [ 1976.485121] sd 3:0:0:0: [sda]  Add. Sense: Unrecovered read error - auto reallocate failed
Feb 18 22:01:41 ubuntu kernel: [ 1976.485137] sd 3:0:0:0: [sda] CDB: Read(10): 28 00 00 0c 5c 58 00 00 08 00
Feb 18 22:01:41 ubuntu kernel: [ 1976.485165] end_request: I/O error, dev sda, sector 810072
Feb 18 22:01:41 ubuntu kernel: [ 1976.485225] ata3: EH complete

Notes

The 'kernel command line' line of the syslog file contains information about the boot parameters used.

  • Images created by unetbootin contain 'initrd=/ubninit' and / or 'BOOT_IMAGE=/ubnkern'

Bugs should be tagged indicating the step where the issue occurred if possible. The possible steps are:

  • ubi-console-setup
  • ubi-language
  • ubi-migrationassistant
  • ubi-network
  • ubi-partman
  • ubi-prepare
  • ubi-tasks
  • ubi-timezone
  • ubi-usersetp - "Who are you?"
  • ubi-webcam
  • ubi-wireless

Also see:

CategoryBugSquad CategoryDebugging