NOTE: missing product name/serial info, because it's not being treated by linux kernel
as a standard disk. Could not find that data anywhere in the system debugger dump.
If you know how to find the model name/number and or serial, let me know.
Also small fix, as noted: ip: should be ip-v4 to match with ip-v6, thanks mikaela.
Also some debugger fixes and updates.
Changes: updated inxi updaters to use github locations.
I will do this commit once for googlecode, and once for github, after that,
all commits will go only to github.
inxi moves to github, despite my dislike of for profit source repos, and git,
I decided that I just don't have the time or energy to do it right, so I'm going
to use github.
The project is already moved, though I have left inxi up for the time being on
code.google.com/p/inxi until I move the wiki to http://smxi.org
Everything is pretty much the same, the project url is:
https://github.com/smxi/inxi
The direct download link for the gz is:
https://github.com/smxi/inxi/raw/master/inxi.tar.gz
git pull is:
git pull https://github.com/smxi/inxi master
svn checkout url:
https://github.com/smxi/inxi
And that's about it.
showing Frameworks version, which is apparently NOT the same as the plasma version.
Also added debugger kde versioning to make this stuff less of an ordeal for data collection.
#kde-devel, now using kf5-config --version which gives similar output to kded4 --version
I use this for both 4 and 5, but since 4 has worked fine for years, I'll just use this for 5
and later.
normal, in this case, sddm decided that using a .pid or .lock file in /run was too easy
so they changed to some session id type string in the /run/sddm/ directory.
Speaking for myself, I find such pointless changes from anything resembling normal behaviors
to the reason that gnu freedesktop systems will never achieve significant desktop use globally.
Also, in the same vein, added debuggers to try to figure out what plasma5/kde 5 is using
internally to give command line version information. Again, something pointless internally
was changed, thus breaking something that had faintly resembled an api, which is of course
why desktop gnu linux will never actually take off, developers in the real world have no
interest in chasing after such pointless and never ending churn in even the most trivial
areas of the OS, let alone the core.
inxi remains however as a log of this ongoing churn and lack of discipline, and so remains
an interesting process of observation, and a way for users to try to avoid the constant
changes in simple system queries that should really never change, so I can see a reason
to keep it going since it's obvious that the actual foss ecosystem itself will not and apparently
cannot grasp that it is the lack of stable apis, methods, etc, that has kept desktop gnu linux
from achieving any actual real world success or popularity, and that is the actual problem
that should be fixed, not some pointless internal change to something.
On the source repo front, maintainers, I still can't find an acceptable alternative to the
impending shutdown of googlecode. github is a for profit venture that people who seem totally
void of any sense of history believe is actually going to be around longer than say, sourceforge,
or googlecode, as a legitimate source hosting site.
I'd welcome any suggestions. So far all the options are bad that I can find.
Top preference is svn, but if git is the absolute only other choice for an otherwise good option,
I'd consider git, but it's a horrible option for inxi because of how inxi development and debugging
works, vs how git works. ie, svn branches are perfect, git branches are totally wrong.
I may end up just hosting the svn on my own servers to avoid having to move yet again when the next
for profit flakey site decides to close up or monetize the source hosting.
The original idea of googlecode was for google to 'pay its dues to the foss community', but apparently
they got bored with that idea, plus of course, the ongoing total failure of google to deal with
automated spam, which has always been a huge bug in the core google corporate culture. But googlecode
was by far the best option I've come across, it was done by a deep pocketed corporation not for profit
for pretty good reasons, and was never intended to be a profit center, which is the closest I could
see for a non free option.
Setting up svn gui stuff however is a royal pain and requires ongoing maintainance for the life of
the software, which is NOT fun, nor will I sign up for that obligation.
I may end up moving to github anyway, even though git truly sucks for inxi and myself, but it's an
idea I find fairly vile, apparently free software (sic) authors seem to have no grasp of the concept
of fredom when it comes to source code hosting, judging by the absurd popularity of github as the
default go to source repo. Their website is pathetic as well, which isn't very promising.
So we'll see where it goes, I think I have until august to decide what to do for source hosting.
Since I'm old enough to have seen sourceforge and now googlecode do the same thing, along with a lot
of other options, to say github won't do this too is delusional, what you can almost certainly say is it
will do it, the only question is when. But, just as Linus did with his non free linux kernel version
control, people will stick with the non free stuff until you realize you can't use it anymore, because
it is non free. Free software hosted on non free source repos is to me one of the most absurd and
stupid things I've ever heard of to be honest.
the switched file name. Kudos to anyone out there fighting to create a working alternative
to the unreliable and buggy and windows emulating systemd, I wish devuan luck. Maybe between
devuan and gentoo and slackware we can save the free software core systems before it's too late.
pet peeve of mine. Now, if -I, -b, -F, or anything that can trigger the memory: used/total
in Information line is not used, -tm will always show the system used/total ram data on the
first line of the Memory item of -t output.
Also, if -xtc (trigger ram data in cpu output) is used, and -I is not triggered, and -tm is
not triggered, will also show system used/total ram data on the cpu first line.
I'd found it odd that this data did not appear when -tcm or -tm or -xtc were used, so this is
now fixed. I used the -t option a fair amount to find memory/cpu use issues, and usually I
don't use the option with other options, so the lack of total system ram data was odd.
long term solution to identify itself, so the hack I had in place fails on new MATE.
We'll see if this does it for various glitches, now quassel and mate latest should
again be working.
fine for all derived distros like Sabayon as well. The test looks for:
/etc/portage/repos.conf/ and type -p emerge
if found will then grab the repos from the source files found.
Note that the logic for this was almost identical to that used for rpm so it was an
easy addon. Please let us know if you have an issue and provide data samples of relevant
files.
1. Tightened runit init detection to use proc, note that if runit works on BSDs inxi will
require more data to properly detect it on BSDs..
2. Use openrc runlevel tests natively if openrc detected.
3. Fixed subtle issue with alias to inxi file and paths.
4. Added rc-status data collection for debugger, improved debugger data collector handling
of bsd and other tests to note absent if not there in file names.
Fixed bugs in Epoch init system detection, caused false positives in systems booted on
SysVinit, but with Epoch installed. Epoch turns out to be in PID 1 == epoch (/proc/1/comm)
so that's easy to fix.
Also fixed spacing isxue with OpenRC output in -I line.
at least on the system I got data from, is not using .pid/.lock extensions, but other systems
are, I'm adding sddm AND sddm.pid detection. This required changing the id to use explicit -f
for test, not the previous -e, which will force only files, not directories, to trigger yes case.
No other changes, but it's worth updating to this because distros may start using sddm in the not so
distant future, it's beta currently though.
as of yet unknown reasons, so rather than wait to see the bug resolved, I'm just removing
uptime as a depenendency, though this is a short term hack only because we don't know
why it was removed from procps or if that was just a mistake, or if other things as well might
be vanishing from procps. Am leaving in however uname as dependency because inxi cannot
determine what platform it is when it starts without that.
output for apt repos. Also refactored duplicated code into a function, no other changes.
Note that this version features the repo debugger tool as well, which is very helpful in
particularly non apt systems to fix issues with its handling of repo formats etc.
fixes a single scenario with apt, where there is only sources.list, no .d/*.list files.
I was assuming that the file name would print out in the output of single file grep,
but that only happens with multiple files.
bsds: removed dragonly specific used mem hack, now will work for any bsd, if avm in vmstat is 0
adds a flag to value, and removes it when used.
Nothing else of note.
Added support, basic, for bsd hard disks, and optical disks.
Added hard disk total/percent used for BSDs, sort of.
These are mostly just hacks since the data isn't easily available from system
standard tools, though I could on freebsd use gpart I guess but that's another tool
needed, and another method, too much work imo for small results.
Now the short form, the -b/-v1 form, and the -C forms are all similar.
Also, added a few hacks to try to extract cpu max speed from cpu model string in
either sysctl -a OR /var/run/dmesg.boot data in freebsd/openbsd. Sometimes it may
work if that data was in the model string. It's a hack, but will do until we get
better data sources or they update their sources to list more data.
handling. Or rather, non handling, since that data only showed in rare cases on short form
(inxi no args) output. Now it uses /sys query to determine min/max speed of cpu, and uses
that data to override any other min/max data discovered.
Still uses /proc/cpuinfo for actual speeds per core. The assumption in this is that all
cares will have the same min/max speeds, which is generally going to be a safe assumption.
Now in short form, inxi, output, it will show actual speed then (max speed) or just (max)
if actual speed matches max speed. Same for -b short CPU output.
For long, -C output, shows max speed before the actual cpu core speeds per core.
With -xx, and in multi cpu/core systems only, shows if available min/max speeds.
Note that not all /sys have this data, so it doesn't show any N/A if it's missing.
permit wget/curl/(openbsd ftp)/(bsd fetch) interchangeably.
This lets more standard downloader defaults in bsds, as well as curl on gnu/linux systems
without triggering an error of missing wget.
1. Fixed cpu core issues on bsds, now shows core count + if > 1, cpus total.
2. Now shows OS instead of Distro on short/long output, since each bsd is an OS.
3. fixed vmstat issues for used memory outputs
Also fixed potential failures with cpu core count array by making it a ',' separated array.
-m/-M would always show requires root for dmidecode no matter what. Also improved dmidecode
error messages/handling.
Also, a fix for no display card data, now shows as expected no card data
Most other fixes are for bsd, mostly openbsd.
1. Added a class for network devices in freebsd pciconf
2. Added -r support for openbsd
3. Fixed some cpu issues for openbsd
4. Fixed an issue in openbsd/freebsd where client version data failed to get cleaned
5. Changed inxi short form output for bsds to show OS data instead of kernel data.
6. BSDs, maybe all, different syntax in xorg.0.log made unloaded gfx drivers not show,
that is fixed now.
-p fixed file system type in -p/-P for openbsd, now shows.
-I / inxi short - fixed used memory, did not show in openbsd, now does.
-f fixed cpu flags in openbsd, now works
-C corrected corrupted cpu data outputs, in openbsd at least, maybe also freebsd
-C added an openbsd hack to sometimes show cpu L2 cache
-m/-M fixed/improved dmidecode error handling for all systems
Modified handling of dmesg.boot data, synched so gawk can parse better.
Now all lines are stripped of ending whitespaces automatically.
Also a dmidecode error handler correction, that was not working right in bsd systems.
Added some debuggers for bsd systems.
output, like so, instead of the old quotes "XFCE4" it shows like this:
XFCE_DESKTOP_WINDOW(WINDOW): window id # 0x1000003
Updated and added a much less strict fallback test case.
I have collected enough datasamples to allow for reasonably fine grained corrections, estimates,
warnings about unreliable capacity now, and have fixed all major failures.
Also, because this stuff is filled out by people somewhere, or not, some fields often are just
empty, or contain the default values, ie, they are worthless. inxi shows N/A for those situations,
it means there is really no actual data to show you.
This feature, sadly, well never be totally reliable, because dmi data is frankly junk, especially
dmi type 5 and 16, which is what is supposed to tell you total capacity of memory array, and the
maximum module size (type 5). However, this data is totally random, often it is right, sometimes
it is wrong. Sometimes type 5 is right and type 16 is wrong, sometimes the other way. And since
type 5 is only present in some systems, it's not reliable anyway.
What is reliable and always right is the actually installed memory per device, ie, sticks. I have
not seen any errors in that, so that seems to be actually coming from the system itself. type 5 / 16
sadly are clearly entered in manually by some poorly paid engineers out there in the world, and are
often total fictions, either far too small, or far too big, or whatever.
inxi will attempt to correct all clear logic errors, and whenever it changes the listed data from
type 5/16, it notes either (est) or (check). (est) means it is a good guess, one I am comfortable making,
(check) means it is either an unreliable guess, or that what the system is reporting is so unlikely that
even though inxi is showing it, it doubts it could actually be true, or at least, it thinks you
should check this yourself.
-m has 3 extra data options, -x prints the part number, if found, and the max module size, if type 5
is present. inxi does NOT attempt to guess at max module size based on what is installed, it only will
correct a listed max module size if installed modules are > than listed max size. Usually part numbers,
if present, are all you need to order a new stick.
-xx shows serial number, manufacturer (often empty, or just random alphanumeric identifiers, but sometimes
they list the actual company name, which is helpful. It also shows, if type 5 data is present, single/double
bank.
-xxx as usual shows largely useless data that may be of interest to soemone, like if ram type is synchronous,
memory bus width data, and module voltage (type 5 data).
This feature will never be reliable I am sad to say because the source data itself is random and much
has been filled out, or not filled out, by engineering drones somewhere out there in the underpaid
world. The ranges of errors are so wide that inxi just has to check what is possible, reasonable, unlikely,
etc, to generate its numbers. In other words, this is NOT just parsing dmidecode output, that is the raw
material only, sad to say.
So this is it, for better or worse. All bug / issue reports with this MUST come with a full:
inxi -xx@14
hardware data upload, run as root.
Also, much to my annoyance, this feature requires root, since /dev/mem needs root to be read, and I assume
the dmi table, so that is a departure from normal inxi standards, as is the low quality input, and thus,
output, data, though I can guarantee that what inxi tells you is in most cases on average more accurate than
what dmidecode tells you, since dmidecode simply prints out what it finds in the dmi table, and nothing else,
in whatever order it finds it, from what I can see, ie, you also cannot trust the order of dmidecode output.
I had been hoping that /sys would start to contain memory data like it does mobo/system data, but it never
happened so I finally decided to just do the ram thing, require dmidecode, require root/sudo, and that's
that.
There will be issue reports, you can help them by looking up the mobo stats/specs yourself and listing them
in the issue, so I don't have to do it. I use the tool at crucial.com which is very accurate and also very
complete in terms of all possible hardware out there.
I would trust that tool before trusting the companies that have the least reliable data, like ASUS.
Much thanks to everyone who is contributing datasets, and the distros, particularly siduction, that really
were very helpful in this process, by finding more and more failure cases that helped me start to tighten
the logic, and make it more and more robust. Special thanks to Mikaela, of #smxi irc.oftc.net, who came up
with two systems that both required a full redo of the logic, and thus who helped a lot in this process.
size, derived mod size 2gb, listed cap 8, but 2 slots, ie, 2gb x 2 == 4. Made this
retain the listed size, but adds (check) to it because either max mod size is wrong
or cap is wrong.
types, in at least one case, it is last, so can't use that as trigger to start loop.
Now using: Table at .. which is always at start of dmi output.
Also, changed size output per module to be in MB GB TB instead of all mB, since modules
are sold by GB or MB, the data should show that as well. Also shortens output.
type 17 in front of type 16), now each array is created as a multidimenstional, 2x array,
and each device is a 3 dimensional array. This seems to clean up the problems with bad
ordering of dmidecode data.
at least making good guesses when the data is bad for ram, and hopefully will not break
too many cases where it was actually right but seemed wrong.
Unfortunately, dmidecode data simply cannot be relied on, and is FAR inferior to the type
of data inxi tries in general to present users, ie, taken directly from the system, and,
ideally, more accurate than most other tools. But in this case, there is just no way to get
the data truly accurate no matter how many hacks I add.
But if you have bad data, then submit: inxi -xx@ 14 so I can take a look at the system,
and see if I can modify the hacks to improve that data.
it is too big, and sometimes too small. Changed data gathering to use arrays, then print/process
the arrays once they are assembled.
Now it will get rid of any max module size if it's greater than the calculated capacity, and it
will generate an estimated capacity/max module size if they are clearly wrong because actual
module sizes are greater than listed max size, or capacity is less than greatest module sizes times
number of devices.
Not perfect, but it never is, this covers more cases now correctly than before.
