Comments (17)
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.
Original comment by [email protected]
on 29 Mar 2014 at 5:58
- Changed state: Accepted
from inxi.
/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
Original comment by [email protected]
on 30 Mar 2014 at 5:09
from inxi.
the script wouldnt finish executing, so i just pulled that files it outputted
and its in the attachment.
Original comment by [email protected]
on 30 Mar 2014 at 5:24
Attachments:
from inxi.
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.
Original comment by [email protected]
on 30 Mar 2014 at 7:14
from inxi.
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.
Original comment by [email protected]
on 30 Mar 2014 at 7:23
from inxi.
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'.
Original comment by [email protected]
on 31 Mar 2014 at 6:48
from inxi.
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?
Original comment by [email protected]
on 31 Mar 2014 at 6:19
from inxi.
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
Original comment by [email protected]
on 31 Mar 2014 at 7:12
- Changed state: Started
from inxi.
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.
Original comment by [email protected]
on 31 Mar 2014 at 10:00
from inxi.
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
Original comment by [email protected]
on 31 Mar 2014 at 11:10
from inxi.
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.
Original comment by [email protected]
on 1 Apr 2014 at 12:38
from inxi.
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.
Original comment by [email protected]
on 1 Apr 2014 at 12:46
from inxi.
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
Original comment by [email protected]
on 1 Apr 2014 at 12:52
from inxi.
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.
Original comment by [email protected]
on 1 Apr 2014 at 1:03
- Changed state: Fixed
from inxi.
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.
Original comment by [email protected]
on 1 Apr 2014 at 1:08
from inxi.
oh, I misread, you said that /etc/slitaz-release exists? I added that to 2.1.14
as well..
Original comment by [email protected]
on 1 Apr 2014 at 1:11
from inxi.
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.
Original comment by [email protected]
on 1 Apr 2014 at 1:19
from inxi.
Related Issues (20)
- Feature Request: Add information on RAM slots HOT 1
- WeeChat is mispelled as "Weechat" and weechat binary isn't recognized HOT 6
- Limnoria ( a Supybot fork) isn't recognized HOT 10
- -c 0 problem (red continues) when FAILED HOT 1
- feature request: more ram details HOT 1
- slackware derivatives HOT 2
- boot loader information option HOT 2
- Wrong CPU clock speed reported on RaspberryPi since Linux Kernel v3.8 HOT 10
- Ignore wrong CPUTIN and use PECI 0 instead for sensor output HOT 8
- Please put the w option back inix -w HOT 4
- Export information in structured format HOT 3
- inxi.changelog executable HOT 1
- CPU frequency in OpenBSD? HOT 25
- inxi can't list remote partition name with space (\040) in fstab. HOT 5
- When formatting is stripped, inxi output is difficult to read
- Shows wrong init when using OpenRC HOT 18
- Fixed some missed quotes inxi_2.2.14 HOT 1
- Move code to Github HOT 5
- Weird characters in the Machine/System output
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from inxi.