So many people with various issues with passthrough and all sorts of other things. lsusb is an immensely useful tool for looking into things when something goes awry. Other ways to get things but a simple command is the best esp for newer people. There are also many debugging scripts and commands out there to poke around your system, and many of them rely on lsusb. Same applies to the other missing ls commands such as lsscsi.
The only practical reason I can think where I would use lsusb would be to find a Coral accelerator for Frigate. And the UI handles this without even having to “know”
There are dozens of reasons, example, was trying to figure out the organization of my usb ports and the groups they were in as I needed to pass a controller into a qemu VM, not windows and not Linux. A lot of information was needed to make it work, not just the UI. There are definitely ways to acquire this, but by far the easiest is a common script. Just one of many examples.
Don’t vote for it if you don’t think it’s useful. Make another feature request for lsscsi, that would also be useful for sure.
Ignoring the USB attached storage and other peripherals, the main reason to want lsusb is for USB attached UPS, (Uninterruptible Power Supply). Specifically trouble shooting, like I had to do with my old FreeNAS Mini & it’s UPS.
Maybe a collective request for all the ls* commands which are not included by default?
I suppose that all of them could be useful for the purpose of troubleshooting attached peripherals and finding out what could be passed to VMs—this one justifying troubleshooting for peripherals which have no direct use for a NAS.
That totals up to 136KiloBytes. Not sure where the 1.5GiB figure comes from.
The package for lsscsi is even smaller, 53KiloBytes. Again ignoring the manual and doc pages.
> du -sk /usr/bin/lsscsi
53 /usr/bin/lsscsi
Now I don't know if the device database is included. Or a separate package. So either package could easily be a bit larger. But I would not think by much.
I don’t see why common hardware/system info tools would not be included by default.
They consume negligible space, and they needn’t be modified from upstream. It’s a zero cost, with marginal benefits (at worst) and much-desired diagnostics (at best).
Simple, whence it’s included by default, if upstream drops it, you end up with customers who still expect it.
Happened to me. multiple times. I had a fully functional hibernate WITH ZFS root on my laptop and desktop. Worked for years, only to have that pm-utils package be deprecated and replaced with something that supposedly could do the job. Except I never could figure it out.
More recently, RedHat is dropping support for screen, forcing me to memorize tmux. And how to work around the automatic tmux nightmare, (it’s run automatically from logging in via SSH). People claim screen is no longer in active development, thus the “need” to replace it. Really? (They “claim” no active development means security issues won’t be fixed…)
The primary use case for system images are immutable environments where debugging and development tools shall optionally be made available, but not included in the immutable base OS image itself.
If TrueNAS were to support this we may not need feature requests for individual tools or commands.
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 002: ID 0627:0001 Adomax Technology Co., Ltd QEMU Tablet
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
I wanted to passthrough a Zigbee and a Bluetooth dongle to Home Assistant (which is featured as an app in official App repo) and I needed lsusb too to get the device and vendor id and to check compatibility!
Had to use it for USB UPS too as someone else has already mentioned.