-   Slackware (
-   -   VirtualBox USB devices history effect: fstab and udev rules (

catkin 11-06-2010 06:23 AM

VirtualBox USB devices history effect: fstab and udev rules
Hello :)

Further to this LQ thread I have investigated further and found a persistent "history effect". AFAIK this is specific to Slackware hence posting in this sub-forum rather than in the Virtualization forum.

After a default installation (Slackware64 13.1 and VirtualBox 3.2.8 but has been seen with earlier versions) the VM's host window's Devices -> USB Devices list is greyed out.

The problem can readily be fixed by adding a usbfs line to fstab but it should not be necessary; udev should do the job. And udev does do the job if /etc/udev/rules.d/10-vboxdrv.rules is renamed as 91-vboxdrv.rules (that moves it to the end of the lexical ordering) and the fstab line is removed and the host is rebooted.

This solution suggests that some inter-action amongst the udev rules is causing the problem. The problem rule(s) could be identified by moving <nn>-vboxdrv.rules within the lexical ordering until shifting it just one position triggers the problem.

Now for the persistent history effect. After renaming to trigger failure (say 10-vboxdrv.rules) and then renaming to a previously working name (say 55-vboxdrv.rules) it still fails, even after reboot! The persistent history effect is removed by restoring the fstab line, rebooting, removing the fstab line and rebooting.

Simulating reboot effects by re-initialising udev rules (udevadm control --reload-rules), usbfs (forgot to umount, ran commands from rc.S to mount) and VirtualBox (/etc/rc.d/rc.vboxdrv restart) did not remove the history effect but a full reboot did.

I have no idea what file change(s) are storing the history effect.

Mostly I'm publishing this in case it helps anybody or in case someone can suggest ways of removing the history effect without rebooting. At the current rate of progress it's going to take a long time for me to home in on the problem rule and maybe find a fix.

Meanwhile there's an effective workaround.



mRgOBLIN 11-07-2010 01:34 AM

What about if you "umount usbfs" and comment out the block in rc.S that mounts it?

This works for me and I have no fstab entry for usbfs.

catkin 11-07-2010 01:15 AM


Originally Posted by mRgOBLIN (Post 4151617)
What about if you "umount usbfs" and comment out the block in rc.S that mounts it?

This works for me and I have no fstab entry for usbfs.

Thanks mRgOBLIN :)

Doesn't that cause any problems with USB devices that are used by the host? I'm not clear about what usbfs is and netsearching didn't find any explanations but AFAIK it's a virtual file system providing information about USB devices so removing the rc.S code that mounts it would prevent that information being made available ... only guessing :confused:

Either which way, I'll certainly try unmounting the usbfs when trying to re-initialise without a reboot (intended to do that before but overlooked).

The rc.S code suggests that the only effect of having the usual VirtualBox usbfs line in fstab is to set the usbfs group and permissions -- otherwise rc.S mounts usbfs at /proc/bus/usb anyway, with default group and permissions.

I'll experiment next time it stops working which will likely be soon -- I've just renamed to 39-vboxdrv.rules which is before 40-usb_modeswitch.rules (a likely culprit?) and close to the beginning of the ordering.

catkin 11-07-2010 09:48 AM

It's working OK with 39-vboxdrv.rules so I'm going to have to leave it there for a while because previous tests didn't fail immediately.

All times are GMT -5. The time now is 06:35 AM.