3

I have done this many times before and it has always worked so I don't know what the problem is now, I even had a look at this but still can't get it working. virt-manager had a crash, it created a .crash file in /var/crash, but it wasn't convenient at the time to file a report so I cancelled reporting it through the GUI.

However now I do want to report it so I have tried running:

sudo apport-cli -p virt-manager --crash-file=_usr_sbin_libvirtd.0.crash

I also tried it initially without specifying the -p option. But the same happens every time, when I answer this it just exits:

*** Send problem report to the developers?

After the problem report has been sent, please fill out the form in the
automatically opened web browser.

What would you like to do? Your options are:
  S: Send report (3.5 MB)
  V: View report
  K: Keep report file for sending later or copying to somewhere else
  I: Cancel and ignore future crashes of this program version
  C: Cancel
Please choose (S/V/K/I/C): S

And nothing comes of it, the only seemingly noticeable change is that .upload and .uploaded files get created in the same location as the .crash file, but nothing actually comes of it. I have tried running it in a TTY, it would normally give me a URL to go to where it has uploaded the data to, but it just exists which is very odd and has never happened before.

So now I am at a loss of how to report it, I tried through the GUI, through the CLI... So how can I file this report on this crash with the .crash file? What am I doing wrong? I am running Ubuntu GNOME 16.04 with GNOME 3.20.

Information Update:

Just checked and found that both the .upload and the .uploaded files are completely blank.

Also, when running the above command I find that this is logged in my syslog:

Jul  5 21:01:43 <Computer-Name> whoopsie[834]: [21:01:43] Parsing /var/crash/_usr_sbin_libvirtd.0.crash.
Jul  5 21:01:43 <Computer-Name> whoopsie[834]: [21:01:43] Uploading /var/crash/_usr_sbin_libvirtd.0.crash.
Jul  5 21:01:45 <Computer-Name> whoopsie[834]: [21:01:45] Sent; server replied with: No error
Jul  5 21:01:45 <Computer-Name> whoopsie[834]: [21:01:45] Response code: 400
Jul  5 21:01:45 <Computer-Name> whoopsie[834]: [21:01:45] Server replied with:
Jul  5 21:01:45 <Computer-Name> whoopsie[834]: [21:01:45] Crash already reported.
  • Do it exist immediately or just takes some time? – Braiam Jul 02 '16 at 22:22
  • @Braiam: As soon as I reply it exits immediately. Takes no time at all in fact, it's instantaneous. –  Jul 02 '16 at 22:39
  • @Braiam: I have updated my question by the way, don't know if it's any help though. –  Jul 05 '16 at 20:00
  • In apport source code, there's a [signature generator](https://bazaar.launchpad.net/~apport-hackers/apport/trunk/view/head:/apport/report.py#L1236) which should give you more information (since the server says that the crash has been submitted). Try to get the signature of your crash and google for it. Alternative, open a bug on LP to allow people to obtain this information on-demand, or another bug asking whenever it should exit without feedback. – Braiam Jul 05 '16 at 20:46
  • @Braiam: Would the report be associated with my LP account that I was logged into at the time when it would have submitted the report or does it only register the connection after I go to it? –  Jul 05 '16 at 21:29
  • I would presume that your report goes through anonymously until the last moment, so, no, I don't think it was registered. – Braiam Jul 05 '16 at 22:09

1 Answers1

1

Just prior to Release Apport crashes opening a LP report is disabled. All Apport crash reports then go to a Db via whoopsie. In the current dev LP reports from crashes is turned back on a couple of months or so from the start of dev.

If you want to open a LP report in a Release version of Ubuntu then you'll need to use ubuntu-bug packagename.

Otherwise they only way in these cases is to re-enable LP reports in Apport, generally that's not appreciated though on occasion I'll do just that. But in order to do so do the following:

1. Run:

sudo vim /etc/apport/crashdb.conf

2. Add a # to the beginning of the 'problem_types': ['Bug', 'Package'], line in order to comment it out.

3. Save the changes and Apport should report bugs to LP as you requested.

Non-security-related bugs in a Release version should be first checked if they also exist in the current dev, if so the LP report should be against the dev package. That's the first step in a possible SRU (stable release update ), for the Release version.

doug
  • 16,848
  • 2
  • 45
  • 60
  • 1
    But I am using `ubuntu-bug` and specifying the package even... I'm also not using a non-Release version... And this is not what normally happens, it's always worked fine before this and either given me a URL or opened a browser window. –  Jul 05 '16 at 22:55
  • There is nothing in your question indicating you've used the command of ubuntu-bug package name. Also there is no mention of using a dev version so what are you really talking about? – doug Jul 06 '16 at 04:46
  • 1
    Using `ubuntu-bug` means using a GUI, using `apport-cli` is the same except it's in the CLI. Normally this problem is solved by me using the CLI, that's why I was doing that when asking the question, but I did try `ubuntu-bug` before that. In my question I stated that I am running Ubuntu GNOME 16.04 which **is** a release version so I don't know what you are talking about. –  Jul 06 '16 at 16:39
  • In my question I said `I tried through the GUI`, that's what I meant. –  Jul 06 '16 at 16:40
  • I've explained this as best as I can, the gist is everything is working for you as expected. If on a Release then crashers will not open a Lp report. If on a dev version then crashers will not open a Lp report until it's re-enabled again. If you want to file a bug to Lp then open a terminal & use the ubuntu-bug command. (there is no gui involved) Ex. - filing against nautilus, `ubuntu-bug nautilus` – doug Jul 06 '16 at 19:29
  • 1
    Well this doesn't usually happen when I do this, it normally gives me a URL to where it has reported the crash report to `ubuntu-bug` would not be appropriate in this case for I need to file the report with a specific dump, not just a general bug. –  Jul 06 '16 at 19:40