Hi,

First off I want to say thank you for this awesome script!
I can't believe I had never heard of it until today but it's going to be a staple in my tool box from now on!

It's brilliant but I have noticed a bit of a problem for large array users: the -D option only displays 26 disks out of the 65 in the array.

Is this a built in limit that I can override?
Back to top

There is no limit. I would have to see the output of: inxi -xx@14 which will create and upload a full debugger dataset which will allow m e to see what is happening with how your system is giving data to inxi.

Let me know when that has been done and I'll take a look at it.

Generally with inxi, it shows you what the system actually is, and what it actually reports, not what the system operator believes to be the case, which are at times not the same thing.

hh
Back to top

By the way, while I won't spend any significant time on this issue until I get the debugging data, it does strike me that /dev/sdx in fact does only go to 26 letters, and that would explain why you see only 26.

I would have to see the syntax for everything above those 26 letters, since I've never seen that, in fact I didn't even realize you could have more than 26 sd devices.

What happens? is it is /dev/sdaa1, sdab1, sdac1, and so on? I honestly have no idea, which is why the debugger data is so invaluable, it lets me see how the system is reporting the data, etc.

rwmj.wordpress.com/2011/01/09/how-are-linux-drives-named-beyond-drive-26-devsdz/

I found it! So it is what I suspected: /dev/sdaa and so on.

But I won't touch this bug/issue until I get data samples that show a real system and how it works.

I also note the vda etc as well, for virtio-blk, which I think is not handled in inxi, not sure, I'll check.

Making inxi handle device names like /dev/sdax3 would be tricky and take great care since it's all written to expect only single letters after sd.

hh
Back to top

Normally I won't consider fixing an issue without getting the debugger data, because it's slow and unreliable, but in this case, the oversight/error was so glaring that I can't leave it unfixed.

Thanks for the heads up, and for being apparently the first inxi user to have > 26 hdd in their system, heh.

Note that because of the absence of the debugger data, I cannot verify that my fix works.

It should, since all I had to do was change the regular expression pattern of [a-z] to [a-z]+.

But I'm not positive it's right, as noted, I can't test it, and there is a lot of code in inxi, might have missed some.

This may be corrected in inxi 2.2.29 though I have no way to know for sure if it's fixed.
Back to top

After wanting this for a while, inxi 2.3.0 has -B option, battery. Shows nothing usually if no battery, unless you use -B explicitly.

-B is in -b, and -v2, and -F.

Extra options for more battery info.

Useful.


Note, all my test systems and datasets show cycle count at 0, so that's clearly a bug in maybe the linux kernel, I can't say.

Systems without a battery will only show the Battery line with empty data alert if you start it with -B explicitly. to avoid spamming the output with pointless data.

The updated man page explains the different numbers for charge:, condition:, and volts:

Now you can see at a CLI glance your battery charge state, AND the actual real capacity of the battery.

Supports > 1 batteries in output, in theory, though I haven't tested that yet explicitly since I have no system with > 1 batteries, but it should work based on the debug tests I did.

This item falls back to using dmidecode, for BSDs which have no /sys data source, but dmidecode is much less information, nothing about current charge or capacity for example, but it's something at least. So BSD support is added.
Back to top

I recently found the inxi script and it appears to be just what I was looking for, to capture system configuration. However, my target use is for embedded systems that quite often run BusyBox and the ash shell. I made some minor changes to get the script running in this environment and was wondering if you would consider patches submitted for this capability.
Back to top

that sounds like an interesting use case, can you show me some sample output using ash? What was the patch? Note that inxi is on github: github.com/smxi/inxi

I thought inxi wouldn't run on busybox, it requires gawk for example, and that requirement can't really be changed in any practical sense.

But I'd be curious to see output, inxi -v7 will show most of the inxi output.
Back to top

The system I am testing with does have gawk installed, so that's not an issue. I'll bundle up the sample output and patches and post them for your comments.
Back to top

My 2 posts are here:
techpatterns.com/forums/about2561.html

Should I repeat them here, or is this pointer good enough?

Is this the best way to submit bug reports?

Thanks.
Back to top

There's been a bunch of inxi updates that have helped it along nicely.

• ipv6 support is now much better, and more useful (2.3.11)
  
• graphics now shows the glx core version, not the deprecated version for free drivers. non free drivers have always shown the latest version (2.3.12)
  
• graphics now shows in root mode, at some point in the past glxinfo and xpdyinfo started to work as root, don't know when that happened. (2.3.14)
  
• new option: -! 40 will allow you to see graphics information in console, out of x, as long as x is running. Note this isn't complete since some environmental variables that would be set in x are not set out of x, gnome and kde for example. (2.3.15)
  
• initial attempt to show wayland/mir. When display server data is detected, the format is:
  x11 (X.org 1.19.0), when it's not, it just looks for xorg data as before. (2.3.12)
  
• new testing option, -xx, shows compositor information if it can find it. This is totally experimental and probably won't work right for many compositors, but it was worth a try, it will require more user data before it's solid. (2.3.12)
  

Back to top