inxi / pinxi 2.9.00 beta testers!

[h2-1]

CMB1 is the answer to the problem, I'll update pinxi and you can try again. It's doing regex searches for BAT* so CMB didn't show.

[h2-1]

While I'd need to see the debugger data from to confirm that your paths are just using CMB instead of BAT as default, 365-p should in theory have it fixed, since I altered the wildcards to include the match of either /BAT or /CMB in the path.

So it should magically 'just work' after update, if it does not, I'll need to see the debugger data.

If the upload fails again, you'll also know why it failed this time since that bug is also fixed, and it will now show you the proper message, or should.

[stsoh]

do u need us to send debug data?? even we dun have any problem with it.

[h2-1]

0367-p should hopefully have corrected the empty usb device name. the mxi box had that failure, and it should now work. I was missing a key test there, now I've made it cascade down a series of tests, so in no case should nothing show there unless the usb data itself has literally nothing in each of the 4 fields I test.

All debug data always helps me, my data collection is one of the key tools I use to figure out variants in data possibilities across systems, so every one I get makes the future that much easier to debug and develop new features for. But you don't need to send it, it just helps out. If there is a bug that I can't figure out in your system, generally I do need to see it, because it's got most of the data I need to figure out most issues, and when it doesn't, I add more to the debugger, which I've been doing steadily during this process as I discovered missing data types etc.

For example, I figured out the odd -A usb failure to show device name by looking at the debug data log from when pinxi runs, that has most of the data it uses in it, and then I check the source data as well, like lsusb -v in that case, and lspci -knn to double check. I never really know for sure what data will be needed. But no, you certainly do not need to send it, as noted, it's just helpful to me, that's all.

[stsoh]

updated p-367, looks great.

Code: Select all

$ sudo pinxi -U
[sudo] password for user: 
Starting pinxi self updater.
Using tiny as downloader.
Currently running pinxi version number: 2.9.00
Current version patch number: 365-p
Current version release date: 2018-03-07
Updating pinxi in /usr/local/bin using pinxi branch as download source...
Successfully updated to pinxi branch version: 2.9.00;
New pinxi branch version patch number: 367-p;
New pinxi branch version release date: 2018-03-07;
To run the new version, just start pinxi; again.
----------------------------------------

Starting download of man page file now.
Skipping man download because branch version is being used.


$ pinxi -v 7
System:    Host: mx1 Kernel: 4.15.0-7.1-liquorix-amd64 x86_64 bits: 64 compiler: gcc v: 7.3.0 
           Desktop: Xfce 4.12.3 (Gtk 2.24.31) info: xfce4-panel dm: lightdm 1.18.3 
           Distro: MX-17_x64 Horizon December 15, 2017 
Machine:   Type: Desktop Mobo: MSI model: G41M-P33 Combo(MS-7592) v: 7.0 serial: N/A 
           BIOS: American Megatrends v: V32.13 date: 11/06/2014 
Memory:    RAM Report: permissions: Unable to run dmidecode. Are you root? 
CPU:       Topology: Dual Core model: Pentium E5400 type: MCP arch: Penryn rev: 10 
           L2 cache: 2048 KB 
           flags: lm nx pae sse sse2 sse3 ssse3 vmx bogomips: 12582 
           Speed: 3146 MHz min/max: N/A Core speeds: 1: 3146 2: 3146 
Graphics:  Card-1: Intel 4 Series Integrated Graphics Controller driver: i915 v: kernel 
           bus ID: 00:02.0 chip ID: 8086:2e32 
           Display Server: x11 (X.Org 1.19.2) driver: intel resolution: 1920x1080~60Hz 
           OpenGL: renderer: Mesa DRI Intel G41 version: 2.1 Mesa 17.3.6 direct render: Yes 
Audio:     Card-1: Intel NM10/ICH7 Family High Definition Audio Controller driver: snd_hda_intel 
           v: kernel bus ID: 00:1b.0 chip ID: 8086:27d8 
           Card-2: GYROCOM C&C LTD driver: USB Audio bus ID: 2:2 chip ID: 1852:db96 
           Sound Server: ALSA v: k4.15.0-7.1-liquorix-amd64 
Network:   Card-1: Realtek RTL8101/2/6E PCI Express Fast/Gigabit Ethernet controller 
           driver: r8169 v: 2.3LK-NAPI port: d800 bus ID: 02:00 chip ID: 10ec:8136 
           IF: eth0 state: down mac: 44:8a:5b:91:69:6c 
           Card-2: Realtek RTL8169 PCI Gigabit Ethernet Controller driver: r8169 v: 2.3LK-NAPI 
           port: e800 bus ID: 03:00 chip ID: 10ec:8169 
           IF: eth1 state: up speed: 1000 Mbps duplex: full mac: 64:70:02:00:71:f9 
           IP v4: 192.168.1.1/24 type: dynamic eth1 scope: global broadcast: 192.168.1.255 
           IP v6: fe80::7e62:ff36:7772:5f03/64 scope: link 
           WAN IP: 121.6.243.146 
Drives:    HDD Total Size: 3.75 TB used: 3.25 TB (86.6%) 
           ID-1: /dev/sda model: TOSHIBA_Q300 size: 111.79 GB serial: 75KB52R4KNRX rev: 11.2 
           temp: 32 C 
           ID-2: /dev/sdb model: TOSHIBA_DT01ACA2 size: 1.82 TB serial: Y7F61VBAS rev: ABB0 
           temp: 35 C 
           ID-3: /dev/sdc model: TOSHIBA_DT01ACA2 size: 1.82 TB serial: 37T82W1AS rev: ABB0 
           temp: 36 C 
           Optical-1: /dev/sr0 vendor: HL-DT-ST model: DVDRAM GH22NS50 rev: TN03 
           dev-links: cdrom,cdrw,dvd,dvdrw 
           Features: speed: 48 multisession: yes audio: yes dvd: yes 
           rw: cd-r,cd-rw,dvd-r,dvd-ram state: running 
Partition: ID-1: / size: 15.72 GB used: 8.75 GB (55.7%) fs: ext4 dev: /dev/sda1 label: rootMX17 
           uuid: 6f4d1ee0-4041-491b-9c4a-b4d79cc29405 
           ID-2: /media/02858C1832958C3F size: 95.69 GB used: 67.8 MB (0.1%) fs: fuseblk 
           dev: /dev/sda2 label: N/A uuid: 02858C1832958C3F 
           ID-3: /media/70E8A8B2E8A8784C size: 1.82 TB used: 1.44 TB (79.0%) fs: fuseblk 
           dev: /dev/sdb1 label: N/A uuid: 5FA3E608575C6981 
           ID-4: /media/5FA3E608575C6981 size: 1.82 TB used: 1.80 TB (98.9%) fs: fuseblk 
           dev: /dev/sdc1 label: N/A uuid: 70E8A8B2E8A8784C 
           ID-5: swap-1 size: 981.3 MB used: 0 KB (0.0%) fs: swap dev: /dev/zram0 label: N/A 
           uuid: N/A 
           ID-6: swap-2 size: 981.3 MB used: 0 KB (0.0%) fs: swap dev: /dev/zram1 label: N/A 
           uuid: N/A 
RAID:      Message: No RAID data was found. 
Unmounted: Message: No unmounted partitions found. 
USB:       Hub: 1:1 usb: 1.10 type: Full speed (or root) hub chip ID: 1d6b:0001 
           Hub: 2:1 usb: 1.10 type: Full speed (or root) hub chip ID: 1d6b:0001 
           Device-1: GYROCOM C&C LTD bus ID: 2:2 usb: 1.10 type: Human Interface Device 
           chip ID: 1852:db96 
           Hub: 3:1 usb: 1.10 type: Full speed (or root) hub chip ID: 1d6b:0001 
           Hub: 4:1 usb: 1.10 type: Full speed (or root) hub chip ID: 1d6b:0001 
           Hub: 5:1 usb: 2.00 type: Full speed (or root) hub chip ID: 1d6b:0002 
           Hub: 6:1 usb: 2.00 type: Full speed (or root) hub chip ID: 1d6b:0002 
           Hub: 7:1 usb: 3.00 type: Full speed (or root) hub chip ID: 1d6b:0003 
Sensors:   System Temperatures: cpu: 41.0 C mobo: N/A 
           Fan Speeds (in RPM): N/A 
Info:      Processes: 180 Uptime: 2:07 Memory: 7.67 GB used: 1.55 GB (20.2%) Init: SysVinit 
           v: 2.88 runlevel: 5 default: 5 Compilers: gcc: 6.3.0 alt: 6/7 Shell: bash 4.4.12 
           running in: xfce4-terminal pinxi: 2.9.00-367-p 

[anticapitalista]

anticapitalista, it looks like you have a firewall block against your IP for some reason, that's not pinxi related.

-v7 does not run the IP -i option, so the issue doesn't trigger, that's getting the WAN IP address, which is done either via dig, or using perl, curl or wget. I just wanted to confirm that there was no actual issue with perl itself, clearly the issue is with the IP and akamai. note that pinxi on failure goes to the next one in the list, which is why you end up seeing the IP address. Dig is the first choice, since it bypasses the need to run an HTTP request to get the iP in the first place.

Do inxi -i and pinxi -i do exactly the same thing?
If so, then there is a bug since inxi -i does not show the 'Failed to connect to server/file!' message, but pinxi -i does.

[h2-1]

It's not a bug in pinxi, it's because I did a lot of optimization tests, and realized that the server inxi uses, smxi.org, is really slow to return the IP, almost 0.5 seconds, and the akamai server is literally 10x faster. dig is also about 10x faster.

So what you're seeing there is a request made to the fast one, and for some reason, their firewall is rejecting the request. that's not related to pinxi, though it is a fact that it's happening and I wanted to see if any issues would arise.

the real question is why the block is happening. pinxi has 4 ways to get the ip, first, it checks if dig is installed, if it is, it always uses that. if not, it uses one of the 3 downloader tools, perl, curl, or wget. Those then get the IP from a set of 3 urls, the first is fastest, by far, the second is quite fast, and the third is mine, smxi.org, which is why the request succeeds in the end, it runs in a loop and keeps trying until it got the ip. inxi also used dig first, then the user downloader tool, but it only used one url as the source, mine, so it ran about 10x slower to get the IP, but it would basically always work since of course I'm not running any such firewalling rules.

inxi is much more simple and primitive due to the limitations of gawk->bash.

However, I was thinking of adding a flag that would tell the ip tool to skip one or more of the ips, like, 1, 2, or 3, and also a configuration option that would let you hard code that into the configs, but no, it's not a bug, you confirmed that by your curl failure and wget failure, the issue is a firewall blocking the request somewhere.

Basically what you are seeing there is just some output that I could remove, though I like to see when failures happen, but if I were to remove that output, you'd never know it had happened, the IP would show, it would just take a bit longer to get it.

[h2-1]

stsoh, great, finally, it took me a while to figure out the cause for the usb audio device name failure, obvious once I found the cause, easy to fix.

[anticapitalista]

h2 - ok, found what the problem was and it has nothing to do with pinxi.
I use /etc/hosts to block ads and whatismyip was included.
I remove it and all works as it should.

BTW - the inxi-gui used in antiX also works with pinxi options

[k_sz]

CMB1 is the answer to the problem, I'll update pinxi and you can try again. It's doing regex searches for BAT* so CMB didn't show.

All right ! so, after a little pinxi -U i'm running version 369-p.

Code: Select all

ksz : ~
$ pinxi -B
Battery:   CMB-1: charge: 62.6 Wh condition: 62.6/62.6 Wh (100%) 

and extensive version (sudo mode, for the RAM output and -y 90 to get a better readability on the forum) :

Code: Select all

$ sudo pinxi -z -v 7 -y 90
System:    Host: Krashteszt Kernel: 4.13.0-1-amd64 x86_64 bits: 64 compiler: gcc 
           v: 6.3.0 Desktop: Xfce 4.12.3 (Gtk 2.24.31) info: xfce4-panel 
           dm: lightdm 1.18.3 Distro: MX-17_x64 Horizon December 15, 2017 
Machine:   Type: Laptop System: FUJITSU SIEMENS product: LIFEBOOK S7220 v: N/A 
           serial: <filter> Chassis: type: 10 v: S7220 serial: <filter> 
           Mobo: FUJITSU model: FJNB1E7 v: 1PCP389403-01 serial: <filter> 
           BIOS: FUJITSU // Phoenix v: Version 1.15 date: 08/21/2009 
Battery:   CMB-1: charge: 62.6 Wh condition: 62.6/62.6 Wh (100%) volts: 12.3/10.8 
           model: Fujitsu CP345705-01 type: Li-ion serial: <filter> status: Full 
Memory:    Array-1: capacity: 8 GB slots: 2 EC: None max module size: 4 GB 
           Device-1: DDRIII 1 size: 2 GB info: double-bank speed: 533 MHz type: Reserved 
           detail: synchronous bus width: 64 bits total: 64 bits manufacturer: 80CE 
           part-nu: M471B5673EH1-CF8 serial: 84FD983B 
           Device-2: DDRIII 2 size: 2 GB info: double-bank speed: 533 MHz type: Reserved 
           detail: synchronous bus width: 64 bits total: 64 bits manufacturer: 830B 
           part-nu: NT2GC64B8HC0NS-CG serial: FA4E2C6A 
CPU:       Topology: Dual Core model: Intel Core2 Duo P8700 type: MCP arch: Penryn 
           rev: 10 L2 cache: 3072 KB 
           flags: lm nx pae sse sse2 sse3 sse4_1 ssse3 vmx bogomips: 10131 
           Speed: 800 MHz min/max: 800/2534 MHz Core speeds: 1: 800 2: 1136 
Graphics:  Card-1: Intel Mobile 4 Series Integrated Graphics Controller driver: i915 
           v: kernel bus ID: 00:02.0 chip ID: 8086:2a42 
           Display Server: X.Org 1.19.2 driver: modesetting unloaded: fbdev,vesa 
           resolution: 1280x800~60Hz 
           OpenGL: renderer: Mesa DRI Mobile Intel GM45 Express version: 2.1 Mesa 13.0.6 
           direct render: Yes 
Audio:     Card-1: Intel 82801I (ICH9 Family) HD Audio Controller driver: snd_hda_intel 
           v: kernel bus ID: 00:1b.0 chip ID: 8086:293e 
           Sound Server: ALSA v: k4.13.0-1-amd64 
Network:   Card-1: Marvell 88E8055 PCI-E Gigabit Ethernet Controller driver: sky2 
           v: 1.30 port: 2000 bus ID: 08:00 chip ID: 11ab:4363 
           IF: eth0 state: up speed: 1000 Mbps duplex: full mac: <filter> 
           IP v4: <filter> type: dynamic eth0 scope: global broadcast: <filter> 
           IP v6: <filter> scope: link 
           Card-2: Intel Ultimate N WiFi Link 5300 driver: iwlwifi v: kernel 
           bus ID: 20:00 chip ID: 8086:4235 
           IF: wlan0 state: down mac: <filter> 
           WAN IP: <filter> 
Drives:    HDD Total Size: 381.94 GB used: 228.59 GB (59.9%) 
           ID-1: /dev/sda model: Samsung_SSD_850 size: 232.89 GB serial: <filter> 
           rev: 2B6Q 
           ID-2: /dev/sdb model: Hitachi_HTS72321 size: 149.05 GB serial: <filter> 
           rev: C30F temp: 34 C 
           Message: No Optical or Floppy data was found. 
Partition: ID-1: / size: 19.10 GB used: 7.58 GB (39.7%) fs: ext4 dev: /dev/sda1 
           label: MXROOT uuid: e78f9236-3990-41c1-b222-b1d6d62b0d63 
           ID-2: /home size: 25.83 GB used: 14.19 GB (54.9%) fs: ext4 dev: /dev/sda7 
           label: MXHOME uuid: 90335696-c863-4360-9b9f-1118a12850d1 
           ID-3: /home/<filter>/Musique size: 50.46 GB used: 38.50 GB (76.3%) fs: ext4 
           dev: /dev/sdb1 label: ZIK uuid: cce13459-b27b-4709-bef3-e85b916a73b3 
           ID-4: /home/<filter>/DIV size: 95.62 GB used: 80.29 GB (84.0%) fs: ext4 
           dev: /dev/sdb2 label: DIV uuid: c48e1065-e9f4-4749-88ee-05096d48cf34 
           ID-5: /home/<filter>/DEBHOM size: 151.22 GB used: 88.04 GB (58.2%) fs: ext4 
           dev: /dev/sda5 label: DEBHOM uuid: 34ec8d41-d74f-4fdd-91bb-f377f6f08658 
           ID-6: swap-1 size: 4.00 GB used: 0 KB (0.0%) fs: swap dev: /dev/sda6 
           label: N/A uuid: 95d25838-31dd-496e-8d8b-cbd48946a644 
RAID:      Message: No RAID data was found. 
Unmounted: ID-1: /dev/sda2 size: 18.55 GB fs: ext4 label: rootantiX 
           uuid: 75fcc5fe-7618-435c-8ea7-c35ec75a7080 
           ID-2: /dev/sda8 size: 9.78 GB fs: ext4 label: homeantiX 
           uuid: d37a30cb-6b52-4d2d-a233-05b8c04c36f9 
USB:       Hub: 1:1 usb: 1.10 type: Full speed (or root) hub chip ID: 1d6b:0001 
           Device-1: Razer USA Ltd bus ID: 1:2 usb: 2.00 type: Mouse chip ID: 1532:0042 
           Hub: 2:1 usb: 1.10 type: Full speed (or root) hub chip ID: 1d6b:0001 
           Hub: 3:1 usb: 1.10 type: Full speed (or root) hub chip ID: 1d6b:0001 
           Hub: 4:1 usb: 1.10 type: Full speed (or root) hub chip ID: 1d6b:0001 
           Hub: 5:1 usb: 1.10 type: Full speed (or root) hub chip ID: 1d6b:0001 
           Hub: 6:1 usb: 2.00 type: Full speed (or root) hub chip ID: 1d6b:0002 
           Hub: 7:1 usb: 2.00 type: Full speed (or root) hub chip ID: 1d6b:0002 
           Hub: 8:1 usb: 1.10 type: Full speed (or root) hub chip ID: 1d6b:0001 
Sensors:   System Temperatures: cpu: 65.0 C mobo: 26.8 C 
           Fan Speeds (in RPM): N/A 
Info:      Processes: 198 Uptime: 1:17 Memory: 3.80 GB used: 1.61 GB (42.3%) 
           Init: SysVinit v: 2.88 runlevel: 5 default: 5 Compilers: gcc: 6.3.0 alt: 6 
           Shell: bash 4.4.12 running in: xfce4-terminal pinxi: 2.9.00-369-p 

Everything seems to be fine, battery, RAM,
As for the FTP [pinxi --debug 21/22] error :

Code: Select all

Error 51: There was an error with upload to ftp server: Could not accept passive data connection - timed out.

the cause of this problem could be on my side : my ISP has updated the router's firmware a few days ago (without any warning as usual) and i'm currently unable to access the said router's config page. Waiting for the support to call me back (they're slow) -_-"

So, i join a pinxi --debug 20 --alt 31 report to this message (the one i joined earlier this morning was the result of an aborted pinxi --debug 22 and this is probably the reason why it was both heavy and empty).
(attachements deleted)