Well, this was a bit a tricky one to nail as I did not have any older version of the 'virtualbox-ose.tcz' extension for comparison. So I had to use the generic 32-bit builds from the VirtualBox download page (like
this one here) and compare it against it's older versions. As it turns out the reported USB issue had already started in v4.0.6 and could be reduced down to the problem that
VBoxManage list usbhost (when executed as user 'tc') reported '<none>' whilst running it as 'root' (or as user 'tc' in v4.0.4 and presumably beforehand) produced a meaningful output. The changelog mentioned several USB related bug fixes since v4.0.4 so there was any chance that one of those would have caused this regression.
I therefore embarked on a series of more tests and further careful comparison of the three packages lead to the following code snippet from a file called 'vboxdrv.sh'. These few lines were first added in v4.0.6 and received a minor correction in v.4.0.8:
# Create the /dev/vboxusb directory if the host supports that method
# of USB access. The USB code checks for the existance of that path.
if grep -q usb_device /proc/devices; then
mkdir -p -m 0750 /dev/vboxusb 2>/dev/null
chown root:vboxusers /dev/vboxusb 2>/dev/null
fi
And indeed replicating those commands with 'virtualbox-ose.tcz' installed and manually creating a '/dev/vboxusb' directory (with the correct permission and ownership) required just a logout/login sequence (to pick up the 'vboxusers' group membership for user 'tc') for the
VBoxManage list usbhost command to succeed. Not only that, but the tested USB devices were indeed afterwards available in the VM and working as expected.
I guess it is for the extension maintainer to decide whether these additional commands should be included in the extension startup file (i.e. '/usr/local/tce.installed/virtualbox-ose') or in the "vbox driver" startup script (i.e. /usr/local/etc/init.d/vboxdrv').
Over the course of this investigation I encountered a few things that might be worth sharing as it could help other users in the future:
- The installation of the VirtualBox Extension Pack (e.g. to be able to test USB 2.0 devices) failed for me initially. I then had to fix the complaint by FILE=/usr/local/lib/virtualbox/VBoxExtPackHelperApp ; sudo cp -a /tmp/tcloop/virtualbox-ose${FILE} $FILE and was then able to install it (as user 'root') either through the GUI or the CLI (e.g. via sudo VBoxManage extpack install Oracle_VM_VirtualBox_Extension_Pack-4.0.8-71778.vbox-extpack).
I believe this means that this particular file needs to be added to those that are already being copied in the extension startup script. - There are ways to avoid the mildly annoying logout/login sequence to pick up the added group membership (i.e. 'vboxusers') when installing the extension for the first time: for me su -p -c sh tc worked. But this is more for users who actually understand what this command does (as all other shells are still running without the added group, and one would need to also execute 'wbar.sh' for the WBAR to pick up the change which would only then allow clicking the VBox icon and expecting that the resulting 'VirtualBox' GUI process to have picked up the added group as well). Therefore it looks to me that the advice to logout and login when installing 'virtualbox-ose.tcz' for the first time (or after manually adding the '/dev/vboxusb' directory until the extension is fixed) remains valid for the majority of users.
- Here are the steps that I undertook to use a generic Linux build from the VirtualBox download page (apart from downloading said file):
tce-load -wi compiletc linux-headers-$(uname -r) as during the installation the kernel modules will have to be build from source,
tce-load -wi Xorg-7.5 SDL glib2 OSS to satisfy the applications dependencies (note: 'glib2' is not required if one does not need the 'VirtualBox' GUI and is happy to just use 'VBoxManage' to define and control VMs and 'VBoxSDL' to start them, 'OSS' is only needed if one wants to use sound in the VMs and one then needs to select it in the VM configuration, 'alsa' can be used as an alternative on the host instead of 'OSS', BUT do not install both!!),
sudo chown root:root /opt to work around an otherwise fatal problem with the application as ownership of 'root:staff' won't do it,
one could then install the pre-build application (e.g. via sudo sh VirtualBox-4.0.8-71778-Linux_x86.run) into '/opt' and would have to add the group membership (e.g. via sudo addgroup -S vboxusers ; sudo addgroup ${USER} vboxusers) and fix the '/dev/vboxusb' problem (e.g. via sudo chown -R root:vboxusers /dev/vboxusb) to be able to undertake some testing.
BTW, it appears that several of the last few commands are required as an installation script uses the possibly less frequently used 'groupadd' command instead of the 'addgroup' command that BusyBox supports. I'll try to raise a bug report with VBox about this, but it is certainly not a high priority one.