What steps will reproduce the problem? 1. run porteus 3 from usb 2. running inxi

What is the expected output? What do you see instead? that it would know that its porteus and not slackware, also the machine version and serial number arent correctly as dmidecode -t 1 has the correct information.

What version of the product are you using? On what operating system? inxi 2.1.10 on porteus 3.0

Please paste your inxi output below. Resuming in non X mode: xdpyinfo not found. For package install advice run: inxi --recommends System: Host: porteus.example.net Kernel: 3.13.6-porteus i686 (32 bit) Desktop: MATE 1.7.1
Distro: Slackware 14.1 Machine: System: Gateway product: Gateway M320 and 4500 Series v: 53.01.02 serial: N824A 310 55537 Mobo: Gateway model: Gateway M320 and 4500 Series v: KBC K53.28.18������������� serial: 0123456789012345 Bios: Phoenix v: 53.01.02 date: 10/07/2004 CPU: Single core Intel Pentium M (-UP-) cache: 2048 KB clocked at 1600 MHz Graphics: Card: Intel 82852/855GM Integrated Graphics Device Display Server: X.org 1.14.5 drivers: intel (unloaded: vesa) tty size: 126x44 Advanced Data: N/A for root Audio: Card Intel 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller driver: snd_intel8x0 Sound: Advanced Linux Sound Architecture v:: k3.13.6-porteus Network: Card-1: Realtek RTL-8139/8139C/8139C+ driver: 8139too IF: eth0 state: down mac: 00:03:25:18:db:1e Card-2: Intel PRO/Wireless 2200BG [Calexico2] Network Connection driver: ipw2200 IF: eth1 state: up mac: 00:0e:35:88:25:1b Drives: HDD Total Size: 95.9GB (47.3% used) 1: id: /dev/sda model: IC25N060ATMR04 size: 60.0GB 2: USB id: /dev/sdb model: ImationFlashDriv size: 3.9GB 3: USB id: /dev/sdc model: Cruzer_Blade size: 32.0GB Partition: ID: swap-1 size: 1.31GB used: 0.00GB (0%) fs: swap Sensors: System Temperatures: cpu: 54.0C mobo: N/A Fan Speeds (in rpm): cpu: N/A Info: Processes: 129 Uptime: 1:04 Memory: 317.3/1229.8MB Init: SysVinit runlevel: 4 Client: Shell (sudo) inxi: 2.1.10

show the output of these files, and note which exist:

/etc/porteus-version (or any other release/version file in /etc, do: ls /etc/porteus and then give me the file name, if it exists, or if it doesn't let me know.

Also show: ls /etc/slackware

and show me that result.

then: cat /etc/os-release cat /etc/lsb-release

The machine version and serial are coming directly from /sys, do this, after updating inxi to latest version with: inxi -U inxi -xx@14 that will show me if there is any error in /sys, my guess is there isn't, but you never know. Obviously if /sys has the wrong information there's nothing inxi can do about it.

/etc/porteus-version = Porteus-v3.0

/etc/slackware-version = Slackware 14.1

ls /etc/slackware only results in /etc/slackware-version

os-release

NAME=Slackware VERSION="14.1" ID=slackware VERSION_ID=14.1 PRETTY_NAME="Slackware 14.1" ANSI_COLOR="0;34" CPE_NAME="cpe:/o:slackware:slackware_linux:14.1" HOME_URL="http://slackware.com/" SUPPORT_URL="http://www.linuxquestions.org/questions/slackware-14/" BUG_REPORT_URL="http://www.linuxquestions.org/questions/slackware-14/"

/etc/lsb-release doesnt exist

running inxi -xx@14 and will add the output when its finished

the script wouldnt finish executing, so i just pulled that files it outputted and its in the attachment.

I would need to know what went wrong with the script execution, I have never seen this issue before, and it did not execute the part I need, the xiin tool. It didn't actually do much. However I note that sysctl did execute, which means this is a bsd system? which makes no sense.

There's clearly something very nonstandard going on here, so you will have to provide full system data for me to give you any help. I have never seen the inxi -xx@ 14 debugger fail on a system with python before. And even on systems without it, it just usually skips that part, but still creates all the output.

I tested inxi debugger on a freebsd system and it all worked fine, no issues.

I looked at your output, and the code stopped execution at nvidia-smi, which is an nvidia program, but standard linux or unix that receives a command that does not exist gives a command not found error. I suspect that you have a failing system to be honest, either ram/mobo/or hard disk, there's no way the inxi debugger would have stopped at that point.

The proteus stuff is added to inxi 2.1.13 but whatever highly non standard thing you are doing on that system needs to be totally and clearly explained before I spend anymore time on this issue.

I have never seen a linux system with bsd sysctl, yet there is that output.

I can give you some hints: if you go to the function: debug_data_collector()

then start executing the commands at about line 1580 one by one manually in a terminal, I will bet you the script does not hang. And if it hangs when you run them together via inxi -xx@14 (ie, a sequence of super fast disk writes), I will bet you the cause is some cpu/mobo/disk failure issue.

Why your system is using sysctl is a mystery that it would be interesting to hear an explanation for, the system itself does not ID as bsd, and certainly inxi itself would never think to look for sysctl in a gnu/linux system, so it doesn't.

well the problem was in 'strings --version' as i commented that out and the program finished executing and the file was uploaded 'inxiporteus.example.net-20140331-104511-all.tar.gz'.

What happened with strings, here's what I get:

$ strings --version GNU strings (GNU Binutils for Debian) 2.24 Copyright 2013 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or (at your option) any later version. This program has absolutely no warranty.

Before I change that, I'd like to know why one system hangs on a command that should either result in a 'command not found' error, or in the --version information.

What do you get?

Re the second part of the issue, there is no error in -M, it was quite unlikely that there could have been. inxi uses the data that is reported by /sys, so if /sys is wrong, or if dmidecode is wrong (one is wrong I assume) then you have to report the issue upstream, either to the kernel devs or to dmidecode, depending which is wrong. I can tell you this about /sys vendor data: once you have seen enough of these /sys traverses, you realize that the vendor basically fills out a form, and that is what /sys then uses, there is very little quality control, if any, for example, I have seen many times: To be filled out by OEM as the value of a field, which means the oem did not fill out the data.

I don't know the specifics of how this data is added to the kernel however. Or does it come from the motherboard itself? I don't remember. Anyway, the kernel gets it and shows it in /sys, my impression was that dmidecode uses the same data where it's present in both places, but it could be using different C calls, I really can't say.

What I can say is that inxi is telling you the truth, /sys has this data about your hardware, so as far as this issue goes, that's a closed, non valid issue, ie, it's not a bug or an error in anything inxi can do anything about.

/sys/devices/virtual/dmi/id/product_name:['Gateway M320 and 4500 Series'] /sys/devices/virtual/dmi/id/product_uuid:['00C2EF2D-2464-0010-9D09-0A0B0330E9AA'] /sys/devices/virtual/dmi/id/board_name:['Gateway M320 and 4500 Series'] /sys/devices/virtual/dmi/id/board_asset_tag:[''] /sys/devices/virtual/dmi/id/chassis_serial:['None'] /sys/devices/virtual/dmi/id/product_version:['53.01.02'] /sys/devices/virtual/dmi/id/chassis_vendor:['Gateway'] /sys/devices/virtual/dmi/id/modalias:['dmi:bvnPhoenix:bvr53.01.02:bd10/07/2004:svnGateway:pnGatewayM320and4500Series:pvr53.01.02:rvnGateway:rnGatewayM320and4500Series:rvrKBCK53.28.18:cvnGateway:ct10:cvrRev1.0:'] /sys/devices/virtual/dmi/id/chassis_version:['Rev 1.0'] /sys/devices/virtual/dmi/id/bios_date:['10/07/2004'] /sys/devices/virtual/dmi/id/bios_version:['53.01.02'] /sys/devices/virtual/dmi/id/product_serial:['N824A 310 55537'] /sys/devices/virtual/dmi/id/sys_vendor:['Gateway'] /sys/devices/virtual/dmi/id/bios_vendor:['Phoenix'] /sys/devices/virtual/dmi/id/board_serial:['0123456789012345 '] /sys/devices/virtual/dmi/id/uevent:['MODALIAS=dmi:bvnPhoenix:bvr53.01.02:bd10/07/2004:svnGateway:pnGatewayM320and4500Series:pvr53.01.02:rvnGateway:rnGatewayM320and4500Series:rvrKBCK53.28.18:cvnGateway:ct10:cvrRev1.0:'] /sys/devices/virtual/dmi/id/chassis_asset_tag:[' '] /sys/devices/virtual/dmi/id/chassis_type:['10'] /sys/devices/virtual/dmi/id/board_vendor:['Gateway'] /sys/devices/virtual/dmi/id/board_version:['KBC K53.28.18\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff'] /sys/devices/virtual/dmi/id/power/control:['auto'] /sys/devices/virtual/dmi/id/power/runtime_active_time:['0'] /sys/devices/virtual/dmi/id/power/runtime_status:['unsupported'] /sys/devices/virtual/dmi/id/power/runtime_suspended_time:['0']

I would like to know why 'strings' appears to be hanging your inxi debugger, in my opinion, you are assuming causation where none exists, your first one you posted hung on nvidia-smi output, which you can see from the gz file content.

I believe it's quite safe to say you have some type of hardware or filesystem corruption issue, seeing a hang a two different places suggests that strongly to me, so I am going to call this system failure rather than an inxi issue for now, unless you can demonstrate repeatedably that a single command actually does hang when run separately in a terminal, then I'd need more data, ie, program version, distro release version, if this is a known issue that has since been resolved on that particular app, but note that as of now, you have had inxi fail at two separate lines of the debugger, which points strongly to file system problems, not inxi issues.

marking this started for now, but actually one issue is fixed, and one issue is invalid, with lingering questions about the debugger vs the file system being queried/written tol

well i checked and strings is found in /usr/bin/ and when i execute it in whatever form, it doesnt do anything, which means i should report it to the distribution. in the incomplete gz file i sent you, the output of strings was empty, so it didnt hang on the nvidia-smi issue. the filesystem isnt corrupted as i'm running it from usb.

I see, right, 0 bytes on strings --version &> strings.txt

that means the behavior is even more strange. As long as the behavior is consistent, I'm just trying to see if I should remove that strings version check since the debugger output should work.

I'm unfammiliar with a case where a command can do that type of hang though. Is it possible your installation media was corrupted, we used to see that frequently in distros I worked with/on, weird failures that nobody else could reproduce, almost always were caused by faulty iso installs, though that should only be an issue with cdrom burn errors, not direct iso to usb installs, iso downloaded via web.

Let me know if any oother users of porteus or slackware that porteus is derived from can reproduce this strings hang, just have them do the command:

strings --version &> strings.txt and report if hangs, if you can get one other report that it hangs, I will change that.

Just out curiousity, what does this command yield:

if strings --version;then echo works; else echo failed;fi

that may show more.

IE: if strings --version;then echo works; else echo failed;fi GNU strings (GNU Binutils for Debian) 2.24 Copyright 2013 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or (at your option) any later version. This program has absolutely no warranty. works

well i tried the if command and it halts. well everytime i've tested and sent you info, i re-wrote the iso to the usb, which means 5 times so far. I then went and got the 2.1 version of porteus and it also halts with strings, so i submitted the bug with them < http://forum.porteus.org/viewtopic.php?f=117&t=3291 >. I thought maybe it was the laptop, so i tested it on 2 other laptops and the same result. I'm downloading slackware's iso now and will testing it and will test inxi on two other slackware derivatives slitaz and salix.

thank you for taking the time, I looked at what you said, then said to myself: what happens if strings does not support --version and also ignores unsupported options?

So I typed in 'strings' alone and hit enter, and there is the hang.

I will remove strings --version test, it's not important, all I need to know is if strings is present or not.

Thank you for following up. It's possible that debian adds --version to the program, and that slackware does not. It sounds like it's not a bug to me, just an unexpected behavior of some versions of strings.

inxi 2.1.14 will remove the strings test, thank you for detecting the exact cause.

well i checked slitaz and i wasnt able to get inxi running as bash wasnt available, but looked in /etc/ for details of its version and its stored in /etc/slitaz-release. There were no other release or version files in the folder.

slitaz-release = cooking

Thanks, for further issues with other variants of slackware, just start a new issue, 2.1.14 inxi closes the actual issues here. strings --version test is removed, since obviously it's very undeesirable for someone taking the time to post issue reports to then also have to debug the inxi debugger as well, lol. Thank you for taking the time required to provide the requested data and figuring out the actual issue, not everyone is so patient.

Closing this issue (actually these 3, the valid porteus, the invalid -M, and the very valid and unexpected strings / debugger issue), but feel free to add more distro support requests, the process is the same always, so you can save time by posting the contents of all the distro files possible, inxi cascades its tests and has to to know which file contains the true distro ids. Distros that do not id via a file probably should not be added to keep the overall complexity of the distro version checks down.

i'm glad to have been some assistance to your project. i had also been testing phoronix's system info results and have sent it some bugs. have you considered teaming up with them to reduce duplication.

well i tested salix and they dont have any release or version files in /etc/ other than the slackware-version file. so if in order to detect it, you would only have to check for /etc/salix-update-notifier.conf and then pull the version number from slackware-version.

oh, I misread, you said that /etc/slitaz-release exists? I added that to 2.1.14 as well..

I would prefer to not add custom tests for a single derived distro, the distro version logic is already close to insane, due to gnu/linux never having a consistent way to identify distros, the new os-release file fails totally to fix this issue because the designer apparently has no idea of derived distros and a system base distro, like: slackware (systembase) vs salix (derived), the specs for os release failed to include the critical SYSTEM_BASE and SYSTEM_BASE_VERSION data variables, that would have allowed distros to add derived data, so linux again has no consistent way to identify distros.

I suggest filing a bug report with salix noting it has no salix-release/salix-version file, something to utterly trivial to add it's not even worth spending the time typing a refusal response to the bug report, faster to just add the file to the distro iso for next release.

It's very unlikely I could use anything from phoronix, inxi is bash+gawk, and bash 3.2 max to make it work on everything else. And it has very specific output requirements, ie, IRC/Shell. Depends.