Check for running VirtualBoxes before uninstall old version

[Petr Burian]

If there is running/suspended VirtualBoxe the installer complains about it and end with error.

Unpacking virtualbox-3.2 (from .../virtualbox-3.2_3.2.0-61806~Ubuntu~karmic_amd64.deb) ...
dpkg: error processing /var/cache/apt/archives/virtualbox-3.2_3.2.0-61806~Ubuntu~karmic_amd64.deb (--unpack):
 subprocess new pre-installation script returned error exit status 1
Errors were encountered while processing:
 /var/cache/apt/archives/virtualbox-3.2_3.2.0-61806~Ubuntu~karmic_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

This check is done after previous version (3.1) is uninstalled. I am not able to turn off running/suspended guests because no VirtualBox is installed at the moment. The solution is to install previous version (3.1) again, turn off guests and then install version 3.2.

Suggestion - do this check BEFORE you uninstall old version.

[Simón]

Ubuntu Lucid 10.04 32 bits

Same problem here:

Preparing to replace virtualbox-3.2 3.2.2-62298~Ubuntu~lucid (using
.../virtualbox-3.2_3.2.4-62431~Ubuntu~lucid_i386.deb) ...
dpkg: warning: old `pre-removal' script returned an exit error 1
dpkg - trying script from the new package instead...
 * Stopping VirtualBox kernel module                                          
                                                                                                         *  done.
dpkg: ... it seems that everything went well.
dpkg: error processing /var/cache/apt/archives/virtualbox-3.2_3.2.4-62431~Ubuntu~lucid_i386.deb (--unpack):
 subprocess new pre-installation script returned an exit error code 1.
 * Starting VirtualBox kernel module                                           
                                                                                                         *  done.
 ...
Errors were encountered while processing:
 /var/cache/apt/archives/virtualbox-3.2_3.2.4-62431~Ubuntu~lucid_i386.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

In my case, I am upgrading virtualbox-3.2 3.2.2-62298~Ubuntu~lucid to 3.2.4-62431~Ubuntu~lucid. But it gives same error when upgrading to 3.2.2-62298~Ubuntu~lucid version.

[Simón]

This is very annoying!!! :-(
I can't uninstall nor upgrading...
Please, solve this as soon as possible!!

[Simón]

I have rebooted the system and I have tried to upgrade again, but same error!!!

[Frank Mehnert]

Seems your keyboard is broken, you should check the '!' key.

Regarding your problem: I assume that there was still a VBoxSVC daemon running. Make sure that no such daemon is running (no VBox GUI open, no VM started). Then re-install the new package. If that does not work for some reason then uninstall the package (dpkg --purge virtualbox-3.2), then install the package again (dpkg -i virtualbox-3.2....).

[Simón]

Linux rebooted!!!!!!
No VBox GUI open!!!!!!!!!
No VM started!!!!!

sudo service vboxdrv stop
 * Stopping VirtualBox kernel module
 *  done.

dpkg --purge virtualbox-3.2 not works neither!!!!!!!

sudo dpkg --purge virtualbox-3.2 
(Leyendo la base de datos ...  00%
239559 ficheros y directorios instalados actualmente.)
Desinstalando virtualbox-3.2 ...
dpkg: error al procesar virtualbox-3.2 (--purge):
 el subproceso script pre-removal instalado devolvió el código de salida de error 1
 * Starting VirtualBox kernel module                                               
                                                                                                    *  done.
Procesando disparadores para python-central ...
Se encontraron errores al procesar:
 virtualbox-3.2

[Frank Mehnert]

Please add the output of

/bin/ps aux|grep VBoxSVC

as well as the output of

pidof VBoxSVC

[Simón]

$ /bin/ps aux|grep VBoxSVC
7811  0.0  0.1  22480  6452 ?        Sl   18:53   0:00 /usr/lib/virtualbox/VBoxSVC --pipe 4 --auto-shutdown

$ pidof VBoxSVC
7811

Ok, it's solved. I have killed the process:

sudo kill -9 7811

And I have could upgrade.
I hope that this doesn't happen again. Although it is the second time it happens.
The last time the error occurred because it was being upgraded, at the same time, the kernel version and VirtualBox. I rebooted and I can upgrade VirtualBox.
But this time, the problem wasn't this.

Thanks.

[Frank Mehnert]

That's exactly what I was assuming. The package checks if a VBoxSVC daemon is running and will deny to upgrade or remove. This is what the original reporter requested.

The VBoxSVC daemon does not start automatically but only if you start the GUI or a VM. After the GUI and the last VM terminated, the VBoxSVC daemon will continue running for about 10 seconds. If the daemon does not terminate itself the it's either a bug in the daemon or there is still a VBox process active. So, if you observe a VBoxSVC daemon again then check with /bin/ps aux|grep virtualbox if there is another VirtualBox / VBoxHeadless / VBoxSVC / VBoxManage process or some VBox webconsole around.

[Simón]

Then there is a bug:

/bin/ps aux|grep virtualbox 
xxxx     7802  0.0  0.0  12252  3632 ?        S    18:53   0:00 /usr/lib/virtualbox/VBoxXPCOMIPCD
xxxx    12081  0.0  0.2  25472  9244 ?        Sl   21:17   0:01 /usr/lib/virtualbox/VBoxSVC --pipe 4 --auto-shutdown

[Simón]

Almost two hours later:

$ /bin/ps aux|grep virtualbox 
xxxx     7802  0.0  0.0  12252  3632 ?        S    18:53   0:00 /usr/lib/virtualbox/VBoxXPCOMIPCD
xxxx    12081  0.0  0.2  25472  9244 ?        Sl   21:17   0:01 /usr/lib/virtualbox/VBoxSVC --pipe 4 --auto-shutdown

Is it correct that VBoxXPCOMIPCD is executing?

[Frank Mehnert]

No, both daemons should shut down themself. But if they don't do this after about 10 seconds after the last VM terminated + the last GUI session finished, then they wouldn't do this anymore. So kill these two daemons manually. Such hanging daemons may occur very seldom under rare circumstances -- difficult to debug and not subject of this ticket.

[Simón]

Today I have received other VirtualBox upgrade to v3.2.4-62467~Ubuntu~lucid.
Before I killed both daemons. The upgrade was correct and I tested again and it was correct. Both daemons shut downs themself.
Thanks.

[Simón]

Other time this error from version 3.2.4-62467~Ubuntu~lucid to 3.2.6-63112~Ubuntu~lucid.

Do I have to kill both processes before upgrades forever? This is totally wrong.
Do you plan to fix this?

[Frank Mehnert]

Are you sure that there are no other VirtualBox processes running when you try to upgrade? A dangling VBoxSVC server can happen sometimes under rare circumstances but it seems that you are always affected which is definitely strange.

[Simón]

Replying to frank:

Are you sure that there are no other VirtualBox processes running when you try to upgrade? A dangling VBoxSVC server can happen sometimes under rare circumstances but it seems that you are always affected which is definitely strange.

Very sure. By several reasons:

1. Casually, this time I had just turned on the PC before upgrading and I had not run VirtualBox. I use VirtualBox to virtualize Windows and I use very little that OS.
2. The unique active session was the mine.
3. If it was executing, VirtualBox window should be open or recently closed, right? It was not the case in any of the upgrades.

With Ubuntu 9.10, this doesn't happen to me.

This bug is very annoying.

[Frank Mehnert]

What do you mean by With Ubuntu 9.10, this doesn't happen to me?

As you told that a VBoxSVC instance was even running after you turned your PC on without having started a VBox session I still wonder how this can happen. Do you have any script running doing VBoxManage calls?

[Simón]

Replying to frank:

What do you mean by With Ubuntu 9.10, this doesn't happen to me?

With VirtualBox previous versions, in Ubuntu 9.10, I never had this problem.

As you told that a VBoxSVC instance was even running after you turned your PC on without having started a VBox session I still wonder how this can happen. Do you have any script running doing VBoxManage calls?

Right now, I just turn on the computer and without I execute any VirtualBox Machine:

$ ps aux|grep virtualbox
...
xxx     9463  0.0  0.0  12256  3632 ?        S    15:12   0:00 /usr/lib/virtualbox/VBoxXPCOMIPCD
xxx     9472  0.0  0.1  22356  6488 ?        Sl   15:12   0:00 /usr/lib/virtualbox/VBoxSVC --pipe 4 --auto-shutdown
....

Wait! I just remember one thing: Could this problem be produced by "preload"?

[Simón]

I have searched, in Google and here, possibles conflicts between preload and VirtualBox but I haven't found nothing. The problem should be other, no?

Now it shows:

$ ps aux|grep virtualbox
xxx     7625  0.0  0.0  12256  3632 ?        S    Jun29   0:00 /usr/lib/virtualbox/VBoxXPCOMIPCD
xxx     7634  0.0  0.1  22360  6492 ?        Sl   Jun29   0:03 /usr/lib/virtualbox/VBoxSVC --pipe 4 --auto-shutdown

[Frank Mehnert]

It is very easy to find out of the preload is responsible for auto-starting of the VBoxSVC daemon: Right after you powered on your computer, do

sudo cat /proc/`pidof VBoxSVC`/status | grep PPid

. The resulting PPid is the process ID which started the VBoxSVC daemon. I assume it is the preload daemon.

[Simón]

I don't think so:

$ sudo cat /proc/`pidof VBoxSVC`/status | grep PPid
PPid:	1

  PID TTY      STAT   TIME COMMAND
    1 ?        Ss     0:00 /sbin/init

$ sudo ps aux | grep preloa
root      2216  0.7  0.1   7084  5140 ?        SNs  10:14   0:41 /usr/sbin/preload -s /var/lib/preload/preload.state

[Frank Mehnert]

Well, that's still no prove. The easiest way to check would be if you uninstall preload and then check if VBoxSVC is still running after you rebooted your computer.

[Simón]

Replying to frank:

Well, that's still no prove. The easiest way to check would be if you uninstall preload and then check if VBoxSVC is still running after you rebooted your computer.

It isn't preload problem. I have uninstalled it, I reboot my PC and...

$ ps aux|grep virtualbox
xxx     2785  0.0  0.0  12256  3636 ?        S    13:59   0:00 /usr/lib/virtualbox/VBoxXPCOMIPCD
xxx     2796  0.0  0.1  21468  6464 ?        Sl   13:59   0:00 /usr/lib/virtualbox/VBoxSVC --pipe 4 --auto-shutdow

Any solution for this problem?

[Simón]

Origin of problem detected: plugin VirtualBox of Kupfer (​kupfer).
Reported in its launchpad: ​https://bugs.launchpad.net/kupfer/+bug/603802