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

 

 

 

Beta testers for new Perl inxi requested

If none of the specific sub-forums seem right for your thread, ask here.
Message
Author
h2
Posts: 131
Joined: 2006-10-29 20:00
Location: USA

Re: Beta testers for new Perl inxi requested

#31 Post by h2 »

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.
smxi/sgfxi site (manuals, how-to's, faqs) :: script forums :: Check out inxi sys info script!

User avatar
Head_on_a_Stick
Posts: 14114
Joined: 2014-06-01 17:46
Location: London, England
Has thanked: 81 times
Been thanked: 132 times

Re: Beta testers for new Perl inxi requested

#32 Post by Head_on_a_Stick »

h2 wrote:is there a command: pwsh --version ?

Code: Select all

PS /home/empty> $PSVersionTable.PSVersion                                                 

Major  Minor  Patch  PreReleas BuildLabel 
                     eLabel               
-----  -----  -----  --------- ---------- 
6      0      2                           


PS /home/empty>
make sure to install pinxi, not inxi, inxi isn't what is being tested, it's what is being replaced.
Ah, right, OK, I will edit the output in a minute.
deadbang

h2
Posts: 131
Joined: 2006-10-29 20:00
Location: USA

Re: Beta testers for new Perl inxi requested

#33 Post by h2 »

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.
smxi/sgfxi site (manuals, how-to's, faqs) :: script forums :: Check out inxi sys info script!

h2
Posts: 131
Joined: 2006-10-29 20:00
Location: USA

Re: Beta testers for new Perl inxi requested

#34 Post by h2 »

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.
smxi/sgfxi site (manuals, how-to's, faqs) :: script forums :: Check out inxi sys info script!

User avatar
Head_on_a_Stick
Posts: 14114
Joined: 2014-06-01 17:46
Location: London, England
Has thanked: 81 times
Been thanked: 132 times

Re: Beta testers for new Perl inxi requested

#35 Post by Head_on_a_Stick »

I have edited my post, it now has the correct `pinxi` output:

http://forums.debian.net/viewtopic.php?p=669463#p669463

I will post back soon with the Alpine Linux output.
deadbang

User avatar
Head_on_a_Stick
Posts: 14114
Joined: 2014-06-01 17:46
Location: London, England
Has thanked: 81 times
Been thanked: 132 times

Re: Beta testers for new Perl inxi requested

#36 Post by Head_on_a_Stick »

Alpine Linux (tracking the edge branch):

Code: Select all

alpine: ~ $ sudo pinxi -zv8
[sudo] password for empty: 
System:    Host: alpine Kernel: 4.14.27-0-vanilla x86_64 bits: 64 compiler: gcc v: 6.4.0 Console: tty 1 
           dm: N/A Distro: Alpine Linux v3.7 
Machine:   Type: Laptop System: Notebook product: W54_55SU1,SUW v: N/A serial: N/A Chassis: type: 9 
           serial: N/A 
           Mobo: Notebook model: W54_55SU1,SUW serial: N/A BIOS: American Megatrends v: 4.6.5 
           date: 10/07/2013 
Battery:   BAT-0: charge: 29.7 Wh condition: 29.7/62.2 Wh (48%) volts: 12.7/11.1 model: Notebook BAT 
           type: Li-ion serial: <filter> status: Full 
Memory:    Array-1: capacity: 32 GB slots: 4 EC: None max module size: N/A 
           Device-1: ChannelA-DIMM0 size: 4 GB speed: 1600 MT/s type: DDR3 detail: synchronous 
           bus width: 64 bits total: 64 bits manufacturer: Samsung part-nu: M471B5273CH0-CK0 
           serial: 967C1A7C 
           Device-2: ChannelA-DIMM1 size: No Module Installed 
           Device-3: ChannelB-DIMM0 size: 4 GB speed: 1600 MT/s type: DDR3 detail: synchronous 
           bus width: 64 bits total: 64 bits manufacturer: Samsung part-nu: M471B5273CH0-YK0 
           serial: 1466BE66 
           Device-4: ChannelB-DIMM1 size: No Module Installed 
PCI Slots: Slot: 0 type: x16 PCI Express J6B2 status: In Use length: Long 
CPU:       Topology: Dual Core model: Intel Core i5-4330M type: MT MCP arch: Haswell rev: 3 
           L2 cache: 3072 KB 
           flags: lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx bogomips: 22359 
           Speed: 898 MHz min/max: 800/3500 MHz Core speeds: 1: 881 2: 895 3: 863 4: 879 
Graphics:  Card-1: Intel 4th Gen Core Processor Integrated Graphics Controller driver: i915 v: kernel 
           bus ID: 00:02.0 chip ID: 8086:0416 
           Display Server: X.org 1.19.6 driver: intel tty: 108x80 
           Message: Advanced graphics data unavailable in console for root. 
Audio:     Card-1: Intel Xeon E3-1200 v3/4th Gen Core Processor HD Audio Controller 
           driver: snd_hda_intel v: kernel bus ID: 00:03.0 chip ID: 8086:0c0c 
           Card-2: Intel 8 Series/C220 Series High Definition Audio Controller driver: snd_hda_intel 
           v: kernel bus ID: 00:1b.0 chip ID: 8086:8c20 
           Sound Server: ALSA v: k4.14.27-0-vanilla 
Network:   Card-1: Intel Centrino Wireless-N 135 driver: iwlwifi v: kernel bus ID: 02:00 
           chip ID: 8086:0892 
           IF: wlan0 state: up mac: <filter> 
           IP v4: <filter> scope: global 
           IP v6: <filter> scope: link 
           Card-2: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller driver: r8169 
           v: 2.3LK-NAPI port: e000 bus ID: 03:00 chip ID: 10ec:8168 
           IF: eth0 state: down mac: <filter> 
           WAN IP: <filter> 
Drives:    HDD Total Size: 232.89 GB used: 11.00 GB (4.7%) 
           ID-1: /dev/sda model: Samsung_SSD_850 size: 232.89 GB serial: <filter> rev: 1B6Q 
           Optical-1: /dev/sr0 vendor: Slimtype model: DVD A DU8A5SH rev: BC61 dev-links: cdrom 
           Features: speed: 16 multisession: yes audio: yes dvd: yes rw: cd-r,cd-rw,dvd-r,dvd-ram 
           state: running 
RAID:      Message: No RAID data was found. 
Partition: ID-1: /dev/shm size: 3.86 GB used: 26.4 MB (0.7%) fs: tmpfs dev: ERR-102 label: N/A uuid: N/A 
           ID-2: / size: 29.99 GB used: 10.98 GB (36.6%) fs: xfs dev: /dev/sda5 label: N/A 
           uuid: 0148d1cd-ab02-4ff4-9008-add003459cb6 
           ID-3: /sys/fs/cgroup size: 10.0 MB used: 0 KB (0.0%) fs: tmpfs dev: ERR-102 label: N/A 
           uuid: N/A 
           ID-4: swap-1 size: 4.00 GB used: 0 KB (0.0%) fs: swap dev: /dev/sda3 label: N/A 
           uuid: 99e1b326-9eea-40fe-becc-c2b6da2ccbcf 
Unmounted: ID-1: /dev/sda1 size: 1007 KB fs: N/A label: N/A uuid: N/A 
           ID-2: /dev/sda2 size: 512.0 MB fs: FAT (32 bit) label: N/A uuid: 713F-2C85 
           ID-3: /dev/sda4 size: 188.38 GB fs: N/A label: N/A uuid: 347fcad5-6e39-4c73-ab69-710b4077051f 
           ID-4: /dev/sda6 size: 10.00 GB fs: XFS label: N/A uuid: 7101623f-3396-4808-a2bc-f57011b1861d 
USB:       Hub: 1:1 usb: 2.00 type: N/A chip ID: 1d6b:0002 
           Hub: 1:2 usb: 2.00 type: N/A chip ID: 8087:8008 
           Hub: 2:1 usb: 2.00 type: N/A chip ID: 1d6b:0002 
           Hub: 2:2 usb: 2.00 type: N/A chip ID: 8087:8000 
           Hub: 3:1 usb: 2.00 type: N/A chip ID: 1d6b:0002 
           Device-1: N/A bus ID: 3:2 usb: 2.00 type: N/A chip ID: 8087:07da 
           Hub: 4:1 usb: 3.00 type: N/A chip ID: 1d6b:0003 
Sensors:   Message: No sensors data was found. Is sensors configured? 
Repos:     Active Pacman repo servers in: /etc/pacman.d/mirrorlist 
           1: http://mirror.bytemark.co.uk/archlinux/$repo/os/$arch
           2: http://mirrors.manchester.m247.com/arch-linux/$repo/os/$arch
           3: http://www.mirrorservice.org/sites/ftp.archlinux.org/$repo/os/$arch
           4: http://arch.serverspace.co.uk/arch/$repo/os/$arch
           5: http://archlinux.mirrors.uk2.net/$repo/os/$arch
Processes: CPU  % used - Command - pid - Memory: MB / % used - top: 5 
           1: cpu: 9.6% command: firefox pid: 2835 mem: 151.4MB (1.9%) 
           2: cpu: 7.5% command: firefox pid: 2678 mem: 307.0MB (3.8%) 
           3: cpu: 5.2% command: firefox pid: 3097 mem: 100.6MB (1.2%) 
           4: cpu: 4.5% command: pinxi started by: perl pid: 3129 mem: 17.9MB (0.2%) 
           5: cpu: 1.4% command: x pid: 2631 mem: 73.8MB (0.9%) 
           Memory MB/% used - Command - pid - CPU: % used - top: 5 
           1: mem: 307.0 MB (7.5%) command: firefox pid: 2678 cpu: 3.8% 
           2: mem: 164.3 MB (0.6%) command: firefox pid: 2797 cpu: 2.0% 
           3: mem: 159.1 MB (0.7%) command: firefox pid: 2723 cpu: 2.0% 
           4: mem: 151.4 MB (9.6%) command: firefox pid: 2835 cpu: 1.9% 
           5: mem: 100.6 MB (5.2%) command: firefox pid: 3097 cpu: 1.2% 
Info:      Processes: 130 Uptime: 10 min Memory: 7.72 GB used: 656.4 MB (8.3%) Init: SysVinit v: version 
           runlevel: default Compilers: gcc: 6.4.0 clang: ersion Shell: ksh running in: urxvtd 
           pinxi: 2.9.00-444-p 
alpine: ~ $
This box uses loksh as the login shell:

Code: Select all

alpine: ~ $ echo $KSH_VERSION
@(#)PD KSH v5.2.14 99/07/13.2
alpine: ~ $
I'm using my own custom fork of dwm for the desktop, that may be why it's not picked up, I'm also using `xinit` rather than `startx` :D

Those pacman repositories are from me messing around, they aren't "normal" for an Alpine Linux system.

Not sure why Init is listed as that, it should be either busybox or OpenRC.

I will post the OpenBSD output tomorrow.

EDIT: my battery is ****ed... :cry:
deadbang

h2
Posts: 131
Joined: 2006-10-29 20:00
Location: USA

Re: Beta testers for new Perl inxi requested

#37 Post by h2 »

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.
smxi/sgfxi site (manuals, how-to's, faqs) :: script forums :: Check out inxi sys info script!

h2
Posts: 131
Joined: 2006-10-29 20:00
Location: USA

Re: Beta testers for new Perl inxi requested

#38 Post by h2 »

2.9.00-0449-p resolves the following issues:

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.
smxi/sgfxi site (manuals, how-to's, faqs) :: script forums :: Check out inxi sys info script!

h2
Posts: 131
Joined: 2006-10-29 20:00
Location: USA

Re: Beta testers for new Perl inxi requested

#39 Post by h2 »

Head_on_a_Stick, the openrc failure is most interesting to me. pinxi doesn't know about busybox init at all, nor do I.

The init detections are a bit sketchy, for example, I can see from the SysvInit v: that strings was actually able to get some data like so:

Code: Select all

strings /sbin/init | grep -Ei 'version\s+[0-9]'
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
smxi/sgfxi site (manuals, how-to's, faqs) :: script forums :: Check out inxi sys info script!

User avatar
Head_on_a_Stick
Posts: 14114
Joined: 2014-06-01 17:46
Location: London, England
Has thanked: 81 times
Been thanked: 132 times

Re: Beta testers for new Perl inxi requested

#40 Post by Head_on_a_Stick »

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? :D

Anyway, here's the output from a freshly-updated OpenBSD-current system:

Code: Select all

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):

Code: Select all

Puffy:~$ sysctl | grep sensors
hw.sensors.cpu0.temp0=40.00 degC
hw.sensors.acpitz0.temp0=43.00 degC (zone temperature)
hw.sensors.acpibtn0.indicator0=On (lid open)
hw.sensors.acpibat0.volt0=11.10 VDC (voltage)
hw.sensors.acpibat0.volt1=12.74 VDC (current voltage)
hw.sensors.acpibat0.current0=0.00 A (rate)
hw.sensors.acpibat0.amphour0=1.01 Ah (last full capacity)
hw.sensors.acpibat0.amphour1=0.05 Ah (warning capacity)
hw.sensors.acpibat0.amphour2=0.02 Ah (low capacity)
hw.sensors.acpibat0.amphour3=1.01 Ah (remaining capacity), OK
hw.sensors.acpibat0.amphour4=6.22 Ah (design capacity)
hw.sensors.acpibat0.raw0=0 (battery full), OK
hw.sensors.acpiac0.indicator0=On (power supply)
hw.sensors.acpithinkpad0.temp0=43.00 degC
hw.sensors.acpithinkpad0.temp1=43.00 degC
hw.sensors.acpithinkpad0.temp2=43.00 degC
hw.sensors.acpithinkpad0.temp3=43.00 degC
hw.sensors.acpithinkpad0.temp4=43.00 degC
hw.sensors.acpithinkpad0.temp5=43.00 degC
hw.sensors.acpithinkpad0.temp6=43.00 degC
hw.sensors.acpithinkpad0.temp7=43.00 degC
hw.sensors.acpithinkpad0.fan0=1988 RPM
hw.sensors.acpidock0.indicator0=Off (not docked), UNKNOWN
hw.sensors.itherm0.temp1=39.05 degC (Core 1)
hw.sensors.itherm0.temp4=42.00 degC (CPU/GPU Max temp)
hw.sensors.itherm0.temp9=42.00 degC (GPU/Memory controller abs.)
hw.sensors.itherm0.temp10=59.00 degC (PCH abs.)
hw.sensors.itherm0.power0=5.00 W (CPU power consumption)
hw.sensors.aps0.temp0=32.00 degC
hw.sensors.aps0.temp1=32.00 degC
hw.sensors.aps0.indicator0=On (Keyboard Active)
hw.sensors.aps0.indicator1=Off (Mouse Active)
hw.sensors.aps0.indicator2=On (Lid Open)
hw.sensors.aps0.raw0=511 (X_ACCEL)
hw.sensors.aps0.raw1=500 (Y_ACCEL)
hw.sensors.aps0.raw2=511 (X_VAR)
hw.sensors.aps0.raw3=500 (Y_VAR)
Puffy:~$
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.
deadbang

h2
Posts: 131
Joined: 2006-10-29 20:00
Location: USA

Re: Beta testers for new Perl inxi requested

#41 Post by h2 »

Hmm, that's two clang versions where the version number has moved. What's clang --version?

I had openbsd repos working, but the problem with trying to actually track the bsds is that not only are they different between each other, they also change within each OS, from release to release, which makes the effort to actually support them close to impossible. For example, as far as I know, the pci data was working previously on the openbsds I tested on, and now it's not. Do they use pciconf?

pinxi has that sensors data, also hardware, and battery, but it isn't being used yet, since that's a new feature I decided to hold off on that until pinxi becomes inxi and I'll do it whenever.

Stuff like this I'd need to see a full debugger data dump with --debug 21 or 22 (21 leaves the gz file on the system after uploading, 22 removes it).

There's too many variables to try to debug without having access to the full system debugger stuff in the case of openbsd.

It's sad to see openbsd doesn't support ps -f, that's another feature, so Ill have to remove that option for openbsds. freebsd does, I believe, at least I've seen no errors on freebsds, been testing on them since the beginning.

I'm curious about what strings output on /sbin/init is, that may give the init name as well as the version number, it's obvious there was a match, only not the right item was selected in the case of the alpine.

For me, bsd support has to take a back seat because they refuse to present anything even remotely consistent between their own releases and other bsds, so I tend to only work on bsd stuff now and then when I'm in the mood, the payoff in time vs users helped just isn't very good, but I do like to have it be as complete as possible, that's certainly coming in the future, but it would be nice if they learned how to play with others a little better, it would help them too, but I can't change their internal cultures.
smxi/sgfxi site (manuals, how-to's, faqs) :: script forums :: Check out inxi sys info script!

h2
Posts: 131
Joined: 2006-10-29 20:00
Location: USA

Re: Beta testers for new Perl inxi requested

#42 Post by h2 »

Corrected in 2.9.00-453:

1. machine device report as Oracle, not virtual box. This is a systemd decision, pinxi translates that back to the expected virtualbox. No comment on the decision making process that decided the solution was to remove the actual vm from output...

2. bsds now no longer try to get shell parent data, since after looking, I realized none of them support -f for ppid, and, as usual, freebsd has the -f option, but it does something different (they do that with the -P option in df too, sigh). So that will correct the issue with openbsd showing errors there. This was never exposed because as noted, freebsd has the option, but it does something different, so the results were always null for this purpose so I didn't see the error. As a result of the new failures in openbsd data collection, I've decided to implement some new decisions:

a: I will not take any issue reports on any bsd system without a full --debug 21 data set for that system, otherwise I'm wasting my life
b: all bsd work is now stopping pre 2.9.01 inxi perl release because it's a waste of time. I may add in one further error case, where I have collected battery/sensors/machine data from sysctl, but the processor is not in place. In that condition, pinxi will show the under development message.
c: in general, I'm not going to try to develop bsd features unless I'm given direct ssh access to the machines. That's how I developed the initial bsd support, but I have to say, I am truly, truly, dismayed, that several bsds have changed syntax, ordering, and various other pointless changes to their data output formats, and so now some features no longer work. Since dev time on bsds yields about 1000 worse man hours spent per user outcomes for pinxi/inxi than gnu/linux, I'm going to basically stop bsd development for pre 3.0.0 release. I had hoped to really get a lot working, but from your openbsd sample, I can see this is a futile effort, one best put to a later date when I truly have nothing better to do with my time or life. I really wanted 3.0.0 to release almost feature complete, albeit with crude simple data, for bsds, but I now see this is not realistic.

Thanks for showing me that sample, that confirmed to me that I can't get that done and also do realworld work and life stuff at this point.
smxi/sgfxi site (manuals, how-to's, faqs) :: script forums :: Check out inxi sys info script!

User avatar
Head_on_a_Stick
Posts: 14114
Joined: 2014-06-01 17:46
Location: London, England
Has thanked: 81 times
Been thanked: 132 times

Re: Beta testers for new Perl inxi requested

#43 Post by Head_on_a_Stick »

h2 wrote:what is the content: cat /proc/1/comm

Code: Select all

alpine:~$ cat /proc/1/comm
init
alpine:~$
^ That's the same as the output from sysvinit, I think.

OpenRC can be used with sysvinit or busybox or even with it's own openrc-init so that one will be tricky too :D

In respect of OpenBSD, casting aside old programs and adopting fresh stuff is a hallmark of that operating system and is considered to be a feature rather than a bug.
deadbang

h2
Posts: 131
Joined: 2006-10-29 20:00
Location: USA

Re: Beta testers for new Perl inxi requested

#44 Post by h2 »

Head_on_a_Stick, yes, I'm familiar with openbsd stuff, my best tech friend uses and prefers openbsd, for the right reasons, security. There's no need to even discuss their invaluable contributions to free libressl and the ever crucial openssh. However, I"m not talking about new programs here, I'm talking about pointless changes to strings and values which are given by system reporting tools themselves, which achieve no benefit, and simply reflect the fact that there is a very small realworld user base, most of whom do manual system checks, so the strings are just strings to be read by humans in many cases, not machine targetted values. This is something that became more obvious to me the more bsd dev work I did, particularly in this iteration with pinxi.

What's odd is that dragonfly and openbsd both have a very nice solution, in fact, it reminds me of inxi output, for the battery, sensors, and machine data, in systcl -a. Something so clean and simple one has to wonder why it's not in all the bsds.

But the time to support these variations between bsds and between releases of the same bsd can't be justified by me at this point, unless I get access to the machines, I learned this the last time I did serious inxi dev time on bsds, luckily that time I got a whole bunch of ssh access to different machines around the world, so i was able to get a fair amount done. Basically re my dev time, it's about like this: direct access, time value 1. Indirect access via full --debug 21 dataset: time value 2-10, or more. Depends on the specific issue. Indirect access via requests for specific files and output: time value, about 100. So I tend to only take case 2 (since getting ssh access rarely happens), and in fact, on github, I won't accept most issues without the data sets, because that's literally a 10 to 100x more demand on my finite free dev time. But for beta testing I decided to make an exception because I'd rather see failure instances and get the stuff resolved. For bsds however, I can't readily emulate many features by injecting single file data into pinxi since so many things are different, so there's a real limit there.

Thanks for confirming the /proc/1/comm.

I believe there is a way to distinguish, the strings method I listed above is a good starting point, but I'd have to have output from the 3 variants to see that. I don't have any more newer sysvinit systems, sadly, but I guess I could install a vm of antix or something to get that data, not too hard. To me, there's always got to be a way, that's the strategy I've generally followed in inxi dev, and it's usually worked out ok, though sometimes you hit fallback cases, like this one, where 1 more missing bit of data is needed. For example, to get the initial sysvinit version info, I simply asked the debian maintainer of sysvinit, and, after commiserating with him about systemd, he realized that strings could deliver that version info. But I would never have come up with that solution, nor would I have thought that init could be more than 1 program in that context. So that might be the answer, hard to say. I'll check some old vms and see if they boot, might show me more.

Your clang --version is still unresolved, I've now seen that twice, but all other clang v: samples I've seen are correct, so there's a variable there I'm not aware of yet.

Thanks for taking a look at the stuff.

As I indicated, the openrc output was left out purely because I forgot, that's corrected. I did not however know that openrc-init was a thing. I was aware that openrc can be used, and when I added that support years ago, was mostly only used, as an addition to another init system, which is why the rc: ... v: was a separate thing in the Info line outut.
smxi/sgfxi site (manuals, how-to's, faqs) :: script forums :: Check out inxi sys info script!

User avatar
Head_on_a_Stick
Posts: 14114
Joined: 2014-06-01 17:46
Location: London, England
Has thanked: 81 times
Been thanked: 132 times

Re: Beta testers for new Perl inxi requested

#45 Post by Head_on_a_Stick »

Oh yes, sorry, I forgot...

Code: Select all

alpine:~$ clang --version 
Alpine clang version 5.0.1 (tags/RELEASE_501/final) (based on LLVM 5.0.1)
Target: x86_64-alpine-linux-musl
Thread model: posix
InstalledDir: /usr/bin
alpine:~$
musl ftw! :mrgreen:
deadbang

h2
Posts: 131
Joined: 2006-10-29 20:00
Location: USA

Re: Beta testers for new Perl inxi requested

#46 Post by h2 »

Code: Select all

Alpine clang version 5.0.1 (tags/RELEASE_501/final) (based on LLVM 5.0.1)
Darn it!!

Now I see. Alpine, who do not write clang, decided they should put their distro name in the string, which is downright absurd. Tough to fix in pinxi, because it expects, quite reasonably that program version strings will be what they are.

Hmm, I know, I'll add in one more test, if the value received is version, increment the snip by 1.

That may work, since most cases I've seen now that are wrong are the result of people adding in a word before the actual application name, which almost never happens, but I've seen enough cases now where I think that fix is the best I'll try, and I think it will fix that class of errors.

Thanks for these examples of yet more fringe cases, these have been enormously helpful, much appreciated.

Will fix this in 0454, that's a pretty easy regex check. It will work in most cases where this type of string add was made, and version was teh found term, and I think I'll draw the line there, after that, it's really outside of the scope of pinxi in my opinion.

Actually, now I'm confused, pinxi is already snipping out the 4th item. hmm. I just realized, this was a fix I did to try to fix the wrong clang version line, so I have to revert that, and then add in the snip increment check.

Code: Select all

# freebsd
clang version 3.7.1 (tags/RELEASE_371/final)
Target: x86_64-unknown-freebsd10.3
Thread model: posix

#another freebsd
clang version 3.7.1 (tags/RELEASE_371/final)
Target: x86_64-unknown-freebsd10.3
Thread model: posix

# linux
clang version 5.0.1 (tags/RELEASE_501/final)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /sbin
You'll notice that the last one is the same exact release as the Alpine labeled one, and, worse, by putting their name first, before the actual program name. The only reason pinxi caught this at all was that it wasn't looking for the string ^clang, starter, but just clang. This means alpine just wanted to be 'special' as far as I can tell, by claiming credit for a program they didn't write. The obvious and correct place to have put any specifics in that string would either be appended to the actual version number, or in the (). this is why I really by the way like Debian, they don't mess around like this.

MY basic inclination in such cases is to file a bug report against alpine clang, and tell them to get rid of their name in that position, but pinxi will try to handle it since there's no telling when people will do things like this.

The init stuff I'd really like to solve however, I'm trying to get some data on that to see what's up. I think it's fixable.
smxi/sgfxi site (manuals, how-to's, faqs) :: script forums :: Check out inxi sys info script!

h2
Posts: 131
Joined: 2006-10-29 20:00
Location: USA

Re: Beta testers for new Perl inxi requested

#47 Post by h2 »

By the way, as an example of what pinxi output looks like when i have direct machine access, this is one of the remote FreeBSD servers I developed pinxi on. Much to my great fortune, the hoster here actually updated their FreeBSD version about 1/2 way through the development process, so I was able to develop early pinxi on Perl 5.010, 5.012, and I think 5.014 maybe. Plus the local system I have that runs Perl 5.008, a venerable Debian stable.

Code: Select all

pinxi -zv8 --alt 31
System:    Kernel: FreeBSD 10.3-RELEASE-p13 amd64 bits: 64 compiler: clang v: 3.4.1 Console: tty 1 dm: N/A 
           OS: FreeBSD 10.3-RELEASE-p13 
Machine:   Permissions: Unable to run dmidecode. Are you root? 
Battery:   Permissions: Unable to run dmidecode. Are you root? 
Memory:    RAM Report: permissions: Unable to run dmidecode. Are you root? 
PCI Slots: Permissions: Unable to run dmidecode. Are you root? 
CPU:       Topology: 8 Core model: Intel Core i7 930 type: MCP arch: N/A L2 cache: N/A 
           features: dmesg.boot permissions 
           Speed: 2800 MHz min/max: 1600/2801 MHz Core speeds: 1: 0 2: 0 3: 0 4: 0 5: 0 6: 0 7: 0 8: 0 
Graphics:  Card-1: Matrox Systems MGA G200eW WPCM450 driver: vgapci bus ID: 0:8:4.0 chip ID: 102b:0532 
           Display Server: No display server data found. Headless server? tty: 131x52 
           Message: Unable to show advanced data. Required tool glxinfo missing. 
Audio:     Message: No PCI card data found. 
Network:   Card-1: Intel 82574L Gigabit Network Connection driver: em port: N/A bus ID: 0:6:0 
           chip ID: 8086:10d3 
           IF: em0 state: active speed: 1000baseT duplex: full-duplex mac: <filter> 
           IP v4: <filter> scope: N/A broadcast: <filter> 
           IP v6: <filter> scope: link 
           IP v6: <filter> scope: N/A 
           IP v4: <filter> scope: N/A broadcast: <filter> 
           IP v4: <filter> scope: N/A broadcast: <filter> 
           IP v4: <filter> scope: N/A broadcast: <filter> 
           IP v4: <filter> scope: N/A broadcast: <filter> 
           IP v4: <filter> scope: N/A broadcast: <filter> 
           IP v4: <filter> scope: N/A broadcast: <filter> 
           IP v4: <filter> scope: N/A broadcast: <filter> 
           Message: Output throttled. IPs: 458; Limit: 10; Override: --limit [1-x;-1 all] 
           Card-2: Intel 82574L Gigabit Network Connection driver: em port: N/A bus ID: 0:7:0 
           chip ID: 8086:10d3 
           IF: em1 state: no mac: <filter> 
           WAN IP: <filter> 
Drives:    HDD Total Size: dmesg.boot permissions used: 603.60 GB 
           Drive Report: dmesg.boot permissions 
           Optical Report: dmesg.boot permissions 
RAID:      Device-1: tank type: zfs status: ONLINE size: 1.81 TB free: 1.18 TB allocated: 651.00 GB 
           size: 1.81 TB free: 1.18 TB allocated: 651.00 GB components: online: ada2 ada1 ada3 
           Device-2: cache type: zfs status: no-status raid: no-raid size: 25.90 GB free: 8.14 GB components: 
           online: ada0s2 
Partition: ID-1: / size: 53.27 GB used: 26.79 GB (50.3%) fs: ufs dev: /dev/ada0s1a label: N/A uuid: N/A 
           ID-2: /usr/boxes size: 1.39 TB used: 271.74 GB (19.2%) fs: zfs raid: tank/boxes label: N/A uuid: N/A 
           ID-3: /usr/home size: 1.24 TB used: 124.56 GB (9.8%) fs: zfs raid: tank/home label: N/A uuid: N/A 
           ID-4: /usr/public_ftp size: 1.12 TB used: 2.49 GB (0.2%) fs: zfs raid: tank/public_ftp label: N/A 
           uuid: N/A 
           ID-5: /usr/www/users size: 1.26 TB used: 142.92 GB (11.1%) fs: zfs raid: tank/www-users label: N/A 
           uuid: N/A 
           ID-6: /usr/wwws/users size: 1.12 TB used: 35 KB (0.0%) fs: zfs raid: tank/wwws-users label: N/A 
           uuid: N/A 
           ID-7: /var/mail size: 1.15 TB used: 31.95 GB (2.7%) fs: zfs raid: tank/var-mail label: N/A uuid: N/A 
           ID-8: swap-1 size: 5.00 GB used: 3.16 GB (63.2%) fs: swap dev: /dev/ada0s1b label: N/A uuid: N/A 
Unmounted: Message: No unmounted partition data found for this BSD system. 
USB:       Missing: Required tool usbdevs not installed. Check --recommends 
Sensors:   Platform: No Freebsd support. Is a comparable sensors tool available? 
Repos:     BSD ports server: /etc/portsnap.conf 
           1: portsnap.FreeBSD.org
           FreeBSD update server: /etc/freebsd-update.conf 
           1: update.FreeBSD.org
           BSD enabled pkg servers in: /etc/pkg/FreeBSD.conf 
           1: pkg+http://pkg.FreeBSD.org/$ABI/quarterly
Processes: CPU  % used - Command - pid - Memory: MB / % used - top: 5 (only 4 processes) 
           1: cpu: 0.0% command: sshd: pid: 82509 mem: 5.94MB (0.0%) 
           2: cpu: 0.0% command: pinxi started by: perl pid: 28188 mem: 18.9MB (0.1%) 
           3: cpu: 0.0% command: ps pid: 28193 mem: 1.76MB (0.0%) 
           4: cpu: 0.0% command: -csh pid: 82514 mem: 2.91MB (0.0%) 
           Memory MB/% used - Command - pid - CPU: % used - top: 5 (only 4 processes) 
           1: mem: 18.9 MB (0.0%) command: pinxi started by: perl pid: 28188 cpu: 0.1% 
           2: mem: 5.94 MB (0.0%) command: sshd: pid: 82509 cpu: 0.0% 
           3: mem: 2.91 MB (0.0%) command: -csh pid: 82514 cpu: 0.0% 
           4: mem: 1.76 MB (0.0%) command: ps pid: 28193 cpu: 0.0% 
Info:      Processes: 4 Uptime: 20 days Memory: 23.98 GB used: 23.74 GB (99.0%) Init: init (BSD) v: N/A 
           Compilers: gcc: 6.4.0 clang: 3.7.1 Shell: csh 6.18.01 running in: tty 1 pinxi: 2.9.00-454-p
As you can see, except for a few root access requiring features, it's basically complete.
smxi/sgfxi site (manuals, how-to's, faqs) :: script forums :: Check out inxi sys info script!

h2
Posts: 131
Joined: 2006-10-29 20:00
Location: USA

Re: Beta testers for new Perl inxi requested

#48 Post by h2 »

Barring last minute tonite or tomorrow morning bug fixes, inxi will go to 2.9.01 tomorrow, which will end the pinxi development branch for now.

I may do one or two more pinxi patch releases if I find something at the last minute, but otherwise, I'm calling it good, I can't spend more time on the beta/dev phase, work beckons.

when it hits distros is up to maintainers, but that will instantly close all pre 2.9 support, since I don't support legacy versions of inxi.

thanks for the great issues, there's a few things I saw that are not fixed yet, but that's mainly because i did not get requested data and I can't fix stuff blindly, so I'm leaving those as things people can file issues on github inxi after tomorrow.

As they say, the perfect in software is the enemy of the good, and pinxi is WAY better than inxi is now, so I feel fine about jumping it up now even if has some glitches, those can be ironed out over the 2.9.xx release cycle.
smxi/sgfxi site (manuals, how-to's, faqs) :: script forums :: Check out inxi sys info script!

User avatar
debiman
Posts: 3063
Joined: 2013-03-12 07:18

Re: Beta testers for new Perl inxi requested

#49 Post by debiman »

h2 wrote:someone on IRC mocked my belief that arm would be consistent, so they'll get a chuckle from your example.
i also had to learn it the hard way.
i'm not in the habit of buying arm laptops.
that's the entire proc/cpuinfo I take it?, no edits?
yep, no edits.

i'll say it again, if you want to get more out of ARM machines you should look at armbian's motd script(s).
they support a long list of devices.

h2
Posts: 131
Joined: 2006-10-29 20:00
Location: USA

Re: Beta testers for new Perl inxi requested

#50 Post by h2 »

https://github.com/pfoo/armbian-lib/blo ... /armhwinfo that has some things in it, but not much more than pinxi shows for hardware, since I just added the /proc/cpuinfo, but I'll take a look at their other scripts and see if I can find more.

I'm fairly happy with most of pinxi now, and while I could basically do pinxi full time, nobody pays me to, so I have to stop at some point, which is actually now, after adding support for deb822 repo syntax in repos, by request of the ubuntu/debian packager (how can I say no to him?), the very last pinxi release I'll do, moving to inxi now.

Had to draw a dev line somewhere, I've been doing this stuff for months, literally.

thanks for the armbian script tips, I'll store those away and see if I can find any subtle little things. But to me, looking at, it's basically just assigning some key words to the device hardware based on the strings it finds, maybe that means more to arm users than me? probably so, so I'll probably add some of those things in the future.

Your arm laptop, being an actual thing that exists, did prompt me to try to get at least some hardware id for arm, and now it does, but only if /proc/cpuinfo has it.

Going to switch inxi to perl now.
smxi/sgfxi site (manuals, how-to's, faqs) :: script forums :: Check out inxi sys info script!

Post Reply