VirtualBox guest additions explicitly relies upon 'gksu' for Linux -> fixed as of Apr-4-2011

[muz]

VirtualBox 3.0.12-r54655

Using the VBoxGuestAdditions.iso that comes with this version, there is an autorun.sh script in the root of the media which automatically detects the guest and runs the appropriate executable accordingly.

On line 39 of this file, if the guest is detected to be Linux, then it executes a command pre-fixed with gksu.

This relies upon the guest having gksu being installed, which is rather naive. Ideally, it should not rely upon this Gtk++ frontend as not all guests will have this. A prime example being Kubuntu (which uses KDE).

A workaround for now is to manually execute the appropriate installer, but this should not be needed to be done on the user's behalf.

[frank]

You tell us that we are naive so you surely have a proper suggestion which tools to test for. Or better a pointer where the whole autostart mechanism for recent Linux distributions (Ubuntu, Fedora, openSUSE) is described. Because we didn't find such a standard.

[ToddAndMargo]

Hi All,

Vbox 3.1.4

Line 39 is nailing me too. As far as I can research it, no release of Fedora Core (FC) has gksu on it. (I do not know why, it is a cool utility.) For my FC12, I had to download and install gksu-2.0.0-1.el5.rf.i386.rpm and libgksu-2.0.5-1.el5.rf.i386.rpm from RPM Forge. Note that these are both Enterprise Linux RPM's. A bit weird that they would support gksu in Enterprise but not FC.

Anyway, I would appreciate it if you guys would find a way around this in your script. Would

su root -c "$path/VBoxLinuxAdditions-$arch.run"

work? If you need the roots password, you could prompt for it with "zenity", which does exist in raw Fedora Core 12. You could do a test to see if gksu exists and operate as normal. And if not, pop a zenity box asking for the roots password, then use the su command.

# execute the installer
if test "$ostype" = "Linux"; then
    if test -f "$path/VBoxLinuxAdditions-$arch.run"; then
      if [ -f /usr/bin/gksu ]; then
         exec gksu /bin/sh "$path/VBoxLinuxAdditions-$arch.run"
      elsif [ -f /usr/bin/zenity ]; then
         rootpwd=zenity ......
         su root -c "$path/VBoxLinuxAdditions-$arch.run" < $rootpwd
      else
         echo "Please install gksu and/or zenity"
         exit 2
      fi
    fi

Many thanks, -T

[iiaiiappa]

This needed to be fix. It is an impediment.

To install virtualbox guest addition in Kubuntu 10.10

sudo apt-get update
sudo apt-get remove virtualbox-*
sudo apt-get install build-essential linux-headers-$(uname -r)
sudo apt-get install virtualbox-ose-guest-x11
sudo reboot

source:  http://destefano.wordpress.com/2010/10/11/virtualbox-guest-meerkat-maverick/

[salalgar]

You could use xdg-su. It's the standard tool.  http://portland.freedesktop.org/xdg-utils-1.0beta1/xdg-su.html This tool will use the native frontend at Gnome, KDE OR xfce and have fallbacks for other enviroments.

The command for the autorun will be

exec xdg-su -c "/bin/sh $path/VBoxLinuxAdditions-$arch.run"

And you could check if is available before try to use it and fallback in gksu.

I have tested it at KDE at openSUSE 11.3  http://i51.tinypic.com/24xl5og.png

[frank]

Just had a short look at Debian: xdg-utils is there but it does not contain xdg-su (neither on 5.0/Lenny nor on 6.0/Squeeze).

[dveeden]

On RHEL6 gksu is not available, but pkexec (PolicyKit) is available.

[Technologov]

Added myself as CC.

-Technologov

[Technologov]

Tested v4.0.5 r71151, and while it shows the "su" dialog on both RHEL5 (text mode) and RHEL6 (GNOME mode), it silently exists afterwards.

-Technologov

[michael]

You might try the test build at

 http://www.virtualbox.org/download/testcase/VBoxGuestAdditions-r71184.iso

As usual, use at your own risk etc.

[Technologov]

Tried: VBoxGuestAdditions-r71184.iso

autorun.sh now runs on RHEL6, but still quietly exits on RHEL5.

[Technologov]

BTW: you can upload me only "autorun.sh" so I can test it quickly across all distros.

[michael]

Just copy "autorun.sh", "runasroot.sh" and "VBoxLinuxAdditions.run" from the ISO image, put them in a directory of your choosing on a VM of your choosing and run "autorun.sh" in that directory.

[michael]

Alexey, we were unable to reproduce the problem you mentioned in comment 12 on CentOS and OEL 5 guests here. If you want to help us track down the problem, you could copy the files into a writeable directory as I described in comment 13 and add the line "set -x" near the top of autorun.sh and runasroot.sh (after the #!/bin/sh line). You should then get more information than you ever wanted to know about what is and what is not being done by the scripts on the console.

[Technologov]

This command crashes the "gnome-terminal" on RHEL 5.5:

exec /usr/bin/gnome-terminal --title 'VirtualBox Guest Additions installation' -x ./runasroot.sh --has-terminal 'VirtualBox Guest Additions installation' '\./VBoxLinuxAdditions\.run --xwin' 'Please try running "./VBoxLinuxAdditions.run" manually.'

[Technologov]

If running from RHEL-5.5-KDE, it starts gnome-terminal (why?), and I get:

exec /usr/bin/gnome-terminal --title 'VirtualBox Guest Additions installation' -x ./runasroot.sh --has-terminal 'VirtualBox Guest Additions installation' '\./VBoxLinuxAdditions\.run --xwin' 'Please try running "./VBoxLinuxAdditions.run" manually.'

(gnome-terminal:3458): Gdk-CRITICAL : gdk_gc_get_colormap: assertion `GDK_IS_GC (gc)' failed

If running from GNOME, it just silently exits.

-Technologov

[Technologov]

At the very least I expect to see "konsole" on KDE, rather than "gnome-terminal".

[michael]

Is gnome-terminal installed on KDE systems like RHEL-5.5-KDE by default? We currently search for gnome-terminal, konsole and xterm in that order.

[Technologov]

Hmm... usually yes, installed.

[Technologov]

KDE 3.x: /sbin/pidof -x kdesktop >/dev/null && export DESKTOP=kde3

GNOME 2.x: /sbin/pidof -x gnome-panel >/dev/null && export DESKTOP=gnome2

If no X11: if test "$DISPLAY" == ""; then DESKTOP= fi

-Technologov

[Technologov]

KDE 4.x: /sbin/pidof -x kdeinit4 >/dev/null && export DESKTOP=kde4

[Technologov]

...nope... for KDE 4.x I am wrong... "kdeinit4" process created by *any* KDE4 application, not just by KDE4 desktop.

[Technologov]

But using Konsole doesn't helps either, it still exits terminal on this command:

exec /usr/bin/konsole --title 'VirtualBox Guest Additions installation' -e ./runasroot.sh --has-terminal 'VirtualBox Guest Additions installation' '\./VBoxLinuxAdditions\.run --xwin' 'Please try running "./VBoxLinuxAdditions.run" manually.'

[Technologov]

KDE 4.x: /sbin/pidof -x kwrapper4 >/dev/null && export DESKTOP=kde4

[michael]

Here CentOS 5 i386 GNOME auto-mounts CDs noexec. When I remount it exec I can run autorun.sh from Nautilus. (I have a couple of local changes that are probably not relevant.) The error you reported doesn't sound like something related to the Additions - is that a more or less clean guest installation?

[Technologov]

Yes, clean install of RHEL 5.5.

[Technologov]

REOPENED for v4.1.6.

Unfortunately this is still broken with VBox 4.1.6. All openSUSE guests and Debian fail to start from Autorun.

-Technologov

[frank]

Very unlikely. We didn't change anything in the installer code since a few releases.

[Technologov]

True -- this is NOT a regression. Just some distros were failing back then, and were never fixed - e.g. openSUSE of all versions (10.2...11.4).

[Technologov]

A large part of this autorun issue is KDE4 Bug 286162:  https://bugs.kde.org/show_bug.cgi?id=286162

(it explains, why all modern openSUSE's failed in "automatic install" test)

-Technologov