I keep seeing an "internal error" dialog on startup (please see below for header of .crash file).

Please note, /usr/lib/virtualbox/VirtualBoxVM does not exist (since the last couple reboots) and the error still appears.

Here is the output of ls /var/crash:

(base) au@a1:~$ ls -l /var/crash
total 24480
-rw-r----- 1 au       whoopsie 16389469 Jan  2 09:36 _usr_bin_pulseaudio.1000.crash
-rw-rw-r-- 1 au       whoopsie        0 Jan  2 09:36 _usr_bin_pulseaudio.1000.upload
-rw------- 1 whoopsie whoopsie       37 Jan  2 09:36 _usr_bin_pulseaudio.1000.uploaded
-rw-r----- 1 root     whoopsie  8655015 Jan  8 00:23 _usr_lib_virtualbox_VirtualBoxVM.0.crash
-rw-r--r-- 1 root     whoopsie    10082 Jan  8 00:17 virtualbox-dkms.0.crash

Here is the header (minus the coredump) of /var/crash/_usr_lib_virtualbox_VirtualBoxVM.0.crash:

ProblemType: Crash
Architecture: amd64
Date: Fri Jan  8 00:23:30 2021
DistroRelease: Ubuntu 20.04
ExecutablePath: /usr/lib/virtualbox/VirtualBoxVM
ExecutableTimestamp: 1591443097
ProcCmdline: /usr/lib/virtualbox/VirtualBoxVM --comment w10 --startvm 6bad7132-1231-4cf8-8ac2-5a2a99493c86 --no-startvm-errormsgbox
ProcEnviron: Error: [Errno 13] Permission denied: 'environ'
ProcMaps: Error: [Errno 13] Permission denied: 'maps'
 Name:  VirtualBoxVM
 Umask: 0002
 State: S (sleeping)
 Tgid:  3479
 Ngid:  0
 Pid:   3479
 PPid:  1866
 TracerPid: 0
 Uid:   1000    1000    1000    1000
 Gid:   1000    1000    1000    1000
 FDSize:    64
 Groups:    4 24 27 30 46 120 131 132 1000 
 NStgid:    3479
 NSpid: 3479
 NSpgid:    3477
 NSsid: 3138
 VmPeak:      382984 kB
 VmSize:      371348 kB
 VmLck:        0 kB
 VmPin:        0 kB
 VmHWM:    69868 kB
 VmRSS:    68296 kB
 RssAnon:      17056 kB
 RssFile:      51240 kB
 RssShmem:         0 kB
 VmData:       39764 kB
 VmStk:      132 kB
 VmExe:       40 kB
 VmLib:    80832 kB
 VmPTE:      404 kB
 VmSwap:           0 kB
 HugetlbPages:         0 kB
 CoreDumping:   1
 THP_enabled:   1
 Threads:   3
 SigQ:  0/256693
 SigPnd:    0000000000000000
 ShdPnd:    0000000000000000
 SigBlk:    0000000000000000
 SigIgn:    0000000001001000
 SigCgt:    0000000180000000
 CapInh:    0000000000000000
 CapPrm:    0000000000000000
 CapEff:    0000000000000000
 CapBnd:    000000ffffffffff
 CapAmb:    0000000000000000
 NoNewPrivs:    0
 Seccomp:   0
 Speculation_Store_Bypass:  thread vulnerable
 Cpus_allowed:  ffffffff
 Cpus_allowed_list: 0-31
 Mems_allowed:  00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000001
 Mems_allowed_list: 0
 voluntary_ctxt_switches:   1149
 nonvoluntary_ctxt_switches:    65
Signal: 6
Uname: Linux 5.8.0-36-generic x86_64
UserGroups: adm cdrom dip lpadmin lxd plugdev sambashare sudo

  • thanks, @user535733 please see updated – mkk Jan 8 at 18:02
  • Try sudo apt update then sudo apt install --reinstall virtualbox if you need Virtualbox or sudo apt remove --purge virtualbox if you don't need it anymore. – Raffa Jan 8 at 18:14

I would remove the files:

sudo rm /var/crash/_usr_lib_virtualbox_VirtualBoxVM.0.crash
sudo rm /var/crash/virtualbox-dkms.0.crash

See this article for more background:



Worth noting, I would not advocate for disabling Apport, like the author of the article does. In my experience cleaning out /var/crash/ when these popups start to come up on every reboot is sufficient and convenient enough.

  • thanks @Levente, I'm confused about why the video recommends to disable apport? Doesn't this mean there could be a million things crashing every time I start ubuntu and I'd never know? I want to make sure everything is working all the time – mkk Jan 8 at 18:11
  • I would not disable Apport. I would just do the part where he advises for the removal of the file. Actually I did a few times; I have encountered this very problem, and this article helped me. But I never disabled Apport. Yet cleaning out /var/crash/ for similar reasons was necessary only like 3 times throughout 4 years of usage. So, I would say, Apport can remain. In my experience, cleaning out /var/crash/ when it becomes necessary is not too big of an inconvenience. – Levente Jan 8 at 18:17
  • @mkk Clearing /var/crash/ will not prevent future crashes from being reported. But it will not solve the issue causing the crash report as well. The only case you might need to clesr the crash report is if a pop up warning is still shown after the issue is solved. – Raffa Jan 8 at 18:26
  • @Raffa yes; I think this is exactly the scenario that OP described: They don't talk about virtualbox crashing all the time. They talk about: 'I keep seeing an "internal error" dialog on startup'. Exactly how it was in my experience, and how this article describes it too. – Levente Jan 8 at 18:31

Let's look at the process of a crash report, using an example from your output:

-rw-r----- 1 au       whoopsie 16389469 Jan  2 09:36 _usr_bin_pulseaudio.1000.crash
-rw-rw-r-- 1 au       whoopsie        0 Jan  2 09:36 _usr_bin_pulseaudio.1000.upload
-rw------- 1 whoopsie whoopsie       37 Jan  2 09:36 _usr_bin_pulseaudio.1000.uploaded

Here, you can see a process.

  1. The crash report is assembled by the apport application
  2. The crash report is uploaded by the whoopsie application
  3. An acknowledgement of the of upload (from Canonical's 'daisy' server) is recorded by whoopsie.

Now, let's look at your latest crash reports:

-rw-r----- 1 root     whoopsie  8655015 Jan  8 00:23 _usr_lib_virtualbox_VirtualBoxVM.0.crash
-rw-r--r-- 1 root     whoopsie    10082 Jan  8 00:17 virtualbox-dkms.0.crash

First, look at the date: Both crashes occurred today. So you should have seen the "An error occurred" dialog twice. Your question implied (perhaps unintentionally) that this was an ongoing problem for a few days, but that's clearly a misreading.

Next, let's move to your .crash output:

Date: Fri Jan  8 00:23:30 2021
ProcCmdline: /usr/lib/virtualbox/VirtualBoxVM --comment w10 --startvm 6bad7132-1231-4cf8-8ac2-5a2a99493c86 --no-startvm-errormsgbox

This means that something on your system ran that command at that time. When you removed VirtualBoxVM, looks like you neglected to remove some script or timer or service or cronjob or something else that tried to launch that non-existent VM.

  • 1
    @mkk This seems like a good explanation as to why the crash report happened in the first place. Very well explained. – Raffa Jan 8 at 19:02
  • I agree with @Raffa. This answer is very helpful and educative. Watching a collaboration following up on this answer could have taught us something valuable about the true background of the issue. I now wish that I was slower with my answer. – Levente Jan 8 at 19:24
  • 1
    @Levente yours is a very good answer, and very much what the OP was looking for. – user535733 Jan 8 at 19:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.