New inxi / pinxi features: user RAM reports! And much more! Testers?

chrisretusn · 01-19-2024, 02:21 AM

Quote:

Originally Posted by h2-1

chrisretusn, sorry, wanted to ask this earlier, can you show:

Code:

sudo dmidecode --type  16,17

I used 'su -' to switch to root.

Code:

~# dmidecode --type  16,17
# dmidecode 3.5
Getting SMBIOS data from sysfs.
SMBIOS 2.4 present.

Handle 0x001F, DMI type 16, 15 bytes
Physical Memory Array
        Location: System Board Or Motherboard
        Use: System Memory
        Error Correction Type: None
        Maximum Capacity: 8 GB
        Error Information Handle: Not Provided
        Number Of Devices: 2

Handle 0x0020, DMI type 17, 27 bytes
Memory Device
        Array Handle: 0x001F
        Error Information Handle: Not Provided
        Total Width: 64 bits
        Data Width: 64 bits
        Size: 4 GB
        Form Factor: DIMM
        Set: None
        Locator: A0
        Bank Locator: Bank0/1
        Type: Unknown
        Type Detail: None
        Speed: 1333 MT/s
        Manufacturer:  
        Serial Number:  
        Asset Tag:  
        Part Number:  

Handle 0x0021, DMI type 17, 27 bytes
Memory Device
        Array Handle: 0x001F
        Error Information Handle: Not Provided
        Total Width: 64 bits
        Data Width: 64 bits
        Size: 4 GB
        Form Factor: DIMM
        Set: None
        Locator: A1
        Bank Locator: Bank2/3
        Type: Unknown
        Type Detail: None
        Speed: 1333 MT/s
        Manufacturer:  
        Serial Number:  
        Asset Tag:  
        Part Number:

Quote:

Originally Posted by h2-1

for your above sample, is that the same udevadm sample you posted earlier, if not, can you also provide:

Code:

udevadm info -p /devices/virtual/dmi/id

I should be the same, nonetheless here it is again.

Code:

# udevadm info -p /devices/virtual/dmi/id
P: /devices/virtual/dmi/id
E: DEVPATH=/devices/virtual/dmi/id
E: MEMORY_ARRAY_LOCATION=System Board Or Motherboard
E: MEMORY_ARRAY_MAX_CAPACITY=8589934592
E: MEMORY_ARRAY_NUM_DEVICES=2
E: MEMORY_DEVICE_0_BANK_LOCATOR=Bank0/1
E: MEMORY_DEVICE_0_DATA_WIDTH=64
E: MEMORY_DEVICE_0_FORM_FACTOR=DIMM
E: MEMORY_DEVICE_0_LOCATOR=A0
E: MEMORY_DEVICE_0_SIZE=4294967296
E: MEMORY_DEVICE_0_SPEED_MTS=1333
E: MEMORY_DEVICE_0_TOTAL_WIDTH=64
E: MEMORY_DEVICE_0_TYPE=Unknown
E: MEMORY_DEVICE_0_TYPE_DETAIL=None
E: MEMORY_DEVICE_1_BANK_LOCATOR=Bank2/3
E: MEMORY_DEVICE_1_DATA_WIDTH=64
E: MEMORY_DEVICE_1_FORM_FACTOR=DIMM
E: MEMORY_DEVICE_1_LOCATOR=A1
E: MEMORY_DEVICE_1_SIZE=4294967296
E: MEMORY_DEVICE_1_SPEED_MTS=1333
E: MEMORY_DEVICE_1_TOTAL_WIDTH=64
E: MEMORY_DEVICE_1_TYPE=Unknown
E: MEMORY_DEVICE_1_TYPE_DETAIL=None
E: MODALIAS=dmi:bvnAwardSoftwareInternational,Inc.:bvrF1:bd11/15/2010:svnGigabyteTechnologyCo.,Ltd.:pnM68MT-S2:pvr:rvnGigabyteTechnologyCo.,Ltd.:rnM68MT-S2:rvr:cvnGigabyteTechnologyCo.,Ltd.:ct3:cvr:sku:
E: SUBSYSTEM=dmi
E: USEC_INITIALIZED=8233950

Quote:

Originally Posted by h2-1

Re the --fake udevadm,that only works if you have the test environment and the debugger data files, what I use to emaulate the various samples here, those files are available from codeberg.org/smxi/pinxi/data/ram/udevadm/ and I'm trying to upload the real data files used to develop in case someone wants to try to work on it other than me, I used to have most of those non-open because it was a pain to go through that stuff and clean it up and organize it, but it's mostly done now so I just add them as I go along.

Thanks, that clears up a question I was going to ask.

BroX · 01-19-2024, 03:30 AM

Any idea why pinxi fails to self-update, while it works fine with inxi?

Code:

...

Deleted post: worked as it should after manual update.

h2-1 · 01-19-2024, 01:35 PM

BroX, sometimes a version has a bug in it, pinxi is very unstable, although there is actually an even more unstable pure development version I use. I do try to keep pinxi fully working, but during active changes, as we've seen in this thread, sometimes I forget to test a change and it has a glitch. Or it might have been an older version that still had the github url in it.

h2-1 · 01-22-2024, 05:33 PM

With a lot of testing, and some best in class bug triggers in the -S Desktop report area, I've gotten a lot of the core refactor bugs and glitches worked out, found some really old bugs that had never been exposed before, until now with a new Hyprland wayland window manager version syntax change, or structure change, finally tracked down that bug.

Because the new features enable new data and reports fairly easily, I'm updating and upgrading a few more items:

Code:

pinxi -SImaz
System:
  Kernel: 6.6.11-1-liquorix-amd64 arch: x86_64 bits: 64 compiler: gcc
    v: 13.2.0 clocksource: tsc avail: hpet,acpi_pm parameters: audit=0
    intel_pstate=disable rcupdate.rcu_expedited=1
    BOOT_IMAGE=/boot/vmlinuz-6.6.11-1-liquorix-amd64
    root=UUID=643cae5c-fe45-41ae-b8a5-d94fafe6bbc4 ro quiet
  Desktop: Xfce v: 4.18.1 tk: Gtk v: 3.24.36 comp: xfce4-panel wm: xfwm
    v: 4.18.0 vt: 7 tools: xfce4-screensaver avail: slock dm: 1: LightDM
    v: 1.32.0 2: SDDM note: stopped Distro: Debian GNU/Linux trixie/sid
Memory:
  System RAM: total: 32 GiB available: 31.27 GiB used: 14.22 GiB (45.5%)
  Message: For most reliable report, use superuser + dmidecode.
  Array-1: capacity: 128 GiB slots: 4 modules: 2 EC: None
    max-module-size: 32 GiB note: est.
  Device-1: Channel-A DIMM 0 type: no module installed
  Device-2: Channel-A DIMM 1 type: DDR4 detail: synchronous unbuffered
    (unregistered) size: 16 GiB speed: 2400 MT/s volts: note: check curr: 1
    min: 1 max: 1 width (bits): data: 64 total: 64 manufacturer: Crucial
    part-no: CT16G4DFD824A.M16FB serial: <filter>
  Device-3: Channel-B DIMM 0 type: no module installed
  Device-4: Channel-B DIMM 1 type: DDR4 detail: synchronous unbuffered
    (unregistered) size: 16 GiB speed: 2400 MT/s volts: note: check curr: 1
    min: 1 max: 1 width (bits): data: 64 total: 64 manufacturer: Crucial
    part-no: CT16G4DFD824A.M16FB serial: <filter>
Info:
  Processes: 656 Power: uptime: 8d 22h 0m states: freeze,mem,disk
    suspend: deep avail: s2idle wakeups: 14 fails: 3 hibernate: platform
    avail: shutdown,reboot,suspend,test_resume image: 12.49 GiB
    daemons: upowerd,xfce4-power-manager Init: systemd v: 255
    target: graphical (5) default: graphical tool: systemctl
  Packages: pm: dpkg pkgs: 3960 libs: 2184 tools: apt,apt-get,aptitude
    pm: rpm pkgs: 0 Compilers: gcc: 13.2.0 alt: 5/6/8/9/10/11/12 Shell: Bash
    v: 5.2.21 running-in: xfce4-terminal pinxi: 3.3.31-66

The entire Power: section in Info: and the tools: section in System: Desktop are new.

There were also quite a few KDE glitches that have largely been worked out, I hope. Note subtle fixes like numeric sorts of Compilers: alt: item, as well as adding zigcc compiler support for the first time, along with already there Clang.

I haven't come across any further -m udevadm sourced RAM issues, but I think the main ones are going to come from systems with > 4 slots for RAM, and probably > 1 CPUs, so not a lot there for average users now I think will go wrong, hopefully.

I resigned myself to the ship already having sailed re the overall verbosity of the advanced data options, particularly -a, but I do try to keep the basic output modes, no -x or -a, to be similarly short to the original inxi. Or at least recognizably so.

If anyone can think of other power daemons to check for, this is my current list:

Code:

apmd gnome-power-manager gsd-power org_kde_powerdevil mate-power-manager power-profiles-daemon tlp upowerd xfce4-power-manager

That's GNOME, KDE, Xfce, MATE, and some more generic ones. I didn't look into that too much, this is a brand new feature so I'm sure I missed several connected to desktops.

h2-1 · 01-30-2024, 05:31 PM

I almost forgot this one, just about to release 3.3.32, but added a udevadm version test (new refactored inxi version tool makes this much easier), and now shows a version too old message for no udevadm data and version less than 249.

This will probably go out the door, i was testing this on older server and it reminded me I'd never handled udevadm version issues explicitly with error messages to inform as to why it didn't get the data, when we discovered here why.

h2-1 · 01-30-2024, 10:45 PM

inxi 3.3.32 is now released, finally, 3 months, biggest changelog ever, I think:

https://codeberg.org/smxi/inxi/src/b...inxi.changelog

Note I'm maintaining the codeberg mirroring to github for one or two more inxi releases, but the pinxi is not mirrored anymore (though the last version in github has the new update URLs in it, so just takes running -U 2x to get the actually new pinxi).

But packagers probably want to change to the codeberg repo urls if they haven't already.

I'm really not fond of feeding Microsoft's code theft tool copilot this type of code because the problems it solves are not common, so I know if someone asks for a solution related to one of these features, they are likely to get some bad copy of inxi logic, though the good side it's in Perl, so that helps.

Thanks for the crucial help finding the real issues with udevadm RAM, which was one reason i wanted to make sure to add the clear message as to why udevadm may fail to give the RAM, version too low, the Slackware 15.0 version was too low if I remember right, so I wanted that to be clear to Slackware users as to why no RAM specifically with udevadm.

chrisretusn · 01-30-2024, 10:58 PM

Congratulations on this new release. A lot of work went in to it, just finish read your changelog, wow! It's break time.

babydr · 01-31-2024, 07:20 PM

@h2-1 , I am with chrisretusn on the Congratulations & It's break time ...

I Finally Figured out what is meant by your '2x' update with pinxi -U Twice .

Please disregard ... JimL

Tho , When trying to upgrade my inxi using pinxi ...
Undoubtedly I am not doing something correctly .

Code:

# /usr/local/sbin/pinxi -U 2x
Error 10: Unsupported value: 2x for option: U
Check -h for correct useage.

# /usr/local/sbin/pinxi -U2x
Error 10: Unsupported value: 2x for option: U
Check -h for correct useage.

# /usr/local/sbin/pinxi -U  
Starting pinxi self updater.
Using curl as downloader.
Currently running pinxi version number: 3.3.31
Current version patch number: 70
Current version release date: 2024-01-23
Updating pinxi in /usr/local/sbin using pinxi main branch as download source...
Validating downloaded data...
Successfully updated to pinxi main branch version: 3.3.32
New pinxi main branch version patch number: 01
New pinxi main branch version release date: 2024-01-30
To run the new version, just start pinxi again.
----------------------------------------

Skipping man download because branch version is being used.

Then trying it again I got the same thing ...

Code:

# /usr/local/sbin/pinxi -U 2x
Error 10: Unsupported value: 2x for option: U
Check -h for correct useage.

# /usr/local/sbin/pinxi -v   
CPU: quad core Intel Xeon E3-1225 V2 (-MCP-) speed/min/max: 1596/1600/3600 MHz
Kernel: 5.4.198 x86_64 Up: 17d 2h 9m Mem: 26.07/31.31 GiB (83.3%)
Storage: 10.91 TiB (23.7% used) Procs: 397 Shell: Bash pinxi: 3.3.32-1

h2-1 · 01-31-2024, 07:38 PM

Sorry, I was using shorthand:

to get current pinxi if you were using an older one:

pinxi -U && pinxi -U

the first updates to the new codeberg URLs, the second updates the actual pinxi.

I don't remember which version I stopped updating the github pinx, maybe 3.3.31-30 or something?

However, you got it since you are now on 3.3.32-1, sorry for being unclear. 2x = do it 2 times, but that obviously wasn't completely obvious. I fall into using shorthand after doing this stuff too long.

baumei · 02-01-2024, 09:41 PM

Hi "h2-1",

Here is the output from my little old laptop, which is still in use every day. (-:

Code:

user1@darkstar:/tmp/pinxi$ ./pinxi -SIGmaz --vs
pinxi 3.3.32-01 (2024-01-30)
System:
  Kernel: 5.15.145-smp arch: i686 bits: 32 compiler: gcc v: 2.37-slack15 clocksource: tsc
    avail: hpet,acpi_pm parameters: auto BOOT_IMAGE=Slackware ro root=802 logo.nologo ipv6.disable=0
  Console: tty 3 DM: startx Distro: Slackware 15.0
Memory:
  System RAM: total: N/A available: 983 MiB used: 706.7 MiB (71.9%)
  RAM Report: message: Installed udevadm v243. Requires >= 249. Try root?
Graphics:
  Device-1: Intel Atom Processor D2xxx/N2xxx Integrated Graphics vendor: ASUSTeK driver: gma500
    v: N/A alternate: gma500_gfx arch: PowerVR SGX545 process: Intel 65nm built: 2008-10 ports:
    active: LVDS-1 empty: DP-1,DVI-D-1,VGA-1 bus-ID: 00:02.0 chip-ID: 8086:0be1 class-ID: 0300
  Device-2: IMC Networks USB 2.0 UVC VGA WebCam driver: uvcvideo type: USB rev: 2.0
    speed: 480 Mb/s lanes: 1 mode: 2.0 bus-ID: 1-3:2 chip-ID: 13d3:5711 class-ID: 0e02
    serial: <filter>
  Display: server: X.org v: 1.20.14 driver: X: loaded: modesetting gpu: gma500 tty: 128x37
  Monitor-1: LVDS-1 model: InfoVision Optronics/Kunshan 0x03f4 built: 2011 res: 1024x600
    dpi: 118 gamma: 1.2 size: 479x125mm (18.86x4.92") diag: 256mm (10.1") ratio: 15:9, 16:9
    modes: 1024x600
  API: EGL v: 1.4 platforms: gbm: drv: N/A inactive: wayland,x11,device
  API: OpenGL Message: GL data unavailable in console. Try -G --display
  API: Vulkan v: 1.2.176 layers: 13 device: 0 type: cpu name: llvmpipe (LLVM 13.0.0 128 bits)
    driver: mesa llvmpipe v: 21.3.5 (LLVM 13.0.0) device-ID: 10005:0000 surfaces: N/A
Info:
  Processes: 418 Power: uptime: 30d 23h 20m states: freeze,mem,disk suspend: deep avail: s2idle
    wakeups: 61 hibernate: platform avail: shutdown,reboot,suspend,test_resume image: 389.5 MiB
    Init: SysVinit v: 3.01 runlevel: 3 default: 3 tool: /etc/rc.d
  Packages: pm: pkgtool pkgs: 992 libs: 190 tools: slackpkg Compilers: clang: 13.0.0 gcc: 11.2.0
    Shell: Bash (login) v: 5.1.16 running-in: tty 3 pinxi: 3.3.32-1

The size of "Monitor-1" is actually about 8.80" by 5.00"; the diagonal size listed above (10.1") is about right.

h2-1 · 02-05-2024, 07:28 PM

Mainly due to the huge number of changes, inxi 3.3.32 went out the door with a ToDo list, but a quick bug report from 3.3.32, which crashes inxi in one corner case, led to my pushing a few new features into inxi, so I can release 3.3.33 in a few days.

Besides the bug fix, I've extended the 'services:' report from just Power: to also Network: Info: item, which is new.

This is the list I'm working off so far, any additional network daemon's/services you can think of that should be included are appreciated so I can get the list as comprehensive as practical.

Code:

connmand dhcpd dhcpleased fingerd ftpd 
gated httpd inetd ircd iwd ModemManager 
named networkd-dispatcher NetworkManager nfsd nginx ntpd 
routed smbd sshd systemd-networkd systemd-timesyncd 
tftpd wicd wpa_supplicant xinetd xntpd

Those are the ps command names. This shows with -na or -ia, not with -Na. These are from a variety of systems, mostly servers.

Code:

Network:
  Device-1: Aquantia AQC111 NBase-T/IEEE 802.3bz Ethernet [AQtion] vendor: QNAP Systems
    driver: atlantic v: kernel pcie: gen: 3 speed: 8 GT/s lanes: 1 link-max: lanes: 4 port: N/A
    bus-ID: 01:00.0 chip-ID: 1d6a:11b1 class-ID: 0200 temp: 47.0 C
  IF: enp1s0 state: up speed: 100 Mbps duplex: full mac: <filter>
  Info: services: NetworkManager, ntpd, sshd, systemd-timesyncd

pinxi -naz
Network:
  Device-1: Intel I350 Gigabit Network driver: igb port: N/A bus-ID: 0:6:0.0 chip-ID: 8086:1521
    class-ID: 0200
  IF: igb0 state: active speed: 1000baseT duplex: full-duplex mac: <filter>
  Device-2: Intel I350 Gigabit Network driver: igb port: N/A bus-ID: 0:6:0.1 chip-ID: 8086:1521
    class-ID: 0200
  IF: igb1 state: no carrier speed: N/A duplex: N/A mac: <filter>
  Info: services: sshd

pinxi -naz
Network:
  Device-1: Intel I350 Gigabit Network vendor: Super Micro driver: igb v: 5.6.0-k pcie: gen: 2
    speed: 5 GT/s lanes: 4 port: 8020 bus-ID: 02:00.0 chip-ID: 8086:1521 class-ID: 0200 temp: 61.0 C
  IF: eth0 state: up speed: 1000 Mbps duplex: full mac: <filter>
  Device-2: Intel I350 Gigabit Network vendor: Super Micro driver: igb v: 5.6.0-k pcie: gen: 2
    speed: 5 GT/s lanes: 4 port: 8000 bus-ID: 02:00.1 chip-ID: 8086:1521 class-ID: 0200
  IF: eth1 state: up speed: 1000 Mbps duplex: full mac: <filter>
  Info: services: httpd, proftpd, sshd, systemd-networkd, xinetd

pinxi -naz
Network:
  Device-1: Intel I211 Gigabit Network vendor: Gigabyte driver: igb v: kernel
    pcie: gen: 1 speed: 2.5 GT/s lanes: 1 port: d000 bus-ID: 08:00.0
    chip-ID: 8086:1539 class-ID: 0200
  IF: enp8s0 state: up speed: 1000 Mbps duplex: full mac: <filter>
  Info: services: apache2, inetd, smbd, sshd, systemd-networkd,
    systemd-timesyncd, wpa_supplicant

Adding stuff like this is a lot easier with the new internal refactors, so I figured, why not? Now, if someone has a notion of a valid why not, I'd like to hear that too of course.

h2-1 · 02-07-2024, 02:25 PM

The quick point release 3.3.33 is out the door, squeezed in some nice little features, refactors, and tools into it

Hoping I didn't also squeeze in fresh bugs, lol, but you never know. Luckily the changes/refactors were very local, and not wide ranging like in 3.3.32, the latter almost certainly would, and did, contain bugs due to so many core changes. But refreshingly corner case, and easy to fix, no logic errors, just some spare characters left in place in one place.

This will hopefully set the creaking ship inxi onto a reasonably maintainable path into the future, though the large codebase and complexity, plus being in Perl, makes that future less than certain. But all shipshape for the itme being! At least I hope so.

Thanks for the help. The udevadm RAM feature is one that actually still surprises me when I see it running on servers without root, I'm like, oh, I got a RAM report without having root on this machine!! And with the proper RAM Array handling. I have not, by the way, seen that fail yet, but the systems are all too similar to draw any real conclusions from, all supermicro boards, with the exception of some of the ones here, which is partly what makes me hope this may actually cover many if not most complex server/workstation type motherboards.

It's odd, previously the only OS I could get RAM data from as user was OpenBSD, I think they may have used something similar to what udevadm is doing during boot to create a static list of RAM, though it is not, I believe, as granular, but that's fine.

There's not many places where BSD support is ahead of Linux, but there are a few, but now Linux has caught up.

By the way, I was testing the udevadm stuff and found that for example Ubuntu 20.04 based systems shipped with udevadm 245, so this addition is quite recent relatively speaking. The Ubuntu 22.04 LTS release had 249, so had just added it basically. Never did find the exact udevadm version where the ram data was added, but have only seen 249 and 245, nothing in between so far.

However, it won't matter since inxi only shows the too old version if no ram data AND version < 249, so if say, 248 or 246 added it, it will show fine.

marav · 05-04-2024, 10:47 AM

Hi h2-1

Since slpkg has totally changed its /etc/slpkg/repositories.toml

Code:

No active slpkg repos in: /etc/slpkg/repositories.toml

New repositories.toml

Code:

ENABLE = true/false

Is it possible to make changes to inxi (inxi -r) in compliance with how the file is made now?

h2-1 · 05-05-2024, 11:25 AM

Oh, I wish I could have squeezed this into 3.3.34, which was a bunch of smallish fixes across many features.

Can you post a sample file of repositories.toml, the full thing, with any whitespace preserved etc.

Ideally with a few variants of possible repos and syntaxes, if applicable. I'll run that through the repo debugger and post working result, when it's working, of course.

thanks

marav · 05-05-2024, 11:43 AM

Quote:

Originally Posted by h2-1

Oh, I wish I could have squeezed this into 3.3.34, which was a bunch of smallish fixes across many features.

Can you post a sample file of repositories.toml, the full thing, with any whitespace preserved etc.

Ideally with a few variants of possible repos and syntaxes, if applicable. I'll run that through the repo debugger and post working result, when it's working, of course.

thanks

Here is mine