porteus distro not detected about inxi HOT 17 CLOSED

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:s
vnGateway:pnGatewayM320and4500Series:pvr53.01.02:rvnGateway:rnGatewayM320and4500
Series: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:rnGatewayM320
and4500Series: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.