M BUZZ CRAZE NEWS
// general

how to fix a non-existent executable path causing "ubuntu internal error"?

By Mia Morrison

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'
ProcStatus: 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
2

2 Answers

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.

3

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:

Edit:

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.

4

Your Answer

Sign up or log in

Sign up using Google Sign up using Facebook Sign up using Email and Password

Post as a guest

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