package install failures with uninformative dpkgterminallog files

Bug #1049223 reported by Brian Murray on 2012-09-11
This bug affects 1 person
Affects Status Importance Assigned to Milestone
apport (Ubuntu)

Bug Description

We occassionally receive package installation failures with DpkgTerminalLog files that contain the following:

 Can not write log, openpty() failed (/dev/pts not mounted?)
 Can not write log, openpty() failed (/dev/pts not mounted?)

These messages are from apt (apt-pkg/deb/ and indicate a failure to openpty. This then results in an apport-package bug report that is lacking enough information for us to do anything about.

These should either not be reported anymore or we figure out how to make apt more informative or why /dev/pts is not accessible.

An example bug report can be found in bug 1048012.

Brian Murray (brian-murray) wrote :

Looking at a collection of DpkgTerminalLog file attachments (from open bugs only) we can see these bugs have this error message in the log file:


That's about 22 out of 1100 package install failures. However, a lot of bugs with this error may be closed as Invalid or the DpkgTerminalLog may appear in the bug description.

Brian Murray (brian-murray) wrote :

Michael - do you have any idea how we can improve the situation here? I'd rather not just block these package install failures.

Changed in apport (Ubuntu):
assignee: nobody → Brian Murray (brian-murray)
status: New → Triaged
importance: Undecided → High
Brian Murray (brian-murray) wrote :

Looking at the 22 bugs that I mentioned the vast majority have 'Command line' information in dmesg that references a cdrom for example:

bug-991520/Dmesg.txt:[ 0.000000] Command line: file=/cdrom/preseed/ubuntu.seed boot=casper initrd=/casper/initrd.lz quiet splash -- maybe-ubiquity

which leads me to believe they had chroot'ed into their Ubuntu system to repair a failed upgrade. There are also a few with 'rescue/enable=true' in the Command line, which is also likely a situation where people chroot'ed.

So I think the best thing to do is just block these package installation failures.

Brian Murray (brian-murray) wrote :

The string is translated so we'll need to check and see if the bug report is coming from a chroot'ed system.

Brian Murray (brian-murray) wrote :

update-manager has some code to see if it is inside a chroot:

def inside_chroot():
    """ returns True if we are inside a chroot
    # if there is no proc or no pid 1 we are very likely inside a chroot
    if not os.path.exists("/proc") or not os.path.exists("/proc/1"):
        return True
    # if the inode is differnt for pid 1 "/" and our "/"
    return os.stat("/") != os.stat("/proc/1/root")

Brian Murray (brian-murray) wrote :

Thinking about this more the check to see whether or not we are inside a chroot would need to happen when the package fails to install (like in apt-pkg/deb/ not after the fact when processing the apport report (e.g. the ubuntu general hook) written to /var/crash.

Changed in apport (Ubuntu Raring):
status: Triaged → Won't Fix
Changed in apport (Ubuntu Raring):
assignee: Brian Murray (brian-murray) → nobody
Changed in apport (Ubuntu):
assignee: Brian Murray (brian-murray) → nobody

This release of Ubuntu is no longer receiving maintenance updates. If this is still an issue on a maintained version of Ubuntu please let us know.

Changed in apport (Ubuntu):
status: Triaged → Incomplete
Launchpad Janitor (janitor) wrote :

[Expired for apport (Ubuntu) because there has been no activity for 60 days.]

Changed in apport (Ubuntu):
status: Incomplete → Expired
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers