Add output of usb-devices when ubuntu-bug linux or apport-collect'ing existing report affecting linux (Ubuntu)

[Pilot6]

What is expected to happen is when an original reporter files a report via a terminal:
ubuntu-bug linux

or performs an apport-collect to a report that is affecting tbe linux (Ubuntu) package, apport automatically gathers the following command and adds it as an attachment:
usb-devices

Lsusb is not sufficient. Upstream bluetooth maintainer requires the output of:
cat /sys/kernel/debug/usb/devices

Without this information patches are never accepted.

Please add this output to apport.

If needed, I can provide a patch, but it is very straight-forward to add.

The is motivated due to the circumstances surrounding the following report, and future bluetooth bugs reported:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1546694

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: apport 2.14.1-0ubuntu3.19
ProcVersionSignature: Ubuntu 4.2.0-30.35~14.04.1-generic 4.2.8-ckt3
Uname: Linux 4.2.0-30-generic x86_64
NonfreeKernelModules: nvidia
ApportLog:

ApportVersion: 2.14.1-0ubuntu3.19
Architecture: amd64
CurrentDesktop: Unity
Date: Sat Feb 27 17:23:18 2016
InstallationDate: Installed on 2013-10-17 (863 days ago)
InstallationMedia: Ubuntu 13.04 "Raring Ringtail" - Release amd64 (20130424)
PackageArchitecture: all
SourcePackage: apport
UpgradeStatus: Upgraded to trusty on 2014-04-16 (681 days ago)

[penalvch (penalvch)]

Has a compelling triaging and developing reason to implement as soon as resources become available.

[Pilot6 (hanipouspilot)]

There are some other bug reports that are stuck because if this issue. I do not remember all of them, but I remember that there were some that are still unanswered.

[Brian Murray (brian-murray)]

lsusb is already gathered. From the linux hook we see:

 47 apport.hookutils.attach_hardware(report)
 48 apport.hookutils.attach_alsa(report)
 49 apport.hookutils.attach_wifi(report)

And in apport/hookutils.py we have the following:

233 def attach_hardware(report):
234 '''Attach a standard set of hardware-related data to the report, including:
235
236 - kernel dmesg (boot and current)
237 - /proc/interrupts
238 - /proc/cpuinfo
239 - /proc/cmdline
240 - /proc/modules
241 - lspci -vvnn
242 - lsusb
243 - devices from udev
244 - DMI information from /sys
245 - prtconf (sparc)
246 - pccardctl status/ident
247 '''
248 attach_dmesg(report)
...
257 report['Lsusb'] = command_output(['lsusb'])

Is lsusb insufficient?

[Brian Murray (brian-murray)]

Oh and the lsusb information can be found here for the referenced bug report.

https://launchpadlibrarian.net/240231558/lsusb.txt

[penalvch (penalvch)]

Brian Murray, thanks for the quick review towards this.

I'll let Pilot6 be the final authority on this, but AFAIK what is desired is the driver being used precisely, and other granular details (rev., etc.), which lsusb doesn't provide (apologies for not stating that in the Description).

Is there an initial security or privacy concern to this?

[Pilot6 (hanipouspilot)]

Lsusb is not sufficent. Upstream maintainer require output of

cat /sys/kernel/debug/usb/devices

Without this information patches are never accepted. It is needed make record of all devices with Cls, Sub, Prot fields

usb-devices command provides the same information in a shorter form and does not require root permissions.
Ubuntu has this program by default.

You can see that all commits in the kernel git adding new USB decices contain this info.

[Pilot6 (hanipouspilot)]

Christopher,

I do not see any privacy concerns at all. The output just lists the devices with the additional information.
The most private that can be there is a serial number of some devices, like Broadcom.

But it can be seen in dmesg either way. So it adds nothing new in this regard.

The problem is that if someone forgets to get the output, a bug will never be fixed upstream.

Marcel Holtman is very strict with his rules. And I agree with him.

Threre is very many USB devices and the kernel filters it not only by PID & VID.

If we commit some device without Cls, Sub, Prot fields, then it will be impossible to re-arrange it later, if needed.

The change is very easy and the output is small enough. So I see no reasons not to add it.

[Jeremy (wa113y3s)]

I agree with Pilot6 but can this info be used to fix the Atheros bluetooth issue with 0cf3:3004 with some being Rome chipsets like in this bug report

https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1542743

The older chipsets like I have use ath3k to load the firmware from /lib/firmware/ar3k/ and the newer ones(Rome) use btusb to load the firmware from /lib/firmware/qca/

[penalvch (penalvch)]

I agree with Jeremy and Pilot6. I don't have any objections to this, nor do any stand at this point.

[Brian Murray (brian-murray)]

The recommendation in comment 7 was actually to use usb-devices not cat'ing /sys/kernel/... as appears in the description.

[Pilot6 (hanipouspilot)]

Brian,

I can explain this.
General requirement of upstream maintainers is to include output of 'cat /sys/kernel/debug/usb/devices'.
It is the most full source and can be run on any Linux system.

'usb-devices' output includes basically the same information. But this software is not available in all linux systems.

Output of 'usb-devices' is acceptable upstream.

It really does not make much difference which one to use. But I vote for 'usb-devices', since it is available in Ubuntu, does not require sudo and the output is a bit shorter.