[Accepted] Please add lsusb, lsscsi commands to Scale!

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.

Obviously should be simple to add.

3 Likes

Is this request storage related?

It shouldn’t be; USB storage is strongly discouraged.

1 Like

It’s just a useful cli command to look around

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”

I would vote for the inclusion of lsscsi, tho.

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.

1 Like

It lists them for you in the UI?

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.

So yes, I voted for this feature.

3 Likes

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.

(And do not forget to vote for your own request!)

4 Likes

That will increase the installer ISO by at least 5 GiB.

lsusb itself requires around 1.5 GiB, I think?

(Why is it not included by default again…?)

1 Like

Good point, I modified my request to add them all.

1 Like

Ignoring the manual & doc pages, I see this for lsusb package size, (on Gentoo Linux);

> du -sk /usr/bin/lsusb /usr/bin/usb-devices /usr/bin/usbhid-dump /usr/bin/usbreset /usr/lib64/pkgconfig/usbutils.pc
105	/usr/bin/lsusb
5	/usr/bin/usb-devices
17	/usr/bin/usbhid-dump
9	/usr/bin/usbreset

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.

It comes from Winnie’s Bag of Sarcasm. :wink:

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).

3 Likes

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…)

Who has ever heard of systemd-sysext?

https://manpages.debian.org/bookworm/systemd/systemd-sysext.8.en.html

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.

Which would relate this topic to Decide and document where to install tools and scripts.

3 Likes

Did anyone order lsusb in SCALE @sfatula? Here’s the non-destructive DIY recipe for educational purposes using systemd-sysext. I tried it in a VM and it listed:

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

Use at your own risk.

5 Likes

@jct

1 Like

I can make it happen too, but, I am looking for it to be part of the install for many reasons. This is a feature request.

2 Likes

That’s really neat, and I think it deserves its own thread. :slight_smile:

1 Like

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.

2 Likes