Could not open /proc/bus/usb/devices

[TJ]

On Gutsy 64-bit using qemu/kvm (also VirtualBox and, I believe, VMWare) and the "-usb" switch no USB devices are available since qemu/kvm looks for the description of them in the 'devices' file of a usbfs mount at

/proc/bus/usb/

but the code previously providing the usbfs mount that is created at start-up via /etc/rcS/S11mountdevsubfs.sh --> /etc/init.d/mountdevsubfs.sh was commented out. The USB devices are now reported at

/dev/bus/usb/

but currently there is no usbfs file-system mounted/linked there to provide the 'devices' text-file.

qemu/kvm reports:

qemuctl -qemu vdeq kvm -boot c -m 512 -hda /home/all/VirtualMachines/WindowsXP-SP2.ovl -net nic,vlan=0 -soundhw es1370 -usb -net vde

info usbhost
Could not open /proc/bus/usb/devices

$ ls -l /proc/bus/usb
total 0

WORKAROUND:
To re-enable it edit the file '/etc/init.d/mountdevsubfs.sh' and uncomment the code after line 40 so it reads:
 # Magic to make /proc/bus/usb work
  #
  mkdir -p /dev/bus/usb/.usbfs
  domount usbfs "" /dev/bus/usb/.usbfs -obusmode=0700,devmode=0600,listmode=0644
  ln -s .usbfs/devices /dev/bus/usb/devices
  mount --rbind /dev/bus/usb /proc/bus/usb
Execute the script manually to enable the change before a system reboot:
$ sudo /etc/init.d/mountdevsubfs.sh start

[Christopher Blay (blayde)]

would making a symbolic link to /sys/bus/usb from /proc/bus/usb help or just screw everything up?

[Christopher Blay (blayde)]

alright, i take back my previous comment (i learned something new today). anyways, would it be possible for whoever maintains this package to add TJ's patch and update the repos?

[TJ (tj)]

Your initial comment made me smile - it was the first thing I tried. When I realised that wouldn't work I got smarter and did

mount --bind /sys/bus/usb /proc/bus/usb

and felt mighty pleased it worked! However qmeu/kvm still couldn't find any devices and I realised it was because in

/sys/bus/usb/devices all the device-links are relative, and begin ../../../devices Unfortunately, in the /proc/bus/usb tree that takes us to /proc/devices which is a regular file and already exists - drat, foiled again!

If other's can confirm this is a problem on 32-bit and 64-bit qemu and kvm I'll post apply the patch and post an SRU debdiff.

[TJ (tj)]

There is a work-around that re-enables /proc/bus/usb/devices:

Support for /proc/bus/usb/* was removed in the initscripts package (part of sysvinit), as per this changelog entry:

sysvinit (2.86.ds1-14.1ubuntu22) gutsy; urgency=low

  * Drop /proc/bus/usb again; software should all be ported to check
    /dev/bus/usb first by now.

 -- Scott James Remnant <email address hidden> Wed, 11 Jul 2007 13:47:24 +0100

To re-enable it edit the file '/etc/init.d/mountdevsubfs.sh' and uncomment the code after line 40 so it reads:

 # Magic to make /proc/bus/usb work
 #
 mkdir -p /dev/bus/usb/.usbfs
 domount usbfs "" /dev/bus/usb/.usbfs -obusmode=0700,devmode=0600,listmode=0644
 ln -s .usbfs/devices /dev/bus/usb/devices
 mount --rbind /dev/bus/usb /proc/bus/usb

Execute the script manually to enable the change before a system reboot:

$ sudo /etc/init.d/mountdevsubfs.sh start

I'm adding the sysvinit package to this bug-report since the changelog entry says applications should now use /dev/bus/usb, but it seems that usb is the only 'bus' using that location. Everything else uses /sys/bus/. Therefore it directly causes the qemu/kvm problem. It seems illogical to require all applications that access USB to be patched for this.

There's a related bug report for VirtualBox with a comment by Scott, but no rationale to why it was done.

Bug #151585 "USB Devices unrecognised by virtualbox (/proc/bus/usb missing)"

[Scott James Remnant (Canonical) (canonical-scott)]

Support for /proc/bus/usb has been dropped because it is racey, and permissions are difficult to set -- compared with /dev/bus/usb which is maintained by udev and doesn't have these issues.

Ubuntu is not the only distribution to have dropped it.

If your software is using /proc/bus/usb, it is broken -- you've had over a year to change it, and you've failed to do so. Please change your software to use /dev/bus/usb now.

I've rejected your sysvinit bug; this is deliberate and is definitely not a bug.

Also your assertion about using /sys is entirely bogus - no devices exist under /sys.

[TJ (tj)]

Scott, thanks for the explanation. When I'd re-aimed kvm at /sys/bus/usb/ I hadn't realised that it looks a for a file 'devices'. I thought it was looking for the base of a directory-tree containing the devices, which is what /sys/bus/usb/devices is.

I'm not sure who is primary maintainer at Ubuntu - several people are listed as adding patches, and it's a MOTU package. I'm an end-user that wants the fix.
I've withdrawn the previous patch and created patches for kvm and qemu that use /dev/bus/usb/ and attached the debdiffs for Hardy and Gutsy-proposed here.

[TJ (tj)]

These patches fix an issue where qemu/kvm expects to find the USB devices file at /proc/bus/usb/devices and reports an error when started with the -usb flag as result. The location was changed in July as a result of a patch to sysvinit and is now /dev/bus/usb/devices.

[TJ (tj)]

This is the kind of output to expect from the kvm/qemu debug shell (easily accessible when using qemuctl). The attachment is a screen-shot of qemuctl after doing Connect > USB > Renew.

(qemu) show usbhost
  Device 4.2, speed 12 Mb/s

    Class e0: USB device 044e:300d, UGX

  Device 2.8, speed 480 Mb/s

    Hub: USB device 04cc:1521

  Device 2.13, speed 480 Mb/s

    Class 00: USB device 07ab:fcc7, Freecom Mobile Drive

  Device 2.9, speed 480 Mb/s

    Hub: USB device 05e3:0606, USB2.0 Hub

  Device 2.12, speed 480 Mb/s

    Class 00: USB device 058f:6362, Mass Storage Device

  Device 2.11, speed 480 Mb/s

    Class 00: USB device 05ac:120a, iPod

  Device 2.10, speed 12 Mb/s

    Class 00: USB device 054c:002c, USB Floppy Drive

  Device 2.3, speed 480 Mb/s

    Class ef: USB device 05ca:1836

[Emmet Hikory (persia)]

KVM Uploaded to hardy. Thanks. Waiting on patch refresh for qemu.

[Chris Halse Rogers (raof)]

We'd really prefer your original one-line patch to the new version (although qemu upstream would probably be interested in the new, general patch). We don't have to care about kernel backwards-compatibility :).

Also, you have the wrong version numbers for your gutsy-proposed debdiffs. The versioning of SRUs are a bit different to normal development versioning. For these packages I'd suggest 0.9.0-2ubuntu4.1 for qemu and 1:28-4ubuntu2.1 for kvm. (One of the reasons for the different versioning is to make sure it doesn't conflict with the versioning in the development release - otherwise you could have a 0.9.0-2ubuntu5 in gutsy-updates and a *different* 0.9.0-2ubuntu5 in hardy).

[TJ (tj)]

And there I was thinking packaging a bug-fix was a quick thing! So far I've spent 5 minutes creating the source-code patch and several hours messing about with packaging!

[Daniel Hahler (blueyed)]

Reported also for usbview in bug #151585.

[Martin Pitt (pitti)]

The three gutsy-proposed patches for usbview, qemu, and kvm look good, please go ahead and get them uploaded. Please upload them into hardy first, though.

[Michael Bienia (geser)]

Are you sure that the patch for usbview is correct? I don't have a /dev/bus/usb/devices file here. I have only subdirs in /dev/bus/usb.

[Emmet Hikory (persia)]

The list that was /proc/bus/usb/devices is no longer available, either in /dev or in /sys. The information must be gleaned in another manner.

[Daniel Hahler (blueyed)]

Sorry, I've only applied the logic of the kvm patch, which should be invalid then, too!?

Apparently I still have the "Magic to make /proc/bus/usb work" uncommented in /etc/init.d/mountdevsubfs.sh and the "ln -s .usbfs/devices /dev/bus/usb/devices" from there seems to create this file.

It appears that for usbview the whole "LoadUSBTree stuff" would have to get rewritten to use the directory/filesystem layout instead of the the "devices" file. I'm not going to work on this though.

[Emmet Hikory (persia)]

My test of KVM worked with the patch: I don't believe it depends on the presence of the devices file. usbview may be different (I have not investigated this package).

[TJ (tj)]

Emmet is, unfortunately, correct. I had forgotten to re-disable the section in /etc/init.d/mountdevsubfs.sh too.

The devices file itself is created when a usbfs mount is created, using:

$ mkdir .usbfs
$ sudo mount -n -t usbfs -obusmode=0700,devmode=0600,listmode=0644 usbfs .usbfs
$ ls .usbfs
001 002 003 004 005 devices
$ cat devices
$ cat .usbfs/devices

T: Bus=05 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=480 MxCh= 8
B: Alloc= 0/800 us ( 0%), #Int= 0, #Iso= 0
D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=0000 ProdID=0000 Rev= 2.06
S: Manufacturer=Linux 2.6.22-14-generic ehci_hcd
...

Unless there is some over-arching reason *not* to use usbfs then the best solution is, I think, to amend /etc/init.d/mountdevsubfs.sh so instead of:

 #
 # Magic to make /proc/bus/usb work
 #
 #mkdir -p /dev/bus/usb/.usbfs
 #domount usbfs "" /dev/bus/usb/.usbfs -obusmode=0700,devmode=0600,listmode=0644
 #ln -s .usbfs/devices /dev/bus/usb/devices
 #mount --rbind /dev/bus/usb /proc/bus/usb

we have

 #
 # Magic to give virtual machines (KVM/QEMU, VirtualBox, VMWare, etc) access to host USB devices
 #
 mkdir -p /dev/bus/usb/.usbfs
 domount usbfs "" /dev/bus/usb/.usbfs -obusmode=0700,devmode=0600,listmode=0644
 ln -s .usbfs/devices /dev/bus/usb/devices

This could be added as an additional stanza (which takes the solution back to amending the "sysvinit" package).

The alternative is to add a complete new set of scripts and links, either:

/etc/rc.S/S12mountdevusbfs -> /etc/init.d/mountdevusbfs.sh

or

/etc/rc2.d/S20mountdevusbfs -> /etc/init.d/mountdevusbfs.sh

That, coupled with the alteration to KVM/QEMU would solve the issue.

Comments please?

[TJ (tj)]

Emmet. I just realised you seem to be suggest it worked with the patch (for KVM on Hardy wasn't it?) but the patch simply replaces /proc/bus/usb/ with /dev/bus/usb/ but there is no 'devices' file link there *unless* the uncommented magic in /etc/init.d/mountdevsubfs.sh (or equivalent) has created a usbfs and linked /dev/bus/usb/devices into it.

I've tested the KVM Gutsy patch here. Without mounting the usbfs (using my new mountdevusbfs.sh script) I get:

$ ls -a /dev/bus/usb
. .. 001 002 003 004 005

info usbhost
Could not open /dev/bus/usb/devices

But once the usbfs is mounted and the 'devices' link created, it works:

$ sudo /etc/init.d/mountdevusbfs.sh start
$ ls -a /dev/bus/usb
. .. 001 002 003 004 005 devices .usbfs

info usbhost
 Device 5.4, speed 480 Mb/s

    Class 00: USB device 0781:5151, Cruzer Micro

  Device 5.3, speed 480 Mb/s

    Class ef: USB device 05ca:1836

  Device 3.3, speed 12 Mb/s

    Class e0: USB device 044e:300d, UGX

Is it possible the Hardy init is creating the usbfs and linking devices, or is there some confusion here?

[perpetualrabbit (perpetualrabbit)]

I have a Trust media center keyboard with builtin trackball. After a reboot, suddenly the trackball responded very sluggish, like with a ball-mouse (not optical I mean) with dirty wheels inside. But it couldn't be dirty yet, it is brand new. I noticed earlier that usbview did not work, but used to under Gutsy. I mounted the /proc/bus/usb filesystem, with mount -t usbfs procbususb /proc/bus/usb and instantly the trackball is working again. Usbview too.

Whatever the thinking is about /proc/bus/usb, the change that was made to it broke my mouse (well trackball) and probably breaks the X window experience for lots of Gutsy users.

Also there should be a better program than just usbview in Gnome to work with usb devices. usbview is very limited. And ugly.

[Saúl Romero (spacetree)]

Hi!

I am new to all this stuff about patching, and i want to ask you some things. I am using ubuntu gustsy gibbon with qemu/kvm and experiencing the described bug:

I followed this guide in order to use the debdiff file from TJ's post (qemu -2ubuntu5 gutsy-proposed debdiff ) : https://wiki.ubuntu.com/UbuntuPackagingGuide/BuildFromDebdiff.

Until the installation of the package it all seemed ok, but if i use qemu alone, my win VM keeps on rebooting. It also keeps on showing the message "Could not open /proc/bus/usb/devices". Same with KVM

What could I have missed? Any help is appreciated. I shall say that a message telling "applying debdiff ..." when i was downloading the source called my attention.

[Brian Pitts (bpitts)]

Reported for lsusb at Bug #159189

[Martin Pitt (pitti)]

I do not see anything to do for ubuntu-sru here. Please get the fixes uploaded and tested in hardy, and attach tested debdiffs for the packages you think should be fixed in gutsy. Feel free to immediately upload clean and obvious patches like http://launchpadlibrarian.net/10207748/kvm_28-4ubuntu3-gutsy.debdiff without prior written approval. After that, please resubscribe ubuntu-sru.

Thank you!

[Emmet Hikory (persia)]

Apparently that patch didn't actually work. Sorry for sitting on this task so long. Open for all takers :)

[Rui Bernardo (epimeteo)]

I was trying to use QEMU with USB in Ubuntu 7.10 Gutsy when I found this bug. I comment out the magic lines in /etc/init.d/mountdevsubfs.sh, started it, but still couldn't use USB in QEMU. Everything inside /proc/bus/usb/ and /dev/bus/usb was owned by root and QEMU couldn't read/write in it. I searched the web for something to change /dev/bus/usb/ and /proc/bus/usb/ permissions. QEMU docs says to "chown -R" all /proc/bus/usb/ and this was a problem since it "doesn't exist".

I found this: http://www.ubuntu1501.com/2007/12/installing-virtualbox-with-usb-support.html and adapted it to QEMU.

Basicaly, I added a new system group called "usbusers", added my username to that new system group and added a line in /etc/fstab setting the GID of /proc/bus/usb. I didn't need to change /etc/udev/rules.d/40-permissions.rules! All the process:

# Edit, uncomment "magic" and start the file /etc/init.d/mountdevsubfs.sh

# Create a system group for usb users:
sudo addgroup --system usbusers
# Output was GID 128

# Add user to usbusers group:
sudo adduser $USER usbusers

# With the lines in /etc/init.d/mountdevsubfs.sh comment out,
# edit /etc/fstab:
sudo nano /etc/fstab

# Add the following line:
# 128 is the GID of the group "usbusers".
none /proc/bus/usb usbfs devgid=128,devmode=664 0 0

# Reboot. After restarting the group owner of the devices were "usbusers":
$ ls -la /proc/bus/usb/
total 0
drwxr-xr-x 7 root root 0 2008-03-11 14:45 .
dr-xr-xr-x 5 root root 0 2008-03-11 14:46 ..
dr-xr-xr-x 2 root root 0 2008-03-11 14:45 001
dr-xr-xr-x 2 root root 0 2008-03-11 14:45 002
dr-xr-xr-x 2 root root 0 2008-03-11 14:45 003
dr-xr-xr-x 2 root root 0 2008-03-11 14:45 004
dr-xr-xr-x 2 root root 0 2008-03-11 14:45 005
-r--r--r-- 1 root root 0 2008-03-11 14:45 devices

$ ls -la /proc/bus/usb/003
total 0
dr-xr-xr-x 2 root root 0 2008-03-11 14:45 .
drwxr-xr-x 7 root root 0 2008-03-11 14:45 ..
-rw-rw-r-- 1 root usbusers 43 2008-03-11 14:45 001

# Eject the USB device in Gnome before using QEMU!
# Run QEMU with the option "-usb" or "-usbdevice host:1234:5678".

This was the way I got this working 100%.

[Daniel Hahler (blueyed)]

Was there really no process during Gutsy (and Hardy nearly already) for these bugs?

Re-opening the sysvinit task:
I'm not affected by it myself, but I wonder why we cannot just enable the magic to make it work by default, from /etc/init.d/mountdevsubfs.sh (code commented out by default):
        #
        # Magic to make /proc/bus/usb work
        #
        mkdir -p /dev/bus/usb/.usbfs
        domount usbfs "" /dev/bus/usb/.usbfs -obusmode=0700,devmode=0600,listmode=0644
        ln -s .usbfs/devices /dev/bus/usb/devices
        mount --rbind /dev/bus/usb /proc/bus/usb

Scott wrote:
> Support for /proc/bus/usb has been dropped because it is racey, and permissions are difficult to set --
> compared with /dev/bus/usb which is maintained by udev and doesn't have these issues.

It does not appear to be really frown to permission issues, because it links to the udev controlled interface.

[Scott James Remnant (Canonical) (canonical-scott)]

Please do not reopen tasks when it has been made clear that the removal was deliberate

[Scott James Remnant (Canonical) (canonical-scott)]

/proc/bus/usb has GONE.

It has been marked deprecated for over a year in multiple Linux distributions, and has been removed by more than one.

Code should be changed to use /dev/bus/usb.

That's all there is to it.

[John Cottier (john-cottier)]

that reminds me of something from Hitch hikers guide to the galaxy ;-)

[Trent Telfer (unnaturalhigh)]

Curious if these proposed patch's have actually been applied to the qemu package in the hardy repository? As to date qemu still does not function properly.

Could not open /proc/bus/usb/devices
Could not add USB device 'host:0fca:0006

Package: qemu
New: yes
State: installed
Automatically installed: yes
Version: 0.9.1-1ubuntu1

[J C Nash (nashjc)]

As far as I can tell, this also affects xsane for some scanners. I've a Canon Canoscan LiDE 60 that used to work fine in Feisty, but now doesn't get found. Since usbview is complaining about /proc/bus/usb/devices, I suspect the same issue. Seems like there's been a long trail on this one. Can we expect a fix soon? As someone who tries to promote Linux and Open Source, bugs like this really take the rug out from under us and send folk rushing to spend $100s with M$.

JN

[J C Nash (nashjc)]

xsane runs as root after making the patch suggested above by Daniel Hahler for mounddevsubfs.sh. This is at least a start, but running as root is 1) dangerous and 2) a nuisance in dealing with files resulting from the scans.

Looks like there's work to do. I'd do it if I were more familiar with usb.

JN

[Anders Häggström (hagge)]

I am an end-user and can confirm this bug is still alive för KVM in Hardy.

I am looking for a workaround to get usb working. I need it!

If there is no workaround availible I hope this issue will be fixed soon! I have tried to uncomment the magic in /etc/init.d/mountdevsubfs.sh but without luck. I only get the following response:

##
usb_host: error - device has no matching configuration
Warning: could not add USB device host:0fce:d0d9
##

How do I get USB to work with KVM in Hardy, please?

[Badiozam (badiozam)]

Having the same problem. I have a CanoScan LiDE that I need to use and even with the patch kvm/qemu refuses to see it.

##
helsing:~$ sudo qemu -M pc -m 1256 -kernel-kqemu -usbdevice host:04a9:2225 -usbdevice host:04e8:326c -usb -hda /home/hamid/helsing-windows -localtime -cdrom /dev/cdrom -net nic,vlan=0 -net user,vlan=0,hostname=emu -smb /media/ERIS -boot c
usb_linux_update_endp_table: Broken pipe
Warning: could not add USB device host:04a9:2225
usb_linux_update_endp_table: Broken pipe
Warning: could not add USB device host:04e8:326c

helsing:~$ ls -la /proc/bus/usb
total 0
drwxr-xr-x 5 root root 120 2008-07-29 09:34 .
dr-xr-xr-x 5 root root 0 2008-07-29 09:34 ..
drwxr-xr-x 2 root root 80 2008-07-29 02:33 001
drwxr-xr-x 2 root root 80 2008-07-29 11:17 002
lrwxrwxrwx 1 root root 14 2008-07-29 09:34 devices -> .usbfs/devices
drwxr-xr-x 4 root root 0 2008-07-29 02:33 .usbfs

helsing:~$ cat /proc/bus/usb/devices

T: Bus=02 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=480 MxCh=10
B: Alloc= 0/800 us ( 0%), #Int= 0, #Iso= 0
D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=0000 ProdID=0000 Rev= 2.06
S: Manufacturer=Linux 2.6.24-19-generic ehci_hcd
S: Product=EHCI Host Controller
S: SerialNumber=0000:00:0b.1
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub
E: Ad=81(I) Atr=03(Int.) MxPS= 4 Ivl=256ms

T: Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=480 MxCh= 0
D: Ver= 2.00 Cls=ff(vend.) Sub=ff Prot=ff MxPS=64 #Cfgs= 1
P: Vendor=04a9 ProdID=2225 Rev= 0.00
S: Manufacturer=Canon
S: Product=CanoScan
C:* #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr=500mA
I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms

T: Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh=10
B: Alloc= 0/900 us ( 0%), #Int= 0, #Iso= 0
D: Ver= 1.10 Cls=09(hub ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=0000 ProdID=0000 Rev= 2.06
S: Manufacturer=Linux 2.6.24-19-generic ohci_hcd
S: Product=OHCI Host Controller
S: SerialNumber=0000:00:0b.0
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub
E: Ad=81(I) Atr=03(Int.) MxPS= 2 Ivl=255ms

T: Bus=01 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 2 Spd=12 MxCh= 0
D: Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=16 #Cfgs= 1
P: Vendor=04e8 ProdID=326c Rev= 1.00
S: Manufacturer=Samsung
S: Product=Samsung ML-2010
S: SerialNumber=3A61BKCY919606V.
C:* #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr= 0mA
I:* If#= 0 Alt= 0 #EPs= 2 Cls=07(print) Sub=01 Prot=02 Driver=usblp
E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=83(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
##

[Shirish Agarwal (shirishag75)]

hi all,
 I can't seem to find any reference to magic anywhere in the .sh script. I'm on Intrepid. Attaching the file, please lemme know what is to be done there.

Its part of the initscripts version 2.86.ds1-59ubuntu2

any guidance on this part would be nice :)

[Matt Zimmerman (mdz)]

openSUSE has a patch at https://bugzilla.novell.com/show_bug.cgi?id=241950 which fixes qemu to use /dev/bus/usb instead of /proc/bus/usb. It doesn't quite apply cleanly to current qemu, but it should be possible to port it without much effort. They may also have a newer version in the package itself.

If someone could get this cleaned up and submitted upstream, and we'll be able to cross qemu (and kvm) off the list of packages affected by this issue.

[TJ (tj)]

I'm working on a patch that will allow legacy support for /proc/bus/usb and current support for /sys/bus/usb. I'm working with kvm userspace git head, which is just after kvm-74. The reason for working with the recent version is the substantial improvements in USB device support introduced with kvm-74, after a QEMU merge.

[TJ (tj)]

I've added sys file-system support to qemu/kvm, but to make it accessible to users it will need a udev group ownership set on /dev/bus/usb/* devices.

I was wondering if "plugdev" would be an appropriate group, or create a new one? I don't think kvm/qemu should have to run as root to access USB devices.

[Matt Zimmerman (mdz)]

On Thu, Sep 04, 2008 at 04:11:02PM -0000, TJ wrote:
> I was wondering if "plugdev" would be an appropriate group, or create a
> new one? I don't think kvm/qemu should have to run as root to access USB
> devices.

I believe we're in the process of deprecating plugdev, so I expect not.

--
 - mdz

[Anders Häggström (hagge)]

When KVM has been installed, the group "kvm" is created. I suspect the group "qemu" is created when you install QEMU, but do not know if this is the case.

One of these groups may be possible to use? KVM/QEMU should of course be run as a separate user, who is a member of any of these groups in a typical installation.

[TJ (tj)]

I've published kvm USB sys file-system enabled packages for Gutsy, Hardy, and Intrepid based on kvm-74 in my PPA.

If people could test them I'd appreciate it. Please read the manual page "man kvm" for information on how to configure the system to allow non-root access to the USB devices.

If the tests don't show any problems I'll investigate back-porting the patch to the version in the Hardy repository, and to the qemu package.

I expect the Intrepid packages will catch up with upstream before release. If not, I'll do a similar patch.

I'm submitting the patch upstream to qemu. If accepted it should be merged into kvm not too long after. Once Ubuntu catches up to a future kvm/qemu release the package-patch can be dropped.

=== changelog ===
kvm (1:74+dfsg-0ubuntu2~ppa1h) hardy; urgency=low

  * Patch 11 Add USB sys file-system support (closes LP #156085).
  * Added USB host setup and usage information to man page.

 -- TJ <email address hidden> Thu, 4 Sep 2008 22:30:00 +0100

kvm (1:74+dfsg-0ubuntu1~ppa1h) hardy; urgency=low

  * New upstream release with new qemu merge that adds better USB support.
  * Removed patch 50_preserve_64bit_sysenter_registers (included upstream).
  * Removed patch qemu_vnc_ext_key_event (included upstream).
  * Added build-depends on unifdef to support header-sync target.
  * Patch 10 fix kernel/Makefile header-sync FTBFS syntax and logic errors.

 -- TJ <email address hidden> Mon, 2 Sep 2008 21:45:00 +0100

[TJ (tj)]

On Thu, 2008-09-04 at 23:15 +0000, Anders Häggström wrote:
> When KVM has been installed, the group "kvm" is created. I suspect the
> group "qemu" is created when you install QEMU, but do not know if this
> is the case.

The problem here is that all hypervisors might want access to the USB
devices (kvm, qemu, virtualbox, etc.). If the device group is
package-specific that will cause all sorts of unwanted and unnecessary
issues for users that work with multiple hypervisors.

It would make sense to have a separate package that all hypervisors can
either depend on or recommend that uses a group specially for the
purpose, and assigns it via a udev rule. "plugdev" might have been good
but if it is being deprecated then some other solution needs to be
found.

[TJ (tj)]

Let's try that again!

The 32-bit PPA builds failed because the debian/rules file had yet another missing clean rule, this time for extboot/. The effect was that as I'm testing on 64-bit "extboot/signrom" was a 64-bit ELF that would, of course, fail on a 32-bit buildd. I failed to test locally in a 32-bit pbuilder, trying to cut corners.

Secondly, I realised I'd made a major programming boo-boo despite knowing better - requesting an allocation of memory in the host USB file-system scan function, forgetting that the function isn't just called once but repeatedly. That would have led to orphaned memory allocations each time a USB scan or open operation occurred - baaad!

I've also changed the logic so it only scans for the USB file-system type the first time. After that it works off stored values.

Uploads to my PPA for Gutsy, Hardy and Intrepid.

=== changelog ===
kvm (1:74+dfsg-0ubuntu2~ppa2h) hardy; urgency=low

  * Fix: update patch 11: Don't detect host USB file-system location more than once.
  * Fix: debian/rules: add missing make extboot clean (fixes signrom failures
       due to previously built binary remaining - which can be for a different
       architecture).

 -- TJ <email address hidden> Thu, 4 Sep 2008 23:30:00 +0100

[Martin Pitt (pitti)]

Hi TJ,

CC'ing the bug again to have a more permanent record of the
discussion. I hope it is ok for you?

TJ [2008-09-04 18:20 +0100]:
> I've finished a sys file-system patch for kvm and qemu that continues to
> support the legacy /proc/ and /dev/ device lists. It is based on a patch
> in the Novell bug-tracker but doesn't rip out legacy support.

What does that mean? I hope not that kvm/qemu are supposed to directly
access USB devices through /sys? (that would be EBW).

> The USB devices in /dev/bus/usb/*/* have root:root permissions.

... by default. E. g. scanners and cameras get ACLs assigned to them
by hal/consolekit, so that the currently active local user session can
access those as well.

> Obviously it wouldn't be a great idea to have VMs running as root so I
> was looking for an existing group that might be used to modify those
> permissions so that kvm/qemu can obtain read/write access to the
> devices. Without it USB support fails.
>
> Matt Zimmerman pointed out 'plugdev' is being deprecated and I didn't
> want to use 'kvm' as that is package-specific.

In fact we want to completely deprecate the (ab)use of groups for
device access:
https://wiki.ubuntu.com/DesktopTeam/Specs/Intrepid/DevicePermissions

So please don't proliferate groups too much. 'kvm' should ideally
disappear as well eventually.

The current two recommended possibilities for providing device access
are:

 - Provide a backend running as root (which can access the devices),
   expose the backend functionality through a D-BUS API (well, could
   be IP or something else as well, but D-BUS is very convenient), and
   control access to the backend through PolicyKit. Then device access
   can be configured with polkit-gnome-authorization (with defaulting
   to something sane, like "local users only"). That's the way e. g.
   mounting internal hard drives through hal works.

 - For pure client-side programs, use the hal ACL management facility:
   /usr/share/hal/fdi/policy/10osvendor/20-acl-management.fdi
   /usr/share/PolicyKit/policy/org.freedesktop.hal.device-access.policy

   The FDI configures which device classes get ACL controlled, and
   assigns access_control.type. The .policy maps that type to a
   PolicyKit privilege, and assigns the default rights.

Please let me know if either of those options are feasible for you.

If you really must use a group for now, then I suppose you coordinate
with Soren, to use a more generic group name than 'kvm'. 'plugdev' is
not appropriate at all, it is meant for hotpluggable block devices,
not virtualization hypervisor access.

Martin

--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)

[Martin Pitt (pitti)]

Hi TJ,

TJ [2008-09-04 18:20 +0100]:
> The USB devices in /dev/bus/usb/*/* have root:root permissions.
> Obviously it wouldn't be a great idea to have VMs running as root so I
> was looking for an existing group that might be used to modify those
> permissions so that kvm/qemu can obtain read/write access to the
> devices. Without it USB support fails.

Oh, hang on, it seems I misunderstood you in my previous reply. You
weren't talking about /dev/kvm, but the actual USB devices, for
propagating them through the kvm guest? In that case you really
shouldn't change anything. If the user can access those USB devices on
the host, then he should equally be able to access them on the guest,
since the kvm process runs under his user account and thus can use the
ACLs?

[Soren Hansen (soren)]

On Fri, Sep 05, 2008 at 09:38:20AM +0200, Martin Pitt wrote:
> What does that mean? I hope not that kvm/qemu are supposed to directly
> access USB devices through /sys? (that would be EBW).

EBW?

[Matt Zimmerman (mdz)]

On Fri, Sep 05, 2008 at 07:41:02AM -0000, Martin Pitt wrote:
> TJ [2008-09-04 18:20 +0100]:
> > The USB devices in /dev/bus/usb/*/* have root:root permissions.
> > Obviously it wouldn't be a great idea to have VMs running as root so I
> > was looking for an existing group that might be used to modify those
> > permissions so that kvm/qemu can obtain read/write access to the
> > devices. Without it USB support fails.
>
> Oh, hang on, it seems I misunderstood you in my previous reply. You
> weren't talking about /dev/kvm, but the actual USB devices, for
> propagating them through the kvm guest? In that case you really
> shouldn't change anything. If the user can access those USB devices on
> the host, then he should equally be able to access them on the guest,
> since the kvm process runs under his user account and thus can use the
> ACLs?

KVM is something of a special case here.

Normally, users access USB devices via a kernel driver which presents an
appropriate device node (e.g. /dev/sd* for mass storage devices),
and sane permissions are set based on that cooked interface.

For KVM USB pass-through, however, it needs access to the raw USB device
(/dev/bus/usb/*/*) so that it can be presented as a virtual device to the
guest OS. These raw USB device nodes are typically owned by root, because
they could be anything and we don't know what the appropriate permissions
should be. The device is released by the kernel driver, and KVM accesses it
exclusively.

Perhaps the raw device node permissions should be set to be the same as the
cooked ones? This would at least avoid tweaking for devices recognized by
the kernel.

Alternatively, we could punt and say that USB pass-through requires root
privileges or manual tweaking of the device node permissions. I'm not sure
to what extent this feature is used in typical KVM usage; I would think it's
mostly useful for reverse engineering and such.

--
 - mdz

[TJ (tj)]

On Fri, 2008-09-05 at 07:41 +0000, Martin Pitt wrote:
> shouldn't change anything. If the user can access those USB devices on
> the host, then he should equally be able to access them on the guest,
> since the kvm process runs under his user account and thus can use the
> ACLs?

The problem is, the user *doesn't* have permissions to the raw device
nodes - they've always been root:root. See Matt's explanation about raw
versus cooked.

On Fri, 2008-09-05 at 08:32 +0000, Matt Zimmerman wrote:
> On Fri, Sep 05, 2008 at 07:41:02AM -0000, Martin Pitt wrot
> KVM is something of a special case here.

KVM, Qemu, VirtualBox, and I suspect some other less well-used
hypervisors. I'm hoping we can find a generic solution so that
hypervisor packages don't conflict.

> For KVM USB pass-through, however, it needs access to the raw USB device
> (/dev/bus/usb/*/*) so that it can be presented as a virtual device to the
> guest OS.

Yes, this is the crux of the issue.

> Perhaps the raw device node permissions should be set to be the same as the
> cooked ones? This would at least avoid tweaking for devices recognized by
> the kernel.

Which cooked ones are you thinking about, Matt? From what I can see the
cooked group/permissions are mostly target-specific (e.g. block, video,
serial) whereas what the hypervisor needs is one group to cover all
device classes.

> Alternatively, we could punt and say that USB pass-through requires root
> privileges or manual tweaking of the device node permissions. I'm not sure
> to what extent this feature is used in typical KVM usage; I would think it's
> mostly useful for reverse engineering and such.

My experience, from watching the number of frustrated users posting in
forums on and off Ubuntu, is that there is a growing number of
non-technical users expecting that a VM guest 'will just work' with
their devices (mice, cameras, tablets, scanners (especially), printers,
etc.), and using the deprecated work-around
in /etc/init.d/mountdevsubfs.sh and commenting out the 'magic' around
line 40.

This is true particularly when the guest is a Windows variant and their
purpose in using the Windows guest is to use the drivers to access a
device (esp. cameras, scanners and printers) that they find problematic
or unsupported in Linux.

This class of non-technical user:

* expect access to their USB devices in the VM guest the same as if it
were running on the the physical machine
* should not be using root access

The way hypervisors and VMs are promoted and talked about creates an
impression that this stuff should 'just work' - its not a small
corner-case away from the sever applications.

I have been trying to avoid a heavy-handed approach of some kind of
root-user proxy server - I can't see how that would be possible anyway,
since raw device access is required and we already have it but it 'would
be nice' to manage permissions so the VM itself isn't run as root.

Hence my suggestion of an optional generic package "vm-usb" that is a
depend or more likely, a recommends, of hypervisor packages like kvm and
whose only task is to install a udev rule that assigns a "vm" group to
the USB device nodes, and adds the group to the system.
Ho...

[Matt Zimmerman (mdz)]

On Fri, Sep 05, 2008 at 03:59:06PM -0000, TJ wrote:
> On Fri, 2008-09-05 at 07:41 +0000, Martin Pitt wrote:
> > Perhaps the raw device node permissions should be set to be the same as the
> > cooked ones? This would at least avoid tweaking for devices recognized by
> > the kernel.
>
> Which cooked ones are you thinking about, Matt? From what I can see the
> cooked group/permissions are mostly target-specific (e.g. block, video,
> serial) whereas what the hypervisor needs is one group to cover all
> device classes.

I was thinking of, for example, USB serial devices (which end up with
'dialout' I believe) and USB storage devices (disk). Then the existing
groups could be used, and would correspond to roughly the same privileges.

> > Alternatively, we could punt and say that USB pass-through requires root
> > privileges or manual tweaking of the device node permissions. I'm not sure
> > to what extent this feature is used in typical KVM usage; I would think it's
> > mostly useful for reverse engineering and such.
>
> My experience, from watching the number of frustrated users posting in
> forums on and off Ubuntu, is that there is a growing number of
> non-technical users expecting that a VM guest 'will just work' with
> their devices (mice, cameras, tablets, scanners (especially), printers,
> etc.), and using the deprecated work-around
> in /etc/init.d/mountdevsubfs.sh and commenting out the 'magic' around
> line 40.
>
> This is true particularly when the guest is a Windows variant and their
> purpose in using the Windows guest is to use the drivers to access a
> device (esp. cameras, scanners and printers) that they find problematic
> or unsupported in Linux.
>
> This class of non-technical user:
>
> * expect access to their USB devices in the VM guest the same as if it
> were running on the the physical machine
> * should not be using root access

I understand, but I'm struggling with how we can grant raw hardware-level
access to these devices (as needed by VMs) without compromising security on
the host. USB is used for a wide range of peripherals, some of which should
not be entrusted to unprivileged users.

> If the raw device nodes in /dev/bus/usb/*/* are so unique in terms of
> permissions then maybe this special-case is justifiable as a user-chosen
> option (recommended but not a default package install) since it is
> addressing a different scenario than the deprecated "plugdev" group?

I'd like to find a way to make this work in the "new world order" first, if
possible. I expect now that we've given him plenty of detail on the use
cases, Martin will have a good suggestion.

--
 - mdz

[TJ (tj)]

On Fri, 2008-09-05 at 17:23 +0000, Matt Zimmerman wrote:
> I understand, but I'm struggling with how we can grant raw hardware-level
> access to these devices (as needed by VMs) without compromising security on
> the host. USB is used for a wide range of peripherals, some of which should
> not be entrusted to unprivileged users.
>
The way I'm thinking, there is no "we" - leave it to the user to decide
whether to grant that permission through the process of installing the
udev rule.
At the moment they install the rule manually if they want user access
to /dev/bus/usb/*/* so a package to do it as a result of "sudo apt get
install ..." is just ensuring the process is bullet-proof.

I'm not advocating a system-default policy but something that makes it
easy for the user to apply the relaxed permission when they make a
conscious decision.

I like the idea of a package since simply by installing/removing it the
permission for any hypervisor to access the devices would be
enabled/denied.

[silvagroup (casaba7339-ubuntu)]

I ma sorry but I am just a dumb user that needs usb for my kvm, and after reading all this I still don't have a clue as to what to do.

It would be nice if it just worked as it's expected to work, that's what 99% of the users expect especially as kvm is the official virtulizer of choice for Ubuntu.

I also recommend a really nice user console like that in vmware server where everything can be set up very easily with out a bunch of cli-ing.

But lacking that, for the average knuckle head user like me what do I need to do to get usb working on my kvm, in as simple a terms as possible.

Thank you.

[TJ (tj)]

I've built kvm-74 with a patch to support the dev file-system natively without any work-arounds. You can get it from my PPA:

https://launchpad.net/~intuitivenipple/+archive?field.name_filter=kvm&field.status_filter=published

Make sure to install the Ubuntu kvm package first since my package currently only contains kvm userspace, not the kernel module.

[Scott James Remnant (Canonical) (canonical-scott)]

On Fri, 2008-09-05 at 08:32 +0000, Matt Zimmerman wrote:

> Perhaps the raw device node permissions should be set to be the same as the
> cooked ones? This would at least avoid tweaking for devices recognized by
> the kernel.
>
They actually should be - if they're not, it's usually an over-eager
bug.

(In recent kernels, the raw device node is just a sub-device of the
cooked one, so anything that matches the cooked should also match the
raw.)

Scott
--
Scott James Remnant
<email address hidden>

[Shirish Agarwal (shirishag75)]

I dunno if the nomination for release for Intrepid is the right thing to do or not, I just wanted to highlight it. So please delete or reverse it if its not the right thing to do :(

I made a point as comment 44

https://bugs.edge.launchpad.net/ubuntu/+source/qemu/+bug/156085/comments/44

This bug has also affected the output coming from a daemon called apcupsd

I made a long thing at

http://sourceforge.net/mailarchive/forum.php?thread_name=511f47f50808030109s4aee5cd3w255b38adc9b88746%40mail.gmail.com&forum_name=apcupsd-users

So I do hope this gets fixed as soon as it can so we users can go back to doing things the way we used to :)

[Danny Wood (danwood76)]

This bug as it stands can be fixed perfectly with the Novell patch (I added the patch manually and it only affects one function in qemu anyway) If you want me to make a patch for the Ubuntu Intrepid version I have no issue in doing that.
I now have fully working USB from within XP under qemu (using the version in the KVM source package)

With regards to Intrepid I believe this patch should be applied before release as this is a regression (although it has regressed and not been fixed from several releases back as can be seen in the 'affects' section above)

[Andreas (afg0510)]

Ubuntu 8.04 server 64bit, vmware-server 1.0.7

After I activated the USB Magic and added a line to fstab the USB devics are now visible to vm guests (e.g. Win2000Pro). Then I noticed that I have 2 sets of folders, one in /dev/bus/usb and a 2nd one in /dev/bus/usb/.usbfs AND after some USB activity, they are no longer identical. Then I made this "Magic hack":

 #
        # Magic to make /proc/bus/usb work
        #
        #mkdir -p /dev/bus/usb/.usbfs
        #domount usbfs "" /dev/bus/usb/.usbfs -obusmode=0700,devmode=0600,listmode=0644
        #ln -s .usbfs/devices /dev/bus/usb/devices
        #mount --rbind /dev/bus/usb /proc/bus/usb

        # Hacked Magic to make /proc/bus/usb work (BETTER?)
        domount usbfs "" /dev/bus/usb/ -obusmode=0700,devmode=0600,listmode=0644
        mount --rbind /dev/bus/usb /proc/bus/usb
        ln -s /dev/bus/usb /dev/bus/usb/.usbfs

Wonder what I screwed up by pointing .usbfs/ back to ../usb/ but it seems to work BETTER that way. For my USB problems he remaining issues look more and more like vmware bugs...

[lnx (nwegener)]

> danwood76 wrote on 2008-10-16:
>This bug as it stands can be fixed perfectly with the Novell patch (I added the patch manually and it only affects one >function in qemu anyway) If you want me to make a patch for the Ubuntu Intrepid version I have no issue in doing that.

Is your patch available? I would like to use it.

[Daniele Cruciani (daniele-smartango)]

when I call
sudo /etc/init.d/mountdevsubfs.sh start
at this line:
domount usbfs "" /dev/bus/usb/.usbfs -obusmode=0700,devmode=0600,listmode=0644

I have output about mount usage, i.e. mount command is wrong, what can I do?

(ubuntu 8.10)

[Danny Wood (danwood76)]

@lnx Here is my patch.
I downloaded the Ubuntu source but it doesn't seem to be complete (I think the ubuntu package relies more on libvirt which doesnt support USB pass through yet)

My patch here is for version 77 of kvm, available here: http://sourceforge.net/project/showfiles.php?group_id=180599
It patches qemu to allow the proper use of the USB pass through option and I have been using it successfully since I patched it (I have a USB programmer that only works with windows).

Save it to the kvm77 directory (where you run the ./configure etc) and run:
patch -p1 < usb-linux.patch
to patch the file.

Then compile as normal, I now have to run my virtual machines from the command line and not through kvm virt manager app, I think this is because of what I said earlier, but its all running perfectly from there and is still fast!

[lnx (nwegener)]

Thank you.

[Daniele Cruciani (daniele-smartango)]

anyone tested kvm78? any fix?

I found that
mount -t usbfs usbfs /proc/bus/usb/
chmod -R a+rw /proc/bus/usb/

make usb work

[Srećko Jurić-Kavelj (jksrecko)]

TJ,

Earlier you said you were just an end user, so I'm wondering if you can upload your kvm packages in official repositories? If not, why don't you assign this bug to someone else? Let's say to Dustin Kirkland, since he uploaded most kvm packages in official repositories?

It's incomprehensible to me that this bug is still opened, more than a year since it was confirmed? Especially when the solution seems so straightforward? And it's already there...

[Michael (michaeljt)]

I wanted to add a comment here as one of the VirtualBox developers. From my point of view, the second solution offered by Martin in comment 53 - using ACLs to make certain devices available - sounds like a good one. However, since the OS probably can't guess in advance which devices the user will want available in a VM, and making all devices available is probably not a good idea, it would be very nice if the user had some way of choosing devices.

Of course, this would only become really useful to us if other distributions did it the same way, but it would be a good start if Ubuntu were to do it :)

[Dustin Kirkland  (kirkland)]

Howdy all,

I've applied the so-called "Novell" patch to kvm-79 in Jaunty. I'm really hoping someone can test the package I've prepared in my PPA and give me some feedback on it.

I'm attaching the debdiff to this bug. Thanks, TJ/danwood76, et al. for the patches along the way. If one or both of you want to tackle me in IRC sometime, I can give you a brief primer on how to submit and actual debdiff, which would probably have helped to get these patches sponsored and integrated more quickly next time ;-)

:-Dustin

[Dustin Kirkland  (kirkland)]

I've tested the kvm patch and it seems to work well. I attached a usb flash disk, and was able to read/write to/from it in the kvm guest.

Note that I did have to adjust the device permissions accordingly. Reading the (lengthy) history above, that is apparently a separate issue that should be dealt with outside of this kvm patch.

I'm requesting sponsorship of this patch, please.

:-Dustin

[Dustin Kirkland  (kirkland)]

Okay, sorry about the blast of status changes... Launchpad did something unexpected to me.

I meant to "decline" the changes for Intrepid for the kvm package. Evidently, Launchpad propagated that decision across ALL of the other packages attached to this bug.

My apologies to other package owners if this stomped on you and your intentions. Feel free to "approve" it, if you so desire.

I also closed the Gutsy tasks associated with this bug. I'm focused on fixing the KVM/QEMU issues in Jaunty, first. After that point, we can open a discussion for an SRU for Hardy, and possibly Intrepid. But before that can happen, I'm going to get this fixed in Jaunty first. And then, we will absolutely need some testing feedback ;-)

:-Dustin

[TJ (tj)]

A few months ago I submitted upstream and had accepted a QEMU patch to support /sys/ as well as the older alternatives (/proc/ and /dev/). That will make its way into KVM when Avi next does a sync with QEMU. I've not had chance to check that status recently but would suspect it'll be in KVM main-line for Jaunty.

[Dustin Kirkland  (kirkland)]

On Thu, Dec 18, 2008 at 9:19 PM, TJ <email address hidden> wrote:
> A few months ago I submitted upstream and had accepted a QEMU patch to
> support /sys/ as well as the older alternatives (/proc/ and /dev/). That
> will make its way into KVM when Avi next does a sync with QEMU. I've not
> had chance to check that status recently but would suspect it'll be in
> KVM main-line for Jaunty.

Hi TJ-

I'm looking at the KVM in Jaunty right now, and it looks like this
patch is currently in there.

Can you please help me understand if this other patch from Novell is
needed in addition? Or is it a "one-or-the-other" deal?
http://launchpadlibrarian.net/18915375/usb-linux.patch

:-Dustin

[TJ (tj)]

On Fri, 2008-12-19 at 03:34 +0000, Dustin Kirkland wrote:
>
> I'm looking at the KVM in Jaunty right now, and it looks like this
> patch is currently in there.
>
> Can you please help me understand if this other patch from Novell is
> needed in addition? Or is it a "one-or-the-other" deal?
> http://launchpadlibrarian.net/18915375/usb-linux.patch
>

The Novell patch is not needed.

I based my patch on combining Robert Schiele's approach with the
existing USB file-system mechanisms so that QEMU/KVM can detect and use
any of them it finds, with the order of preference being
sys-fs, /dev/bus/, or /proc/bus/.

To confirm this the code should show, in part:

 * This code is based on Robert Schiele's original patches posted to
 * the Novell bug-tracker https://bugzilla.novell.com/show_bug.cgi?id=241950
*/
static int usb_host_scan_sys(void *opaque, USBScanFunc *func)

[Daniele Cruciani (daniele-smartango)]

I tried it in Intrepid forcing dependencies, I got:

(qemu) usb_add host:0951:1601
husb: open device 2.5
/dev/bus/usb/002/005: Permission denied

[TJ (tj)]

On Fri, 2008-12-19 at 13:57 +0000, Daniele Smartango wrote:
> I tried it in Intrepid forcing dependencies, I got:
>
> (qemu) usb_add host:0951:1601
> husb: open device 2.5
> /dev/bus/usb/002/005: Permission denied

Daniele, see the discussion on device-node permissions further back
(2008-09-04 onwards).

The unresolved issue is, no decision has been made on how to set
permissions for KVM/QEMU to access the raw device nodes. By default they
are root:root so when KVM/QEMU are run as a regular user the "Permission
Denied" message is to be expected.

Running KVM/QEMU as root isn't the most desirable solution either.

Until a decision is made on how best to support this the user will need
to choose a method to set permissions manually to allow the user access
to the raw devices.

In my PPA package I added manual instructions to the man-page. I'll
quote it here (Dustin - maybe this is worth adding to the current
lvm/qemu man pages until the permissions issue is resolved?):

USING USB DEVICES
       kvm-74 introduced much-improved support for USB host devices, but still expected to find
       them in /proc/bus/usb/ which has been deprecated for over a year. The Ubuntu patches added
       in 1:74+dfsg-0ubuntu2 provide support for /sys/bus/usb/devices/ and /dev/bus/usb/devices
       discovery, and connection via /dev/bus/usb/*/*

       kvm must be started with the "-usb" option. From the kvm monitor console (Ctrl+Alt+2 when
       the VM Window has grabbed focus - Ctrl+Alt+1 to return to the VM) USB host devices can be
       discovered using:

       info usbhost

       The devices can be added to the guest using, for example:

       add_usb host:5.3

       If the guest is running as non-root the permissions to /dev/bus/usb/*/* will need altering
       to allow the VM read/write access to the USB devices.

       Create a new group "vm" and add users that require USB access for VMs to it:

       sudo addgroup vm
       sudo addgroup $USER vm

       Log-out/log-in to effect the new group membership.

       Add a udev rule to assign USB devices to the vm group:

       # Virtual Machine hypervisor access to USB devices
       SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", GROUP="vm"
       SUBSYSTEM=="usb_device", GROUP="vm"

       Save the file as /etc/udev/rules.d/41-vm-usb.rules and reload udevd:

       sudo /etc/init.d/udev restart

       The guest virtual machines should now be able to access the USB devices without root priv‐
       ileges.

[Dimitrios Symeonidis (azimout)]

Upgrading to triaged-medium for Jaunty, to get some developer attention. This package has been broken for more than a year now, are we going to fix it or remove it? (I can't believe gregk-h is the maintainer of this!!!)
http://www.kroah.com/linux/usb/

[TJ (tj)]

Jaunty's kvm-83 includes my USB sys-fs patch from upstream QEMU and therefore no longer requires the /proc/bus/usb/ work-arounds.

I've opened a new report to deal with the permissions issue: bug #331331 "Non-root guest doesn't have permission to access sys-fs USB devices"

[Matt Zimmerman (mdz)]

Marking kvm as fixed in Jaunty per TJ's comment

[Michael (michaeljt)]

FWIW, this is fixed upstream in VirtualBox 2.1.2.

[mlg7 (mlg7)]

For end users like me:
the workaround suggested at
https://bugs.launchpad.net/ubuntu/hardy/+source/usbview/+bug/156085/+viewstatus
worked for me, at least, usbview works again.

>To re-enable it edit the file '/etc/init.d/mountdevsubfs.sh' and uncomment the code after line 40
(4 lines, up to the closing brace)

[mlg7 (mlg7)]

to Scott (and others):
>/proc/bus/usb has GONE.
>It has been marked deprecated for over a year...
>Code should be changed

I will tell thou a clever thing, only don't get offended.

With each such incompatibility you lose 3% of users.
If you have only two users, it's not even a whole number,
so there is no problem. For 30 users, it may be explained
as a personal choice. And if you were employed by a
capitalist with at least 1K customers, that capitalist
would wash your brains after 2nd found incompatibility.
But you are a free developer...
Well, each lost user is extra $90 in Bill Gates' pocket.
Please think, how immoral it is to give away other
people's money to a rich guy!

Now, a real story.
The GCC guys changed the C++ compiler (4.2) so that it is
incompatible with 3.4. Some projects cannot be compiled
(warnings as errors), while others (warnings ignored)
compile but crash at run-time. (Example: SUN's CLDC.)
VMWare tools, another example, also could not be
fully compiled, and the distribution included a broken
package (!). So I tried 8.10 and decided not to use it.
Nor will I recommend it to anybody else. I use an old version.

[Danny Wood (danwood76)]

GCC 4.2 had bugs in it which are fixed in 4.3.
But you can always get the 3 series of the compiler anyway.

Also I don't think most devs care about bill and his millions, he is slowly loosing the battle of world domination and the EU are constantly trying to break him.
OOO is constantly gaining popularity and OOO 3.0 has some great new usability features which I like.

But this bug has been fixed in qemu, virtualbox, kvm and works correctly in jaunty, it supports all types of the usb system so it will work if you are running on an old system with an old OS that uses /proc/bus/usb also.

This isn't a thread but a bug report so your stupid rant is just wasting space, fortunately the bug has been fixed.

[Noel J. Bergman (noeljb)]

mig7 has a point. Over a year ago, Scott James Remnant commented that "If your software is using /proc/bus/usb, it is broken -- you've had over a year to change it, and you've failed to do so." But Scott's wrong in the sense that it isn't "our" (users') software that is broken, it is "your" (Ubuntu's) software that is broken.

Dimitrios' point is that packages should either be fixed or removed from the repository.

usbview does not work. If you look at the upstream bug for usbview, Debian seems to consider it Ubuntu's problem, and they are not making upstream fixes.

apcupsd is broken in Hardy and Intrepid without manual intervention by mounting usbfs. I've gone through that on Hardy, and will be checking Intrepid, although I've found reports that it does work. That does not appear to be an option with Jaunty, so unless there's a fix in there that I'm not finding so far, there is another broken package.

Look, I have no problem with removing usbfs, but Ubuntu is not making the necessary fixes to dependent packages, leaving users with broken packages. Agreeing with Dimitrios -- such packages should be removed, fixed, or moved to a broken-packages repository if you want a place to put them aside for interested community members to take a shot at fixing them.

A bit of good news is that libusb-1.0 can hide the change, for applications written to use libusb instead of processing the device space themselves.

[Noel J. Bergman (noeljb)]

> That does not appear to be an option with Jaunty

Actually, it is. So that workaround still applies for users who search around to find it.

[Colin Watson (cjwatson)]

Noel, could you please describe the breakage with apcupsd in Jaunty in detail? Shirish's comments earlier were purely about documentation, as far as I've been able to tell. apcupsd does not appear to refer to /proc/bus/usb/ anywhere other than documentation, and seems to just open /dev/usb/hiddev* etc.

[Max Romantschuk (max-romantschuk)]

I have a Midisport 4x4 which is affected by this issue, package midisport-firmware. Will happily test to verify that all is well once a fix is available.

[Scott James Remnant (Canonical) (canonical-scott)]

On Mon, 2009-03-16 at 16:56 +0000, Max Romantschuk wrote:

> I have a Midisport 4x4 which is affected by this issue, package
> midisport-firmware. Will happily test to verify that all is well once a
> fix is available.
>
Which part doesn't work?

If you have the device plugged in during boot - could you
attach /var/log/udev from that boot.

Scott
--
Scott James Remnant
<email address hidden>

[Max Romantschuk (max-romantschuk)]

Scott James Remnant wrote:
> Which part doesn't work?
>
> If you have the device plugged in during boot - could you
> attach /var/log/udev from that boot.

I'm running Intrepid at the moment, should this work in Jaunty by now? I
just ran across this bug after the earlier midisport-specific bug was
marked as a duplicate of this one.

So do I need to upgrade to Jaunty to test?

.max

[Scott James Remnant (Canonical) (canonical-scott)]

On Mon, 2009-03-16 at 19:04 +0000, Max Romantschuk wrote:

> Scott James Remnant wrote:
> > Which part doesn't work?
> >
> > If you have the device plugged in during boot - could you
> > attach /var/log/udev from that boot.
>
> I'm running Intrepid at the moment, should this work in Jaunty by now? I
> just ran across this bug after the earlier midisport-specific bug was
> marked as a duplicate of this one.
>
Logs from intrepid will be fine.

Scott
--
Scott James Remnant
<email address hidden>

[Noel J. Bergman (noeljb)]

apcupsd works without /proc/bus/usb/devices -- documentation error

[Noel J. Bergman (noeljb)]

apcupsd works without /proc/bus/usb/devices --- documentation error

[Noel J. Bergman (noeljb)]

Colin,

I pulled the apcupsd and gapcmon sources for Gutsy, Hardy and Intrepid, and combed over them. As you say, no references. So I went back and re-tested without usbfs on both Hardy and Intrepid (I no longer have Gutsy handy for testing).

To my chagrin (but not dismay :-)), it works. So you're right: I got caught by a documentation error, and did not try running it without first trying to meet the documented requirements, although even there the documentation is ambiguous enough that one can interpret it in multiple ways. In this case, RTFM might be construed to have a slight twist on the usual meaning.

I've marked the apcupsd entries as invalid, and will open a separate bug for the documentation.

By the way, I see that vmware-server is mentioned here. Has anyone tried VMware Server 2 (I am downloading it now, so I can take a look), or is this just about version 1? VMware Workstation 6.5.x has had no problem with USB devices on any of these versions of Ubuntu.

[Noel J. Bergman (noeljb)]

As promised: bug 343869

[Max Romantschuk (max-romantschuk)]

As per Scott's request I'm attaching /var/log/udev from a boot with my Midisport device plugged in.

My Intrepid system works to the extent that I do get the device up and running by hotplugging after boot, as described in
https://bugs.launchpad.net/bugs/215081

[Scott James Remnant (Canonical) (canonical-scott)]

The midisport-firmware problem is that fxload uses the wrong environment variable to get the device name

[Launchpad Janitor (janitor)]

This bug was fixed in the package fxload - 0.0.20020411-1.1ubuntu1

---------------
fxload (0.0.20020411-1.1ubuntu1) jaunty; urgency=low

  * Use DEVNAME from the environment in preference to DEVICE, the former
    contains the modern /dev/bus/usb path. LP: #156085.

 -- Scott James Remnant <email address hidden> Tue, 17 Mar 2009 10:02:33 +0000

[Launchpad Janitor (janitor)]

This bug was fixed in the package midisport-firmware - 1.2+dsfg1-0ubuntu6

---------------
midisport-firmware (1.2+dsfg1-0ubuntu6) jaunty; urgency=low

  * 42-midisport-firmware.rules.in: Correct rules to act on the USB raw
    device, rather than the first interface. LP: #156085.

 -- Scott James Remnant <email address hidden> Tue, 17 Mar 2009 10:06:10 +0000

[Max Romantschuk (max-romantschuk)]

Scott James Remnant wrote:
> The midisport-firmware problem is that fxload uses the wrong environment
> variable to get the device name

If I understood the fxload docs correctly there is a command line
argument to specify the device as well. Could this be used for a
work-around in the midisport-firmware package's udev rules?

[Max Romantschuk (max-romantschuk)]

I just noticed a fix was released already. I will upgrade to Jaunty and verify that everything works for midisport-firmware.

[Scott James Remnant (Canonical) (canonical-scott)]

Dustin: could you look at QEMU, it should be the same basic patch as KVM right?

[Scott James Remnant (Canonical) (canonical-scott)]

usbview will be removed from the archive, it's functionality is available from lsusb or gnome-device-manager

[Dan Bishop (danbishop)]

I have a midisport 2x2 which I have just tried and found not to be working, however, I've just realised that the latest package hasn't made it to me yet, only 0.0.20020411-1.1 and not 0.0.20020411-1.1ubuntu1. Make sure you check this before testing the 4x4! :)

[Dan Bishop (danbishop)]

Can confirm this fix works perfectly for midisport 2x2 :D

[Dustin Kirkland  (kirkland)]

I'm marking QEMU as 'fix released' as well.

The relevant patch that we were carrying for kvm has been included in QEMU upstream, and is already present in qemu 0.10.0 in Jaunty.

:-Dustin

[Max Romantschuk (max-romantschuk)]

Confirmation for Midisport 4x4 working as well. :)

[Steve Langasek (vorlon)]

there is no vmware-server package in jaunty; marking this task invalid.

[Launchpad Janitor (janitor)]

This bug was fixed in the package madfuload - 1.2-2ubuntu2

---------------
madfuload (1.2-2ubuntu2) jaunty; urgency=low

  * 42-madfuload.rules.in: Add -D $root/$name to madfuload calls so we use
    /dev/bus/usb paths. LP: #156085.

 -- Scott James Remnant <email address hidden> Wed, 01 Apr 2009 09:40:00 +0100

[Sergio Zanchetta (primes2h)]

The 18 month support period for Gutsy Gibbon 7.10 has reached its end of life -
http://www.ubuntu.com/news/ubuntu-7.10-eol . As a result, we are closing the
Gutsy task.

[toaste (toaste)]

A slight change to the mountdevsubfs.sh workaround is necessary in Jaunty (9.04)

The commented out magic in mountdevsubfs.sh was removed sometime after Hardy, probably because it didn't work anymore since domount no longer likes "" as a parameter.

Add code below immediately after the line that reads:
domount devpts "" /dev/pts devpts -onoexec,nosuid,gid=$TTYGRP,mode=$TTYMODE

 #insert the following below the line above (line 41 for me)
        #
 # Magic to make /proc/bus/usb work
 # These following 4 lines were added to make USB devices avabilable in vmware
        #
 mkdir -p /dev/bus/usb/.usbfs
 domount usbfs none /dev/bus/usb/.usbfs -o busmode=0700,devmode=0600,listmode=0644
 ln -s .usbfs/devices /dev/bus/usb/devices
 mount --rbind /dev/bus/usb /proc/bus/usb

[Daniele Cruciani (daniele-smartango)]

info in https://bugs.launchpad.net/bugs/331331
solve all my problem in Jaunty

> -------Original Message-------
> From: Cas Craven <email address hidden>
> Subject: [Bug 156085] Re: Could not open /proc/bus/usb/devices
> Sent: 11 May '09 05:26
>
> A slight change to the mountdevsubfs.sh workaround is necessary in
> Jaunty (9.04)
>
> The commented out magic in mountdevsubfs.sh was removed sometime after
> Hardy, probably because it didn't work anymore since domount no longer
> likes "" as a parameter.
>
> Add code below immediately after the line that reads:
> domount devpts "" /dev/pts devpts -onoexec,nosuid,gid=$TTYGRP,mode=$TTYMODE
>
> #insert the following below the line above (line 41 for me)
>         #
> # Magic to make /proc/bus/usb work
> # These following 4 lines were added to make USB devices avabilable in vmware
>         #
> mkdir -p /dev/bus/usb/.usbfs
> domount usbfs none /dev/bus/usb/.usbfs -o busmode=0700,devmode=0600,listmode=0644
> ln -s .usbfs/devices /dev/bus/usb/devices
> mount --rbind /dev/bus/usb /proc/bus/usb
>
> --
> Could not open /proc/bus/usb/devices
> https://bugs.launchpad.net/bugs/156085
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[mahogeni muse (dkeeling0419)]

Ok, I am totally new to linux so I also am a novice when it comes to updating patches. I downloaded Ubuntu Desktop 9 and of course it won't recognize the USB Devices on my laptop. I have a Toshiba Satellite A215-S5818 with Windows Vista (build 6). Ubuntu 9 is the guest OS on VMWare Workstation 7.0 (build 203739). I've tried to mount usbfs manually using

mount -t usbfs none /proc/bus/usb

I've tried modifying /etc/fstab by adding the following code at the bottom:

usbfs /proc/bus/usb usbfs auto 0 0

The last thing I read was to modify the etc/init.d/mountdevsubfs.sh and uncomment

mkdir -p /dev/bus/proc/usb/.usbfs
domount usbfs ""/dev/bus/usb/.usbfs -obusmode=0700,devmode=0600,listmode=0644
ln-s .usbfs/devices/dev/bus/usb/devices
mount --rbind/dev/bus/usb/proc/bus/usb
$ sudo /etc/etc/init.d/nountdevsubfs.sh.start

However, when I went to the /etc/init.d directory there was no mountdevsubfs.sh file so I created one and added the code above with no luck. What am I doing wrong? Any help would be sincerely appreciated...

Thanks!

[Danny Wood (danwood76)]

Your problem sounds more like a bug in VMware and as it is a paid product I would ask them about it.
It sounds like VMware is not passing the USB devices on.

[mahogeni muse (dkeeling0419)]

Thanks danwood76...I'll give it a try...*sigh* back to the drawing board....

[Kip Warner (kip)]

I contacted the developer of USBView and this is the dialogue.

On Sat, Apr 03, 2010 at 09:19:43PM -0700, Kip Warner wrote:
> Hey Greg,
>
> Thanks for your great application USBView. I'd like to use it and I am
> running Ubuntu Karmic. The problem is it looks as though they dropped
> support for /proc/bus/usb a while ago and your app needs to be changed
> to use /dev/bus/usb instead, as I understand it:
>
> https://bugs.launchpad.net/ubuntu/+source/usbview/+bug/156085/comments/6
>
> Is this possible?

Please contact ubuntu about this, there is nothing I can do about it.

good luck,

greg k-h

[Karri Kaksonen (karri-kaksonen)]

/proc/usb is also needed for all users that use Aladdin HASP technology. What affects me is nautical chart subscriptions that require the HASP to work. These HASP keys will still be around for the next 10 years. So I feel that there should be a work-around for this.

The work-arounds presented in this thread do not work because the domount command is also dropped together with all the mount-shell scripts from the initscripts packages.

The last working system is Ubuntu 9.04

[Michael (michaeljt)]

Karri: I can see at least two ways of solving this in more recent Ubuntus. One is virtualisation (e.g. VirtualBox with USB virtualisation, since that no longer depends on /proc/bus/usb :) ). The other would be a preloaded libary which emulated /proc/bus/usb while actually accessing /dev/bus/usb and sysfs. Much like the way that OSS was emulated in user space over ALSA. The second solution should also work for USBView by the way.

Such a library is in my opinion a correct way of dealing with legacy devices which are lacking in current kernels (keeping the support in the kernel after its sell-by date is rather ugly, it seems to me) and it shouldn't be too much work to write as long as you don't have to support polling on files, although I hasten to add that I'm not volunteering for the job :)

[Rolf Leggewie (r0lf)]

Hardy has seen the end of its life and is no longer receiving any updates. Marking the Hardy task for this ticket as "Won't Fix".