Beta testers for the new inxi/pinxi wanted, squash the bugs!


#6

Thankyou,
and sorry if I shouldn’t ask it here, but I notice many times on forums where, to help others, output of inxi -…, is asked, along with lsblk, fdisk -l, gdisk -l, (but mostly) efibootmgr -v, …

oops, I missed this.

nice.

Jus curious if you’re working on a future feature switch-set to incorporate some of the above, into [p]inxi, and whether or not, if inxi needs sudo, then that’s fine too. ?

But again, thx for inxi, which proves, once again, that Terminals are King, along with “sysstat”.
:wink:


#7

A couple of problems:

Running pinxi I get 12686% HDD used, while in inxi and pinxi -F it says 12.4% used:

CPU: Quad Core AMD Phenom II X4 940 (-MCP-) 
speed/min/max: 3000/800/3000 MHz Kernel: 4.15.8-1-MANJARO x86_64 Up: 1:41 
Mem: 1703.0/7980.0 MB (21.3%) HDD: 1.71 TB (12686.0% used) Procs: 168 
Shell: zsh 5.4.2 pinxi: 2.9.00-387-p

There maybe some issue with sensors for my GPU. Inxi says the temperature of the gpu is 57.0, while pinxi says 22 C. Result for pinxi -s

Sensors:   
  System Temperatures: cpu: 46.0 C mobo: 41.0 C gpu: radeon temp: 22 C 
  Fan Speeds (in RPM): cpu: 0 fan-1: 2205 fan-3: 0 

For comparison the results of using sensor:

radeon-pci-0100
Adapter: PCI adapter
temp1:        +56.5°C  (crit = +120.0°C, hyst = +90.0°C)

it8720-isa-0e80
Adapter: ISA adapter
in0:         ...
...
fan1:        2205 RPM  (min =   13 RPM)
fan2:           0 RPM  (min =   10 RPM)  ALARM
fan3:           0 RPM  (min =   10 RPM)  ALARM
temp1:        +41.0°C  (low  =  -6.0°C, high = +127.0°C)  sensor = thermistor
temp2:        +47.0°C  (low  =  -1.0°C, high = +127.0°C)  sensor = thermistor
temp3:        +22.0°C  (low  =  -6.0°C, high = -17.0°C)  ALARM  sensor = thermistor
cpu0_vid:    +0.413 V
intrusion0:  OK

#8

Lolix, I’d ask you not to package pinxi, this is a purely development branch, that can and does get up to 10 release per day. pinxi -U is the best updating method, because that guarantees you are running the actual current pinxi release.

That set of uninitialized errors is exactly the type of thing I’m looking for, that means an assumption that a certain data type could never be null was wrong, astounding just how many of those I’ve gotten in the past week, which is why the more diverse the systems testing it, the better. Those are usually easy to fix.

This is a case where I’d want to see the --debug data set, because I need to fiind the root cause for that, it should never be null, technically, internally, so I would want to see how that came about so I can actually fix the issue, not patch over it. This comes from lsusb -v

USB is a new feature, so it’s most likely to have bugs, since usb data is just as dirty, inconsistent, and unreliable as any other vendor generated data is. But that particular error is an internal logic bug I’m pretty sure, there must have been some type of variation in the structure of lsusb -v that confused pinxi.

I often release a new version, say, 0383-p 10 minutes after 0382-p, so a specific person can test the fixes and ensure they are correct.

johnvan54, that looks like some bugs for sure, however, you truncated your sensors output so I can’t actually resolve the issue. All data samples need to be complete, as is, or just run --debug 21 or --debug 22 and I get the data exactly as the system gives it, which then lets me inject that data into pinxi directly to figure out the issue.

Running pinxi I get 12686% HDD used, while in inxi and pinxi -F it says 12.4% used

looks like a math problem there, except those two things should be doing the same math.

I have some tentative gpart stuff in pinxi, but it’s mostly for BSDs, however, one primary purpose of rewriting inxi into perl was to make the creation of new features much much easier (it is), and the debugging of existing features far easier (it is).

eugen-b, to uninstall, it’s a simply script: rm -f /usr/local/bin/pinxi and then:

locate pinxi

which will show you where your pinxi . directory is, probably $HOME/.local/share/pinxi in most cases on modern systems, unless XDG data/config directories are used, then they will be in those.

Feedback looks good so far, and confirms that pinxi is not yet ready for stable 3.00 release, but we’re getting there! Thanks for testing it.


#9

Okay, I ran both pinxi and pinxi -s using --debug 22.


#10

johnvan54, the sensors issue is a regex error, but it’s not cooperating, should be working shortly. Thanks, I’ll see what happened with the short pinxi hdd size thing.


#11

johnvan54, 0-388-p should fix the sensors issue, that was just a regex error, I tried using something that works on other languages, but not in perl. That’s a new feature by the way, which is why it had a bug, inxi didn’t do gpu intel|amdgpu|radeon|nouveau sensors temp detection at all. If sensors has fan speed for the gpu, it will show that too, unless it uses a different syntax for the fanx: line starter.

Just to clarify, --debug 21/22 overrides everything else, so you don’t need to use options on pinxi, it won’t impact the debugger data.


#12

Tested with 0-389-p and the GPU temperature looks fine:

pinxi -s                                                             [1]
Sensors:      
  System Temperatures: cpu: 47.0 C mobo: 43.0 C gpu: radeon temp: 58 C 
  Fan Speeds (in RPM): cpu: 0 fan-1: 2198 fan-3: 0

#13
Sensors:
  System Temperatures: cpu: 30.0 C mobo: 26.0 C gpu: amdgpu temp: 26 C 
  Fan Speeds (in RPM): cpu: 0 fan-1: 1408 fan-3: 0 fan-5: 0 gpu: amdgpu 
  fan: 1408

this is a sample of pinxi handling multiple gpus/sensors:

Sensors:   System Temperatures: cpu: 30.0 C mobo: 26.0 C 
           Fan Speeds (in RPM): cpu: 0 fan-1: 1408 fan-3: 0 fan-5: 0 
           GPU: device: nvidia screen: :0.0 temp: 48 C device: amdgpu temp: 26 C fan: 1408

There were several bugs in sensors gpu temp/fan speeds, those are corrected and will be committed shortly. This is a sample of the data running locally, from stretch-K10 system.


#14

As I have said packaged; it is not accurate, the AUR consists of script for building packages.
I have made an AUR script that package the very latest git commit of pinxi, running pinxi -U or yaourt -S inxi-dev-git will give the same result

The version of the package is the number of git commits FYI

In the AUR there are thousands of in development programs :slight_smile:


sudo rm /usr/local/bin/pinxi

I guess


#15

Lolix, I see, that sounds solid as long as it’s grabbing the latest git commit, that makes sense, good thinking.

0390-p fixes an entire set of sensors errors, mainly the gpu temp/fan speed data from sensors, not things like nvidia-settings. I had no data samples with fan speeds, didn’t even know if sensors would have that in it, but it does, and now I do, so that’s an entire feature that is now more reliable, that is, it actually works, heh.

I still have not gotten to the wrong short form pinxi HDD size used, that’s next.


#16

0391-p fixes the pinxi short form output for HDD percent. That was a simple error, dividing the number formatted results for total/used instead of the unformatted raw values. Nobody had noticed this error because they didn’t do the combination required to expose it: run pinxi short form, AND have used/total that worked out to different units, like GB/TB. So that was a fortunate catch, and exactly the type of bug I’m hoping to squash before final release.

These were all really good catches, the sensors stuff was several things, the usb was failing to handle possible null values where they’d never shown up before.

Also found and corrected, something I actually tried fixing a while ago in inxi, the failure to show the full data for Distro for manjaro, the dataset I got finally showed me why, since arch-release also showed up, all subsequent actions stopped, and defaults set for arch processing kicked in, instead of the defaults for manjaro distro id. To solve this, I just remove the arch-release from the distro files if manjaro is found, that should then result in correct full ID. I thought had this solved some 6 months ago, but I was missing the key bit of info (which is why the --debug datasets are so valuable, they show me stuff I didn’t think of looking for when it comes to causes of failure etc. The full manjaro string from lsb-release file should now be showing as expected, sorry about that one, that was meant to be corrected some time ago.

Thanks for the solid bugs, and datasets that help resolve them. I’ll scan the rest of the datasets to see if I can find other errors that haven’t been noticed.


#17

uploaded --debug 21 data.
My mount output is a bit weird, because I use btrfs subvolumes.

Partition: ID-1: /dev size: 3.60 GB used: 0 KB (0.0%) fs: devtmpfs dev: ERR-102 label: N/A uuid: N/A 
           ID-2: /run size: 3.61 GB used: 1.1 MB (0.0%) fs: tmpfs dev: ERR-102 label: N/A uuid: N/A 
           ID-3: / size: 237.48 GB used: 10.34 GB (4.4%) fs: btrfs dev: /dev/sda3 label: N/A uuid: N/A 
           ID-4: /boot size: 247.9 MB used: 151.3 MB (61.0%) fs: ext2 dev: /dev/sda2 label: N/A 
           uuid: 302ae0b1-b913-471b-a1ab-3bb4575b4d00 
           ID-5: /var/cache/pacman/pkg size: 237.48 GB used: 10.34 GB (4.4%) fs: btrfs dev: /dev/sda3 
           label: N/A uuid: N/A 
           ID-6: /home size: 237.48 GB used: 10.34 GB (4.4%) fs: btrfs dev: /dev/sda3 label: N/A uuid: N/A 
           ID-7: /boot/efi size: 252.0 MB used: 242 KB (0.1%) fs: vfat dev: /dev/sda1 label: N/A 
           uuid: 1B50-4EF2 
           ID-8: /home/eugen/.ccache size: 237.48 GB used: 10.34 GB (4.4%) fs: btrfs dev: /dev/sda3 label: N/A 
           uuid: N/A 
           ID-9: /home/eugen/Data size: 237.48 GB used: 10.34 GB (4.4%) fs: btrfs dev: /dev/sda3 label: N/A 
           uuid: N/A 
           ID-10: /run/media/eugen/openSUSE-Tumbleweed-DVD-x86_6400 size: 7.42 GB used: 6.67 GB (89.9%) 
           fs: fuseblk dev: /dev/sdd1 label: openSUSE-Tumbleweed-DVD-x86_6400 uuid: DD6A-2F86 
           ID-11: /run/media/eugen/DATA2 size: 92.73 GB used: 61.08 GB (65.9%) fs: xfs dev: /dev/sdb5 
           label: DATA2 uuid: 3de85b28-17b3-4a39-bd5e-61b4e118d7fd 

The output of mount for comparison:

~/inxi-dev-git >>> mount | grep 'subvol='                                                                                                                                                    
/dev/sda3 on / type btrfs (rw,noatime,compress=lzo,ssd,space_cache,commit=120,subvolid=257,subvol=/@)
/dev/sda3 on /var/cache/pacman/pkg type btrfs (rw,noatime,compress=lzo,ssd,space_cache,commit=120,subvolid=307,subvol=/@pkg)
/dev/sda3 on /home type btrfs (rw,noatime,compress=lzo,ssd,space_cache,commit=120,subvolid=306,subvol=/@home)
/dev/sda3 on /home/eugen/.ccache type btrfs (rw,noatime,compress=lzo,ssd,space_cache,commit=120,subvolid=309,subvol=/@ccache)
/dev/sda3 on /home/eugen/Data type btrfs (rw,noatime,compress=lzo,ssd,space_cache,commit=120,subvolid=308,subvol=/@data)

If you want to enhance btrfs detection…


#18

geggo, thanks for the solution to that 'TIN" value in cpu sensors, I’d seen it before but had no idea where it came from. Bad regex in this case, failed to handle a set of situations. This should now be corrected in 0393-p

eugen-b, thanks for the btrfs samples, those are barely handled, as you noticed, in pinxi, or inxi. I’ll see what can be done with them.

Just fyi, pinxi doesn’t use mount, not in GNU/Linux, it does use it for some things in BSDs. Running subshells is up to 50x more expensive re time than reading file, so it reads /proc/partitions, which is basically the same data.

The number one optimization target for pinxi is to get rid of every subshell possible, and switch to file reading, if possible, because about 90% of pinxi’s execution time comes from loading perl modules (a small part) and subshell commands (80+% of the time it takes pinxi to run, at least).

RE btrfs (and zfs, by the way, similar issue), subvolumes, I’ve seen these, but as of yet, I don’t quite understand how to handle them, mainly because I don’t actually understand the concepts behind a subvolume. This is one of the things that is hanging up the completion of RAID as well by the way.


#19

btrfs subvolumes can be mounted with
sudo mount -o subvol=<subvolume_name> /dev/sda1 /mnt
command, for example. Then you will find not the whole content of sda1 on /mnt but only the content of the <subvolume_name>. (Subvolumes allow to separate data like partition while being flexible in size.)
About reading files: Here is subvolume output from /proc/mount

~/inxi-dev-git >>> cat /proc/mounts | grep 'subvol='                                                                                                                                         
/dev/sda3 / btrfs rw,noatime,compress=lzo,ssd,space_cache,commit=120,subvolid=257,subvol=/@ 0 0
/dev/sda3 /var/cache/pacman/pkg btrfs rw,noatime,compress=lzo,ssd,space_cache,commit=120,subvolid=307,subvol=/@pkg 0 0
/dev/sda3 /home btrfs rw,noatime,compress=lzo,ssd,space_cache,commit=120,subvolid=306,subvol=/@home 0 0
/dev/sda3 /home/eugen/.ccache btrfs rw,noatime,compress=lzo,ssd,space_cache,commit=120,subvolid=309,subvol=/@ccache 0 0
/dev/sda3 /home/eugen/Data btrfs rw,noatime,compress=lzo,ssd,space_cache,commit=120,subvolid=308,subvol=/@data 0 0

#20

machine name: myXPS15, you should find the USB networking devices hopefully now correctly showing their full data per card, there was a bug in there for usb which I believe I’ve corrected, as of 0394-p.

Whenever you see: IF-ID-x: it means that pinxi failed to match the card/device to the IF data, and just prints out the stuff that hadn’t been matched after the main card line items are made. One major enhancement, well, there were several really big enhancements for pinxi -n and -i is that now the IF(s) match to the cards, and for systems, like some usb where pinxi could not determine if the device was a networking device, or on all ARM systems, that have no pci data, pinxi now prints out the unused IF devices after, before the WAN line. It also handles all the IPs associated with each IF. This won’t be obvious to regular home users, but it really is on servers with a lot of IPs running.

But I think I sorted out most of the main networking usb device bugs now.


#21

0395-p removes the dev/run file system types, which are new ones for me, from partitions, I had devfs but didn’t know run and dev were now their own types. So that is good.

Added logging to figure out an odd glitch in the ‘running in: gnome-shell-’ (notice the - at the end?) glitch, which I cannot currently account for, as far as I can tell from your data, eugen-b, it’s actually running in gnome-terminal-server, but something in pinxi or ps cut off the last bit. I’ve added more robust data logging in those areas to see what’s actually happening in there for future debugging.

What’s the difference between gnome-terminal and gnome-terminal-server?


#22

eugen-b, as far as I can tell, there’s no real difference between what pinxi can learn about partitions from df -kPT, /proc/partitions, or /proc/mount

In this regard, re btrfs, what pinxi does is: it counts only one mounted /dev/xxx partition when calculating the hdd used percent. This covers the btrfs issue, along with bind mounts, and various other ways to mount the same thing multiple times.

Since the reported used data is the same for each btrfs partition sub volume, theres no way that pinxi can discover what is actually used unless there are other reporting tools available specific to btrfs that will give this information, then I’d need to know what those tools are, and what the output of them is so it can be parsed.

I’d also need to add that to the debugger data collector so that improved btrfs support could be added.

Since there’s currently no data that can be used to determine this, I’d have to wait for that information. Technically I’d recommend filing an issue on https://github.com/smxi/inxi (the master branch, not the inxi-perl one), so it can be followed up on over time to see if anything can be done to improve that, but after looking at all that data, there’s nothing that can be used that I can see.

I see in the debugger tool that there at least was a command: btrfs show / btrfs show --mounted, but in your data these two resulted in null (not program missing, note, just nothing, empty), the command exists, but there is no output for it. That’s the only info that pinxi debugger knows about internally, and that yielded nothing, so apparently either that’s obsolete, or from some other type of system, I can’t say, all I know is it’s in the debugger, and returned nothing.

I’ve rolled in some more fs blacklists for partitions, but otherwise, I can’t really see where I can change btrfs handling with the given data.


#23

Oh, I forgot to mention, while this is not yet implemented, pinxi/inxi 3 is designed to handle two new things:

  1. language packs, to some degree, at least for line key values and error/message output in lines. the --help and --version are not as easy to handle.

  2. export to json or xml.

Both of these are designed into the core pinxi code, since you can’t add on either as an afterthought, but neither is as of yet implemented, though both are actually quite close, 1. has all the key/value data designed for translation, and 2. has all the core internal datastructures designed for either screen print or data export.

I’ve held off on 1 because the language features are not stable yet, that is, I keep changing key/value data internally, so that probably won’t be offered until after 3.0.0 is released. 2. I’d probably just use a perl module, which would be a dependency if that feature were used, I just have to look into how well those export modules actually work. One piece of how I had to make the data structures however makes it a non clean export to json or xml, so I have to look into that as well.


#24

@h2-1
FYI: inxi 2.9.07-1 now in Stable Branch gives me this error between the CPU and Graphics sections :

$ sudo inxi -v8
...
CPU:       Topology: Dual Core model: Intel Core i5-4200U type: MT MCP arch: Haswell rev: 1 L2 cache: 3072 KB 
           flags: lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx bogomips: 18360 
           Speed: 798 MHz min/max: 800/2600 MHz Core speeds (MHz): 1: 798 2: 798 3: 798 4: 805 
Use of uninitialized value $server in lc at /usr/bin/inxi line 7626.
Graphics:  Card-1: Intel Haswell-ULT Integrated Graphics Controller driver: i915 v: kernel bus ID: 00:02.0 
           chip ID: 8086:0a16 
           Display Server: X.Org 1.19.6 driver: intel unloaded: fbdev,modesetting,vesa 
           resolution: 1920x1080~60Hz 

Update: I do not get that error message in 2.9.08-1 from Unstable running under VirtualBox.


[Stable Update] 2018-03-27 - Kernels, Krita, Grub, Deepin, Pamac, Pacman-Mirrors, Firefox
#25

yes, it was a brief bug, it’s fixed.