Scheduled Maintenance: We are aware of an issue with Google, AOL, and Yahoo services as email providers which are blocking new registrations. We are trying to fix the issue and we have several internal and external support tickets in process to resolve the issue. Please see: viewtopic.php?t=158230
Did 0443 fix the issue? If not, it's just a matter of some paths being slightly off. Since the data has to come from /sys, that's where I have to find it, or rather, that's where pinxi has to find it.
I have to buy myself some usb networking devices, I just don't use them, I'll double check to see if I have some lying around in case the 0443 fix did not do the job, but it should.
so I believe it probably works now, but confirm or deny the latest version as fixing it or not, if not, it's probably just a small path glitch because it's late here.
As usual, update with; pinxi -U
Pinxi doesn't actually use readlink, it's just the nearest shell equivalent, it actually uses abs_path, so the real question is if latest pinxi works or not.
sunrat, fantastic! that was not easy to figure out, quite the little puzzle, so I'm relieved that it works for you or it would have been frustrating.
The great thing about this fix is it handles both audio and network devices. that's certainly WAY better than the old default value, that's for sure, I'm glad you brought that up, thanks.
debiman, can you paste or link to paste of /proc/cpuinfo from that arm system - that output is obviously messed up.
I have limited datasets from arm systems, but it looks like the cpu was the only thing that glitched, so I can fix that pretty easily with a copy of /proc/cpuinfo from that system.
pawRoot, I assumed it was 3, so 2.9.00-0443-p should have that corrected. The giveaway is the trimmed off 'v'' from version, the version tool always trims extra vs off the numbers to avoid stuff like v2.34.i, which told me right away that version was in column 2, and the number probably in column 3. Thanks for verifying.
this machine runs armbian btw, which is really based on ubuntu. i hope i won't get kicked out of fdn for that
armbian compiles some system info for /etc/motd, i had a glance at the scripts, they seem to compile a lot of info for many different devices. maybe you should look at that. it outputs to /var/run/motd.dynamic, and the script is in /etc/init.d/armhwinfo, but i couldn't find out what package it belongs to.
debiman, just when I think I've seen every variant, a new one pops up, that will require special handling, thanks.
I'm going to have to add some more rules to the die detection, I've already had to remove it for all non arm/ryzen devices because there is really no way to determine it dynamically. And to be fair, someone on IRC mocked my belief that arm would be consistent, so they'll get a chuckle from your example.
Since it's very unlikely they built a 4 core cpu with 4 separate dies, I'm going to add in some filters to get rid of such circumstances.
that's the entire proc/cpuinfo I take it?, no edits?
I've thrown a curve ball with this one because my current interactive (and login) shell is Microsoft's PowerShell, I think it's fairly safe to assume that no other GNU/Linux users will try this
I will edit this post later with output from my other systems.
Last edited by Head_on_a_Stick on 2018-03-18 19:29, edited 1 time in total.
Head_on_a_Stick, is there a command: pwsh --version ?
I'm curious to see why it shows () as well, that might be in ps aux, not sure.
Oh, I just noticed, make sure to install pinxi, not inxi, inxi isn't what is being tested, it's what is being replaced. I thought there was something off about the output.
debiman, I've realized that your cpu arm glitch actually covers an entire range of ARM failures, and that I can correct missing Machine data as well using this processor data in some case.
I believe I'll in an arm pretest that runs if -M or -C are used that will trip a flag that tells pinxi to look for this specific type of data, and to also print the missing machine data as well.
This will correct the basic cpu errors, and provide the system information as well, I'll work on that, should be up fairly soon. I use a similar logic for various bsd data features, though there are 3 missing (battery, machine, and sensors) for bsds, but the data is present, it's just not used yet.
Head_on_a_Stick, I'm particularly interested to see the -zv8 output of openbsd and alpine. I actually put a fair amount of work into openbsd support during the dev process for pinxi, as noted, it's missing 3 data types which are available to pinxi internally but not yet implemented, sensors, machine (without needing dmidecode/root), and battery. Dragonfly and openbsd have been good about getting this data into sysctl -a, freebsd as far as I know has not been as good there for those types.
Great stuff, I asked for corner fringe cases, and I'm getting them, really helpful.
Head_on_a_Stick, some issues:
1. what is: ps aux | grep xinit
I'll need that to add xinit to start up types. This test will be slightly risky, but because it only runs if no display manager was found, and will be a fallback to startx test, it might work. This will be in 0436-p. Note that this is not a very good or reliable test because xinit will often be present in the ps aux data regardless of what dm started the desktop/wm.
2. What is: clang --version
your output isn't matching other clang version output, that is, there's an extra word in there in the version string from other clang versions I've seen. This may require custom filters
3. I will have to correct the memory array max size, in inxi, if it had no value, it was not shown, but I believe it should actually show an estimated value when null, which it does, sometimes, in certain cases, but that should be extended to all cases since I'm now having pinxi print that max memory size per slot item always.
UPDATE: Corrected in 0448-p
4. Not in your data, but there's a failure to properly id USB networking devices
5. the ksh issue I'm not sure is a pinxi issue, pinxi shows ksh there because that's what the shell identified itself as to pinxi. Sometimes the shells people believe are running under pinxi are not the actual shells running, and since pinxi uses the shell it's given by the system, that's all it can know. I've added loksh however to the list of known ksh variants internally, so if it appears as the shell id, it should return the value you listed: 5.2.14 (the v trimmed off)
6. The dwm fork, as long as it's called dwm, might be a bug on your end possibly, since if it's calling itself dwm, it would have been picked up by pinxi in the fallback wm section. If it appears in ps aux under some other name, that's why it wasn't found.
pinxi does two things when it tests for a desktop/wm variant: first, it checks that the program name exists, basically the equivalent of: which dwm
If it passes that test, it goes on to the more expensive test, to see if it's running in ps aux. It does that because pinxi has to test a lot of possible values to determine the non major desktops, so the test has to be reasonably efficient. So that's the two things needed for pinxi to find a desktop that does not complete XDG_CURRENT_DESKTOP (and even the ones that do, don't always do it, I've actually seen a distro REMOVE that value in their release...) or which is not locate-able in xprop -root (another expensive test). Identifying desktops is FAR more difficult than it should be, in a perfect world, they'd all export to XDG_CURRENT_DESKTOP and that would literally be the only test pinxi needs to run to determine what the desktop is, but sadly, we don't live in that world, we live in a really messy inconsistent one.
As an aside, dwm is one of the wm that outputs version info to stderr, which would be another place it could fail, since that has to be tested for explicitly by program name. scrotwm does that too. dwm also has the version number in the first column of output, or did. But the version info would only trip if pinxi had gotten a name it knows about to work with, which it did not.
7. With slight trepidation, I'm removing the cascade of tests for repos, previously it was apt first, then a list of choices in if/elsif structure. I've now removed the elsif and made each variant a possible value no matter what was found before it. That should cover cases like your alpine, and since -r is an option that you only use if you want to see the output, or if you used -v8, that should be ok.
1. arm pinebook, this helped resolve 2 issues. First, I hope an improved ARM cpu count and model id, and no more false cpu core counts, plus an attempt to be a bit smarter with die counts, in this case, if its' guess at die count equals core count, it dumps it since it's probably wrong. Second, with the data in cpuinfo, I can create a small report in the -M data section for arm devices where no other machine data was found. That looks nice.
As far as I can tell, most arm will list hardware, rev, and serial number in cpuinfo, though the pinebook example only listed hardware, but it's still way better than pinxi did before, now at least if that data is there, it will show the device info it can glean.
2. added optional json export tool: JSON::XS, so now it can use either the new forked Cpanel::JSON::XS or the older variant, whichever, both should work fine.
3. pinxi now estimates max memory stick capacity based on the max capacity plus some othe tricks. As with all estimates for RAM array capacity and max module size, whenever the data was generated rather than read, it says, note; est|check depending on the values. If no note is appended, that means the data comes from the original source, but never trust that, it's often wrong, it's not based on reality, it's just something someone copies and pastes in, often from a different mobo altogether. The per stick data is accurate.
Some other small glitches, but I forgot them. There's still a todo item remaining, usb nics, they aren't being ID'ed completely accurately, but the audio and network usb drivers should now show if available, so that's a big improvement.
but it's actually just a final fallback test before it gives up, there's no actual way I know to determine what the init system was there. The way pinxi determines that the init is SysVinit is literally just a series of steps, with that being the last one, and if /etc/inittab is there, and no other init was found, it assumes SysVinit, and tries to get the version using strings as above, in your case, since it's not sysvinit, it did get the version, but the wrong part of the string.
If you have this file, what is the content: cat /proc/1/comm
Some inits can be found in there, systemd, epoch, and runit
So I'd need info on how to detect busybox if that's what the init system is.
OpenRc would not show as init, but I believe I forgot to add in the rc: item if it's present, that's a bug, oops. Yes, I checked, I simply forgot to add in the print out of rc data, completely slipped my mind. That's been corrected in 2.9.00-451-p
I will have to answer your Alpine questions later, I'm in OpenBSD now, for the init question `ls -l /sbin/init` shows a symlink to busybox (systemd also symlinks to init) so perhaps you could use that.
Also, I would just note that BunsenLabs exports XDG_CURRENT_DESKTOP=XFCE but is in fact an openbox/tint2 distribution, how's that for an edge case?
Anyway, here's the output from a freshly-updated OpenBSD-current system:
Puffy:~$ doas pinxi -zv8
System: Host: Puffy.lan Kernel: OpenBSD 6.3 amd64 bits: 64 compiler: N/A Desktop: N/A dm: startx
OS: OpenBSD 6.3
Machine: Missing: Required program dmidecode not available
Battery: Missing: Required program dmidecode not available
Memory: RAM Report: missing: Required program dmidecode not available
PCI Slots: Missing: Required program dmidecode not available
CPU: Topology: Quad Core model: Intel Core i5 M 520 type: MCP arch: N/A L2 cache: N/A
features: N/A
Speed: 2400 MHz min/max: N/A Core speeds: 1: 0 2: 0 3: 0 4: 0
Graphics: Message: No PCI card data found.
Display Server: X.Org 1.19.6 driver: intel resolution: 1280x800~60Hz
OpenGL: renderer: Mesa DRI Intel Ironlake Mobile version: 2.1 Mesa 13.0.6 direct render: Yes
Audio: Message: No PCI card data found.
Network: Message: No PCI card data found.
WAN IP: <filter>
Drives: HDD Total Size: N/A used: 6.98 GB
ID-1: /dev/sd0 model: N/A size: N/A serial: N/A
Optical Report: No floppy or optical data found for this BSD system.
RAID: Message: No RAID data was found.
Partition: ID-1: / size: 1004.8 MB used: 81.7 MB (8.1%) fs: dev: /dev/sd0a label: N/A uuid: N/A
ID-2: /home size: 44.29 GB used: 3.67 GB (8.3%) fs: local dev: /dev/sd0m label: N/A uuid: N/A
ID-3: /tmp size: 3.93 GB used: 13.5 MB (0.3%) fs: local dev: /dev/sd0d label: N/A uuid: N/A
ID-4: /usr size: 7.87 GB used: 1.38 GB (17.6%) fs: local dev: /dev/sd0f label: N/A uuid: N/A
ID-5: /usr/X11R6 size: 1.97 GB used: 178.7 MB (8.9%) fs: local dev: /dev/sd0g label: N/A uuid: N/A
ID-6: /usr/local size: 9.84 GB used: 1.65 GB (16.7%) fs: local dev: /dev/sd0h label: N/A uuid: N/A
ID-7: /usr/obj size: 1.97 GB used: 2 KB (0.0%) fs: local dev: /dev/sd0l label: N/A uuid: N/A
ID-8: /usr/src size: 1.97 GB used: 2 KB (0.0%) fs: local dev: /dev/sd0k label: N/A uuid: N/A
ID-9: /var size: 3.93 GB used: 16.6 MB (0.4%) fs: local dev: /dev/sd0e label: N/A uuid: N/A
ID-10: swap-1 size: 2.00 GB used: 0 KB (0.0%) fs: swap dev: /dev/sd0b label: N/A uuid: N/A
Unmounted: Message: No unmounted partition data found for this BSD system.
USB: Hub: 0:1 usb: high speed type: Intel EHCI root hub chip ID: 0000:8086
Device-1: Intel Rate Matching Hub bus ID: 0:2 usb: high speed type: N/A chip ID: 0020:8087
Hub: 1:1 usb: high speed type: Intel EHCI root hub chip ID: 0000:8086
Device-2: Intel Rate Matching Hub bus ID: 1:2 usb: high speed type: N/A chip ID: 0020:8087
Sensors: Platform: No Openbsd support. Is a comparable sensors tool available?
Repos: Alert: No repo data detected. Does pinxi support your OS type?
Processes: CPU % used - Command - pid - Memory: MB / % used - top: 5
1: cpu: 0.3% command: xterm pid: 41016 mem: 9.56MB (0.2%)
2: cpu: 0.1% command: x pid: 16020 mem: 23.8MB (0.6%)
3: cpu: 0.0% command: init pid: 1 mem: 0.44MB (0.0%)
4: cpu: 0.0% command: syslogd: pid: 37109 mem: 1.99MB (0.1%)
5: cpu: 0.0% command: syslogd pid: 23540 mem: 1.64MB (0.0%)
Memory MB/% used - Command - pid - CPU: % used - top: 5
1: mem: 146.4 MB (0.0%) command: chrome: pid: 54269 cpu: 3.8%
2: mem: 145.8 MB (0.0%) command: chrome: pid: 83913 cpu: 3.8%
3: mem: 134.8 MB (0.0%) command: chrome: pid: 4726 cpu: 3.5%
4: mem: 123.1 MB (0.0%) command: chrome: pid: 51087 cpu: 3.2%
5: mem: 112.6 MB (0.0%) command: chrome: pid: 50977 cpu: 2.9%
ps: unknown option -- f
usage: ps [-AaceHhjkLlmrSTuvwx] [-M core] [-N system] [-O fmt] [-o fmt] [-p pid]
[-t tty] [-U username] [-W swap]
Info: Processes: 54 Uptime: 1:01 Memory: used: Init: init (BSD) v: N/A Compilers: gcc: 4.2.1 clang: ersion
Shell: ksh pinxi: 2.9.00-451-p
Puffy:~$
I don't know of any dmidecode equivalent in OpenBSD and you may want to look at ps(1), here is a summary of the available sensors on my platform (ThinkPad X201):
Versioning is tricky with -current because it changes all the time — mine was identifying itself as "6.3-beta" until Friday's update when it started calling itself "6.3", I think the release is just around the corner.