inxi / pinxi 2.9.00 beta testers!
Re: inxi / pinxi 2.9.00 beta testers!
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.
Re: inxi / pinxi 2.9.00 beta testers!
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.
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.
Re: inxi / pinxi 2.9.00 beta testers!
do u need us to send debug data?? even we dun have any problem with it.
MX-17.1_x64 Horizon, G41M-P33 Combo (MS-7592), Pentium E5400 (2706 MHz), 8Gb RAM (984 MT/s),
Intel 4 Series Integrated Graphics, Realtek PCIe Fast RTL8101/2/6E, PCI Gigabit RTL8169 Ethernets.
Accepted Linux when i found MX-Linux in 2016.
Intel 4 Series Integrated Graphics, Realtek PCIe Fast RTL8101/2/6E, PCI Gigabit RTL8169 Ethernets.
Accepted Linux when i found MX-Linux in 2016.
Re: inxi / pinxi 2.9.00 beta testers!
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.
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.
Re: inxi / pinxi 2.9.00 beta testers!
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
MX-17.1_x64 Horizon, G41M-P33 Combo (MS-7592), Pentium E5400 (2706 MHz), 8Gb RAM (984 MT/s),
Intel 4 Series Integrated Graphics, Realtek PCIe Fast RTL8101/2/6E, PCI Gigabit RTL8169 Ethernets.
Accepted Linux when i found MX-Linux in 2016.
Intel 4 Series Integrated Graphics, Realtek PCIe Fast RTL8101/2/6E, PCI Gigabit RTL8169 Ethernets.
Accepted Linux when i found MX-Linux in 2016.
- anticapitalista
- Developer
- Posts: 4167
- Joined: Sat Jul 15, 2006 10:40 am
Re: inxi / pinxi 2.9.00 beta testers!
Do inxi -i and pinxi -i do exactly the same thing?h2-1 wrote: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.
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.
anticapitalista
Reg. linux user #395339.
Philosophers have interpreted the world in many ways; the point is to change it.
antiX with runit - lean and mean.
https://antixlinux.com
Reg. linux user #395339.
Philosophers have interpreted the world in many ways; the point is to change it.
antiX with runit - lean and mean.
https://antixlinux.com
Re: inxi / pinxi 2.9.00 beta testers!
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.
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.
Last edited by h2-1 on Thu Mar 08, 2018 5:58 am, edited 1 time in total.
Re: inxi / pinxi 2.9.00 beta testers!
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
- Developer
- Posts: 4167
- Joined: Sat Jul 15, 2006 10:40 am
Re: inxi / pinxi 2.9.00 beta testers!
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
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
anticapitalista
Reg. linux user #395339.
Philosophers have interpreted the world in many ways; the point is to change it.
antiX with runit - lean and mean.
https://antixlinux.com
Reg. linux user #395339.
Philosophers have interpreted the world in many ways; the point is to change it.
antiX with runit - lean and mean.
https://antixlinux.com
Re: inxi / pinxi 2.9.00 beta testers!
All right ! so, after a little pinxi -U i'm running version 369-p.h2-1 wrote: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.
Code: Select all
ksz : ~
$ pinxi -B
Battery: CMB-1: charge: 62.6 Wh condition: 62.6/62.6 Wh (100%)
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
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.
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)
Last edited by k_sz on Thu Mar 08, 2018 5:22 pm, edited 1 time in total.
> Desktop : AMD 64 bits (unknowned monocore model :P looking for an AM2+ 4cores Phenom) | RAM 4Go DDR2 | MX@daily updates, sudo apt dist-upgrade
> Laptop x2 : WIP obsolescence and "old" batteries prices have killed my project
> Laptop x2 : WIP obsolescence and "old" batteries prices have killed my project