is I believe the only one that actually uses this at this point.
Preferred is lsb-release, because that tends to be more accurate.
Note, this may trigger arch derived distro errors, sigh...
in path, ie, /dev/mapper/truecrypt1 for example.
Also fixed some subtle bugs that could in some instances trigger errors on partition label/uuid, not likely, but it could.
via xprop, so that is now moved to full desktop version handling. This requires bypassing the gnome test, which
is a good thing, because the gnome test uses a deprecated method for gnome detection. Still works, but best to
move from it no matter what.
New tarball, new inxi version.
that makes it a bit more readable. New version number, new tarball.
I debated making it one per line default as soon as -x is triggered but will leave it this way for now, with -xx
you get the easier to read single line output in all cases, so that's probably good enough.
ssh'ed into box, and don't remember what dm is running the desktop. Shows N/A if in X if nothing detected, does not show
out of X since could be a headless server.
Updated man page, new tarball.
And if user is logged in as root. The -U procedure for inxi itself will run independently of that.
On completion of inxi download/update, if successful, will do the man page update/install.
And that's that.
Biggest change, totally reworked the man page, now it's much more complete and has a lot more information.
Includes how to run in IRC clients, how to create konversation shortcut for /inxi type start.
Ok, that's it, probably will refine the desktop extra information and maybe add a dm or two more.
Also added in startx detection for when no dm was detected, thanks JavaAtom for that one.
I decided to just add an -xxx option, for extra extra extra data, no output if nothing detected.
No big support issues, and Mint has used inxi by default for a while, so I think it's fine to add this for them.
entrance gdm gdm3 kdm kdm-trinity lightdm lxdm mdm nodm slim wdm xdm
there's been a relative flood of new display managers, and a few more are probably coming, so
it's actually a somewhat useful thing to have this option.
This is also going to close issue 30, which is not going to be further handled due to ratrace
of trying to support various software packages running on the systems.
Also updated man page for that -xx item.
Now RAID works like this:
-b - if no /proc/mdstat, or if no devices found and module is running, show nothing, otherwise show short form as before
-F - if no proc/mdstat, show nothing, if no devices but mdstat and if -xx, show all lines, otherwise show normal
-R - show all messages and missing file/module information so users, particularly sys admins, know right away module
is running even if no devices.
-v 6 and less, like -F. -v 7, like -R run, ie, show all messages.
this gets rid of unneeded line output given that only if you have md_mod running will you have any data for /proc/mdstat
and that module is only running if you have mdraid installed.
Also redid the no data messages for no module state and no devices state to better reflect what is actually happening.
Good adjustment and good cleanup of unneeded output while tightening the actual usability of the specific messages received.
Includes 4 levels, -b shows basic only, -R shows primary info, device id, components, state, and report on drives
-Rx shows more, and triggers a second info line per device with more raid info.
-Rxx also adds more information, and triggers system raid support info and unmounted raid devices line.
-F uses -R now.
And that's that, enough raid stuff for a lifetime.
That would need to be set in the inxi override config file. The page must show only
one line of output, and that last item on that line must be the ip address.
Ok, that's it, not a big deal, but some people may prefer a non smxi ip address page
for whatever reason, so have at it. Or not.
inxi thinks it's a single core cpu, no matter if it's multicpu or multicore.
Using the: cpu cores
value to double check, as a fallback. This seems to work, ie, if cpu cores is listed as 1
but processor count * cpu count is > 1, then clearly the intel reporting bug is in play.
Note that this is NOT an inxi bug, but is a bug in how some intel cpus create their
cpuinfo data, but since intel is a major player, it's worth handling that issue.
Apparently if you pack an array that is global inside a subshell, that does not register on the primary level of bash.
Who knew?
Maintainers, this is a serious bug fix, so updat to 1.7.27 now or the usb cards will not be seen.
Fixing this required using find, so find will have to be added to the recommended apps, but
leaving it off for now until sure this method is the only way to do it.
The earlier used grep method to get the paths did not work, why, I don't know.
This may require redoing the usb path finder logic, we'll see.
