New inxi / pinxi features: user RAM reports! And much more! Testers?
by h2-1 from LinuxQuestions.org on (#6HX6Y)
Support for the udevadm sourced ram data is in final testing phase in inxi now, I just heard about this option from someone posting an inxi codeberg feature request. This is the source of the data:
Code:udevadm info -p /devices/virtual/dmi/idWhile that path suggests this data comes from /sys/devices/virtual/dmi/id, it actually doesn't, or I would have used it years ago. That's where the board/chassis/bios data lives, and oddly, udevadm barely shows any of that.
Slackware appears to be using the eudev package to provide udevadm, not sure if that's a standard install item, it was in my test, but I used Slax to verify. eudev is what inxi shows for slackware in --recommends anyway, correct please if wrong.
Since inxi already had the logic to handle the low quality dmi data from dmidecode, which needs a lot of filters, and some core logic to make sure the results are not logically impossible, implementing the udevadm sourced version was pretty straightforward since all I had to do was tweak the existing logic for the udevamd data. I was kind of lucky because all the hard fixes, logic corrections, tests, etc, were done a long time ago for dmidecode sourced ram data, so udevadm as data source did not take that long to add.
There are so far two significant issues with udevadm data I've found, first, and most likely to be visible to average users, is the RAM voltages appear to be broken, in all my tests, systems that returned voltages return 1 for all, min, max, configured, which is clearly wrong. The other is that while dmidecode correctly assigns the main RAM Array to a handle, then links the RAM Device module reports to that handle, in udevadm it appears they assume that there will never be more than one RAM system board array. That's very corner case, but it is an odd oversight.
If anyone has, which I know is a stretch, a box with 2 system board memory arrays (which would show as 2 separate type 16 memory devices, those are the Arrays), I'm particularly interested in those. Or remote access to one, that's going to be a big server for sure.
A few other differences, which are actually improvements, is the speeds are all MT/s, and the sizes are in Bytes. dmidecode changes sizes to human readable, which takes more processing to deal with.
But given for most users, most of the time, this data will be largely correct (assuming the logic tests run to correct obviously impossible situations), and also, will for the first time let you get data without dmidecode (I think, not sure where udevadm is getting it's dmi data from, will test to verify it still works without dmidecode).
You can play around with this now:
https://codeberg.org/smxi/pinxi
or quick shortcut install:
Code:wget smxi.org/pinxi && chmod +x pinxiI put pinxi in /usr/local/bin so it's in path, but it doesn't matter where it is.
If you already have pinxi installed, just use its self updater:
Code:pinxi -Uand then
Code:pinxi -SIGma --vs
# or for public posts
pinxi -SIGmaz --vsNote that -S, -I, and -G have seen the most upgrades, refactors, and enhancements, but the non root/sudo -ma showing data was not an expected feature for this upcoming release until last week, when I got an issue saying it was possible, which I'd never known.
I still have some fine tunings, but I'm shooting to release this as next inxi, 3.3.32 within a week, unless some testers can find failure cases that need handling, which is often the case with RAM data sources.
Note that if you get what you believe are wrong or misleading results, and want to help improve it, supply:
Code:udevadm info -p /devices/virtual/dmi/id > udevadm-data.txtand upload it somewhere, or here, most systems the data is not too long. Feel free to slightly alter the serial numbers if you don't want those to show, I'm doing that on all the test files I'm adding to the pinxi/data/ram/udevadm/ as I go along, I just XXXX out half the serial nummber, but leave enough unique so I can tell it's working.
I was checking some last minute details and testing some stuff, for example, udevadm version 174 does not appear to have this feature, at least not in TinyCore, though I know the dmi data is there, so I was wondering when it was added.
Sample from my system [sorry, forum gets rid of indentation]:
Code:pinxi -maz --vs
pinxi 3.3.31-45 (2024-01-16)
Memory:
System RAM: total: 32 GiB available: 31.27 GiB used: 11.44 GiB (36.6%)
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>
Any tests, feedback, etc appreciated, and in particular, any data samples that show it not working when dmidecode did.
Note that if you have dmidecode installed, pinxi will use that automatically for sudo/root start of inxi, though you can force udevadm with --force udevadm, so it's easy to compare the two sources for variations.
Note that dmidecode has more data than udevadm, which offers up a sort of basic summary per array and module, but the data is pretty close and inxi didn't use all the dmidecode values anyway, so it's quite similar.
Thanks for looking, and testing, if you feel so inclined.
Code:udevadm info -p /devices/virtual/dmi/idWhile that path suggests this data comes from /sys/devices/virtual/dmi/id, it actually doesn't, or I would have used it years ago. That's where the board/chassis/bios data lives, and oddly, udevadm barely shows any of that.
Slackware appears to be using the eudev package to provide udevadm, not sure if that's a standard install item, it was in my test, but I used Slax to verify. eudev is what inxi shows for slackware in --recommends anyway, correct please if wrong.
Since inxi already had the logic to handle the low quality dmi data from dmidecode, which needs a lot of filters, and some core logic to make sure the results are not logically impossible, implementing the udevadm sourced version was pretty straightforward since all I had to do was tweak the existing logic for the udevamd data. I was kind of lucky because all the hard fixes, logic corrections, tests, etc, were done a long time ago for dmidecode sourced ram data, so udevadm as data source did not take that long to add.
There are so far two significant issues with udevadm data I've found, first, and most likely to be visible to average users, is the RAM voltages appear to be broken, in all my tests, systems that returned voltages return 1 for all, min, max, configured, which is clearly wrong. The other is that while dmidecode correctly assigns the main RAM Array to a handle, then links the RAM Device module reports to that handle, in udevadm it appears they assume that there will never be more than one RAM system board array. That's very corner case, but it is an odd oversight.
If anyone has, which I know is a stretch, a box with 2 system board memory arrays (which would show as 2 separate type 16 memory devices, those are the Arrays), I'm particularly interested in those. Or remote access to one, that's going to be a big server for sure.
A few other differences, which are actually improvements, is the speeds are all MT/s, and the sizes are in Bytes. dmidecode changes sizes to human readable, which takes more processing to deal with.
But given for most users, most of the time, this data will be largely correct (assuming the logic tests run to correct obviously impossible situations), and also, will for the first time let you get data without dmidecode (I think, not sure where udevadm is getting it's dmi data from, will test to verify it still works without dmidecode).
You can play around with this now:
https://codeberg.org/smxi/pinxi
or quick shortcut install:
Code:wget smxi.org/pinxi && chmod +x pinxiI put pinxi in /usr/local/bin so it's in path, but it doesn't matter where it is.
If you already have pinxi installed, just use its self updater:
Code:pinxi -Uand then
Code:pinxi -SIGma --vs
# or for public posts
pinxi -SIGmaz --vsNote that -S, -I, and -G have seen the most upgrades, refactors, and enhancements, but the non root/sudo -ma showing data was not an expected feature for this upcoming release until last week, when I got an issue saying it was possible, which I'd never known.
I still have some fine tunings, but I'm shooting to release this as next inxi, 3.3.32 within a week, unless some testers can find failure cases that need handling, which is often the case with RAM data sources.
Note that if you get what you believe are wrong or misleading results, and want to help improve it, supply:
Code:udevadm info -p /devices/virtual/dmi/id > udevadm-data.txtand upload it somewhere, or here, most systems the data is not too long. Feel free to slightly alter the serial numbers if you don't want those to show, I'm doing that on all the test files I'm adding to the pinxi/data/ram/udevadm/ as I go along, I just XXXX out half the serial nummber, but leave enough unique so I can tell it's working.
I was checking some last minute details and testing some stuff, for example, udevadm version 174 does not appear to have this feature, at least not in TinyCore, though I know the dmi data is there, so I was wondering when it was added.
Sample from my system [sorry, forum gets rid of indentation]:
Code:pinxi -maz --vs
pinxi 3.3.31-45 (2024-01-16)
Memory:
System RAM: total: 32 GiB available: 31.27 GiB used: 11.44 GiB (36.6%)
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>
Any tests, feedback, etc appreciated, and in particular, any data samples that show it not working when dmidecode did.
Note that if you have dmidecode installed, pinxi will use that automatically for sudo/root start of inxi, though you can force udevadm with --force udevadm, so it's easy to compare the two sources for variations.
Note that dmidecode has more data than udevadm, which offers up a sort of basic summary per array and module, but the data is pretty close and inxi didn't use all the dmidecode values anyway, so it's quite similar.
Thanks for looking, and testing, if you feel so inclined.