Ubuntu06 Feb 2019 10:11 am

The other day gnumeric crashed on me and like a good Ubuntu user, I submitted the crash report to the Ubuntu Error Tracker. Naturally, I also wanted to see the crash report in the Error Tracker and find out if other people had experienced the crash. It used to be an ordeal to find the OOPS ID associated with a specific crash, you’d have to read multiple lines of the systemd journal using ‘journalctl -u whoopsie.service’ and find the right OOPS ID for the crash about which you are interested.

$ journalctl -u whoopsie.service
-- Logs begin at Fri 2019-02-01 09:36:47 PST, end at Wed 2019-02-06 08:41:02 PST. --
Feb 02 07:08:46 impulse whoopsie[4358]: [07:08:46] Parsing /var/crash/_usr_bin_gnumeric.1000.crash.
Feb 02 07:08:46 impulse whoopsie[4358]: [07:08:46] Uploading /var/crash/_usr_bin_gnumeric.1000.crash.
Feb 02 07:08:48 impulse whoopsie[4358]: [07:08:48] Sent; server replied with: No error
Feb 02 07:08:48 impulse whoopsie[4358]: [07:08:48] Response code: 200
Feb 02 07:08:48 impulse whoopsie[4358]: [07:08:48] Reported OOPS ID 7120987c-26fc-11e9-9efd-fa163ee63de6
Feb 02 07:11:11 impulse whoopsie[4358]: [07:11:11] Sent; server replied with: No error
Feb 02 07:11:11 impulse whoopsie[4358]: [07:11:11] Response code: 200

However, I recently made a change to whoopsie to write the OOPS ID to the corresponding .uploaded file in /var/crash. So now I can just read the .uploaded file to find the OOPS ID.

$ sudo cat /var/crash/_usr_bin_gnumeric.1000.uploaded

This is currently only available in Disco Dingo, which will become the 19.04 release of Ubuntu, but if you are interested in having it in another release let me know or update the bug.

Ubuntu24 Jan 2019 01:11 pm

In my years working on the Ubuntu project I’ve seen quite a lot of bug reports about people encountering failures when trying to upgrade from one release of Ubuntu to another. The most common issue, in my opinion (I have no numbers), is a system having a PPA or other 3rd party provider of packages enabled and that archive having packages which cause a failure to calculate the upgrade.

I’ve recently made some changes to ubuntu-release-upgrader which should improve this situation. The dist-upgrader has had support for an environmental variable, RELEASE_UPGRADER_ALLOW_THIRD_PARTY, for quite a while but it didn’t actually work because do-release-upgrade and check-new-release-gtk didn’t pass the variable to the dist-upgrader. This has now been resolved and actually helps with two things. One is keeping PPAs enabled during the release upgrade process, the other provides better support for users who have their own mirror of the archive. For example, I mirror some releases of Ubuntu and when upgrading have to always respond to the dialog about using an internal mirror and saying yes to rewrite my sources.list file. But now if I use ‘RELEASE_UPGRADER_ALLOW_THIRD_PARTY=1 do-release-upgrade’ I won’t see that dialog!

The other change to ubuntu-release-upgrader makes the dist-upgrader check to see if the package provider actually supports the release to which you are upgrading. As an example the team-xbmc Kodi PPA does not support Ubuntu 18.10. Without my recent change to ubuntu-release-upgrader the upgrade process would just cancel because the PPA didn’t have a release file, this seemed like a silly reason for the whole upgrade to quit! Now the release upgrader will disable the archive that doesn’t support the release to which the system is upgrading and continue to try and calculate the upgrade.

Both of these options are available for upgrades from 18.10 to 19.04 and from 18.04 to 18.10 although 18.04 changes are still in -proposed. So if you have some PPAs enabled and want an easier upgrade process be sure to use the RELEASE_UPGRADER_ALLOW_THIRD_PARTY environment variable and feel free to let me know how it goes.

Ubuntu03 Oct 2017 12:43 pm

I’ve recently been looking at issues regarding separate /boot partitions and people running out of free space. Being a long time user of Ubuntu and LVM, I have a /boot partition that was appropriately sized for kernel of the release I installed (Ubuntu 13.04!), but now that I’m running Artful Aardvark, which will become Ubuntu 17.10, my /boot partition is a bit small.

I don’t have any extraneous files in my /boot partition, like .old-dkms files (being worked in bug 1515513) or old kernels. So I need some solution to make the files that are there take up less space. Fortunately, it is possible to choose the compression method used by update-initramfs when it makes initrd images. The default “COMPRESS=gzip” can be found in /etc/initramfs-tools/initramfs.conf.

Because configuration options are also read from /etc/initramfs-tools/conf.d/ and after the initial initramfs.conf file I decided to create a file named “compressed” in that directory with the contents:


After which I needed to update the initrd.img files in my /boot partition. I can do this with:

sudo update-initramfs -u -k all

Its easy to confirm the compression method used:

$ file /boot/initrd.img-4.12.0-13-generic
/boot/initrd.img-4.12.0-13-generic: XZ compressed data

Now I’ve managed to create some more free space in my /boot partition, however it may take a bit longer for update-initramfs to run and may increase boot time a little. That sounds better than reinstalling though!

It is also worth noting that a follow on error from update-initramfs failing due to a lack of free space in boot is that it leaves extra files in /var/tmp/. Thanks to the reporter of bug 1713004 for pointing this out.

Ubuntu02 Aug 2017 05:00 pm

Earlier I wrote about how it is possible to upgrade, with the upgrade prompt set to normal, from Ubuntu 16.04 (Xenial) to Ubuntu 17.04 (Zesty) and that this is a supported upgrade path. There is an unsupported method to upgrade from Ubuntu 16.04 to Artful Aardvark, which will become Ubuntu 17.10. I say unsupported because the upgrade path is not necessarily safe and it should not be used on production systems, however it is useful for testing part of the LTS to LTS upgrade path.

As I mentioned previously, update-manager uses a meta-release file from changelogs.ubuntu.com to determine what upgrades are allowed. This meta-release file is cached in:


If we want to test an upgrade from Ubuntu 16.04 to Artful, with Prompt=lts (found in /etc/update-manager/release-upgrades) we’ll want to create our own meta-release-lts-development file. The meta-release file has lts appended because of the prompt setting and development because we will use the -d switch to perform the upgrade. This meta-release-lts-development file will contain the release we are upgrading from and release to which we are upgrading e.g.:

bdmurray@clean-xenial-amd64:~$ cat .cache/update-manager-core/meta-release-lts-development

Dist: xenial
Name: Xenial Xerus
Version: 16.04.2 LTS
Date: Thu, 21 April 2016 16:04:00 UTC
Supported: 1
Description: This is the 16.04.2 LTS release
Release-File: http://archive.ubuntu.com/ubuntu/dists/xenial/Release
ReleaseNotes: http://archive.ubuntu.com/ubuntu/dists/xenial-updates/main/dist-upgrader-all/current/ReleaseAnnouncement
ReleaseNotesHtml: http://archive.ubuntu.com/ubuntu/dists/xenial-updates/main/dist-upgrader-all/current/ReleaseAnnouncement.html
UpgradeTool: http://archive.ubuntu.com/ubuntu/dists/xenial-updates/main/dist-upgrader-all/current/xenial.tar.gz
UpgradeToolSignature: http://archive.ubuntu.com/ubuntu/dists/xenial-updates/main/dist-upgrader-all/current/xenial.tar.gz.gpg

Dist: artful
Name: Artful Aardvark
Version: 17.10
Date: Thu, 19 October 2017 17:10:00 UTC
Supported: 0
Description: This is the 17.10 release
Release-File: http://archive.ubuntu.com/ubuntu/dists/artful/Release
ReleaseNotes: http://archive.ubuntu.com/ubuntu/dists/artful/main/dist-upgrader-all/current/DevelReleaseAnnouncement
ReleaseNotesHtml: http://archive.ubuntu.com/ubuntu/dists/artful/main/dist-upgrader-all/current/DevelReleaseAnnouncement.html
UpgradeTool: http://archive.ubuntu.com/ubuntu/dists/artful/main/dist-upgrader-all/current/artful.tar.gz
UpgradeToolSignature: http://archive.ubuntu.com/ubuntu/dists/artful/main/dist-upgrader-all/current/artful.tar.gz.gpg

I created this by making a mash-up of the meta-release and meta-release-development files at changelogs.ubuntu.com. With this I can now upgrade from Ubuntu 16.04 to Artful by running:

do-release-upgrade -d
Checking for a new Ubuntu release
Get:1 Upgrade tool signature [836 B]
Get:2 Upgrade tool [1,270 kB]
Fetched 1,271 kB in 0s (0 B/s)
authenticate 'artful.tar.gz' against 'artful.tar.gz.gpg'
extracting 'artful.tar.gz'

If you run into any bugs when testing this unsupported upgrade path please report them using ‘ubuntu-bug ubuntu-release-upgrader’.

Ubuntu19 Jul 2017 02:52 pm

I’ve recently made some changes to how do-release-upgrade, called by update-manager when you choose to upgrade releases, behaves and thought it’d be a good time to clarify how things work and the changes made.

When do-release-upgrade is called it reads a meta-release file from changelogs.ubuntu.com to determine what releases are supported and to which release to upgrade. The exact meta-release file changes depending on what arguments, –proposed or –devel-release, are passed to do-release-upgrade. The meta-release file is used to determine which tarball to download and use to actually perform the upgrade. So if you are upgrading from Ubuntu 17.04 to Artful then you are actually using the the ubuntu-release-upgrader code from Artful.

One change implemented some time ago was support for the release upgrade process to skip unsupported releases if you are running a supported release. For example, when Ubuntu 16.10 (Yakkety Yak) becomes end of life and you upgrade from Ubuntu 16.04 (Xenial Xerus) with “Prompt=normal” (found in /etc/update-manager/release-upgrades) then Ubuntu 16.10 will be skipped and you will be upgraded to Ubuntu 17.04 (Zesty Zapus). This ensures that you are running a supported release and helps to test the next LTS upgrade path i.e. from Ubuntu 16.04 to Ubuntu 18.04. Similarly, when Ubuntu 17.04 becomes end of life an upgrade from Ubuntu 16.04, with “Prompt=normal”, will upgrade you to Ubuntu 17.10.

I’ve also just modified the documentation regarding the ‘-d’ switch for ubuntu-release-upgrader and update-manager to make it clear that ‘-d’ is from upgrading from the latest supported release (Ubuntu 17.04 right now) to the development release of Ubuntu. The documentation used to incorrectly imply that any release could be updated to the development release, something that would be an unsafe upgrade path. Additionally, the meta-release-development and meta-release-lts-development files were modified to only contain information about releases relevant to the upgrade path. So meta-release-lts-development is currently empty and meta-release-development only contains information about Ubuntu 17.04 and Artful Aadrvark which will become Ubuntu 17.10.

I hope this makes things a bit clearer!

Ubuntu12 Jul 2017 10:48 am

The Ubuntu Error Tracker is really good at presenting information about the versions of packages affected by a crash. Additionally, it has current information about crashes regarding stable releases of Ubuntu in addition to the development release. Subsequently, it can be a great resource for verifying that a crash is fixed for the development release or for stable releases.

As a member of the Stable Release Updates team I am excited to see an SRU which includes a bug report either generated from a crash in the Ubuntu Error Tracker (identifiable by either the bug description or errors.ubuntu.com being in the list of subscribers) or with a link to a crash in the Ubuntu Error Tracker.

One example of this is a systemd-resolved crash which while the bug report was not created by the bug bridge does contain a link to a bucket in the Error Tracer. Using the bucket in the Error Tracker we were able to confirm that new version of the package did not appear there and subsequently was no longer experiencing the same crash.

Two crashes about libgweather, bug 1688208 and bug 1695567, are less perfect examples because libgweather ended up causing gnome-shell to crash and the Error Tracker buckets for these crashes only show the version of gnome-shell. But fortunately apport gathers information about the package’s (gnome-shell in this case) dependencies and as the maintainer of the Error Tracker I can query its database. Using that ability I was able to confirm, by querying individual instances in the bucket, that the new version of libgweather did in fact fix both crashes.

So whether you are fixing crashes in the development release of Ubuntu or a stable release keep in mind that its possible to use the Error Tracker to verify that your fix works.

Ubuntu21 Jun 2017 10:40 am

The other day some of my fellow Ubuntu developers and I were looking at bug 1692981 and trying to figure out what was going on. While we don’t have an answer yet, we did use some helpful tools (at least one of which somebody hadn’t heard of) to gather more information about the bug.

One such tool is lp-bug-dupe-properties from the lptools package in Ubuntu. With this it is possible to quickly find out information about all the duplicates, 36 in this case, of a bug report. For example, if we wanted to know which releases are affected we can use:

lp-bug-dupe-properties -D DistroRelease -b 1692981

LP: #1692981 has 36 duplicates
Ubuntu 16.04: 1583463 1657243 1696799 1696827 1696863 1696930 1696940
1697011 1697016 1697068 1697099 1697121 1697280 1697290 1697313 1697335
1697356 1697597 1697801 1697838 1697911 1698097 1698100 1698104 1698113
1698150 1698171 1698244 1698292 1698303 1698324 1698670 1699329
Ubuntu 16.10: 1697072 1698098 1699356

While lp-bug-dupe-properites is useful, in this case it’d be helpful to search the bug’s attachments for more information. Luckily there is a tool, lp-grab-attachments (also part of lptools), which will download all the attachments of a bug report and its duplicates if you want. Having done that you can then use grep to search those files.

lp-grab-attachments -dD 1692981

The ‘-d’ switch indicates I want to get the attachments from duplicate bug reports and the ‘-D’ switch indicates that I want to have the bug description saved as Description.txt. While saving the description provides some of the same capability as lp-bug-dupe-properties it ends up being quicker. Now with the attachments saved I can do something like:

for desc in $(find . -name Description.txt); do grep "dpkg 1.18.[4|10]" $desc;

dpkg 1.18.4ubuntu1.2
dpkg 1.18.10ubuntu2
dpkg 1.18.10ubuntu1.1
dpkg 1.18.4ubuntu1.2

and find out that a variety of dpkg versions are in use when this is encountered.

I hope you find these tools useful and I’d be interested to hear how you use them!

Ubuntu20 Mar 2015 09:27 am

As I hinted at in my last post, apport-noui, which will enable automatic crash reporting, is now available in the -proposed repository for Trusty. If you want to test it follow the instructions in the SRU bug report. Otherwise, it will be made available in -updates next week.

Ubuntu20 Feb 2015 02:53 pm

Now that apport-noui, a package to automatically report crashes to the Ubuntu Error Tracker without user interaction, has been proven to work well on Ubuntu devices I was wondering what it would take to get it running on my Mythbuntu 14.04 install as I was tired of getting the occasional apport dialog when I was trying to watch TV.

I had to backport a couple of apport fixes and also backported one whoopsie fix that will log the OOPS ID of any reported crashes to /var/log/syslog. I’ve put these updated versions of apport and whoopsie in my PPA, however they are acceptable for a Stable Release Update and depending on the interest I will upload them to the SRU queue.

I added my PPA to my 14.04 system:

sudo add-apt-repository ppa:brian-murray/ppa

I then installed the apport-noui package on it.

sudo apt-get install apport-noui

I’ve been running it for about a week now and looked in my /var/crash/ directory on my Mythtv system to discover a .crash and a correpsonding .uploaded file. The .uploaded file means that the crash was sent to the Ubuntu Error Tracker.

While I could inspect the .crash file on my system to see what it is about let’s look for the OOPS ID in /var/log/syslog.

Feb 20 10:38:54 flash whoopsie[8223]: Parsing
Feb 20 10:38:54 flash whoopsie[8223]: Uploading
Feb 20 10:38:56 flash whoopsie[8223]: Sent; server replied with: No error
Feb 20 10:38:56 flash whoopsie[8223]: Response code: 200
Feb 20 10:38:56 flash whoopsie[8223]: Reported OOPS ID

The crash can be found at the Error Tracker at https://errors.ubuntu.com/oops/2ad9d3f0-b6b8-11e4-bf61-fa163e707a72. On the problem instance page we can see a line labelled Problem and that is a link to the bucket for these crashes. These crashes seem to occur pretty frequently, so I’ve opened a Launchpad bug report corresponding to the crash.

Let me know if you think this is useful (or if you have any issues) and I’ll work on getting this into the Trusty and Utopic SRU queues.

Ubuntu04 Dec 2013 06:13 pm

One thing I remember being excited about when moving from Windows to Linux was using my middle mouse button to paste. I somewhat recently got a Apple Wireless Trackpad and lost this ability as there is no middle mouse button. (As far as I knew at the time, but it looks like the upper right corner is a middle click.) I discovered that I could set a three finger tap to middle click and subsequently paste by the following:

/usr/bin/xinput set-prop "Apple Wireless Trackpad" "Synaptics Tap Action" 2 3 0 0 1 3 2

However, running that on every reboot, and battery change in the trackpad was rather annoying. With the advent of upstart user jobs (the real point of this post) I thought one would be a good way to set this functionality.

I put the following in a file named magicpad-paste.conf in my ~/.config/upstart/ directory:

description "Enable three finger middle click with an Apple Trackpad"
author "Brian Murray "

start on :sys:input-device-added NAME='"Apple Wireless Trackpad"'


echo "$DATE Apple Wireless Trackpad detected"
# it seems that a sleep is needed for the device to become fully available
sleep 5
/usr/bin/xinput set-prop "Apple Wireless Trackpad" "Synaptics Tap Action" 2 3 0 0 1 3 2

end script

The hardest part was figuring out that a sleep was necessary for the device to become fully registered so that xinput would work.

Next Page »