-Gxx explains what, but not necessarily why, as when recovery or nomodeset parameters have been used to boot. It would be easier and time saving to not need to make two separate requests for information, inxi -Gxx plus cat /proc/cmdline, but searching inxi man page the string cmdline is not to be found. See e.g. www.linuxquestions.org/questions/linux-desktop-74/mint-19-1-cinnamon-opening-in-wrong-desktop-4175652747/#post5989057
Back to top

this could be of utillity, though I'm not really sure where that would go in inxi.

I also don't see it as being just an -Sxxx option since that information is only useful as you note in specific circumstances, and those boot options can be quite long. Then there's the question of what to show or not show, and how.

I believe it would work well as an --admin option, which is made specifically to show such data.
Back to top

This is now in pinxi 3.0.33-6, and will be in next inxi, 3.0.34.

note that there appears to be a bug or change in newer glxinfo, not sure what's up there:

Note that: inxi -baxxxzwould show the same basic data, including graphcis and the system line, so either -Faxxxz or -baxxxz or -SGaxxx would be the options support people would be asking for. Further note that there are many legacy inxi's packaged, and those pools will never update until a new release of the distro is done, and they will get the new inxi only once it's released and assuming they actually update their pools, so I can't do anything about distros not having current inxi versions.



I'm waiting for an issue reporter to finalize one issue before doing next inxi, but if he doesn't show up soon, I'll have to ignore that one.
Back to top

True, but we who request its output can also request it be updated with -U and B_ALLOW_UPDATE=true first.

Is 3.0.33-6 available to download? I looked for at least 10 minutes without finding any beta link.[/quote]
Back to top

pinxi is in the inxi-perl branch on github: github.com/smxi/inxi/tree/inxi-perl

Shortcut download URL: wget smxi.org/pinxi

Install somewhere in PATH, like /usr/local/bin, and then you can use the pinxi -U to get latest version from then on.

It's pointed at as well on github master branch README of inxi as the dev version.

pinxi uses its own configuration file, pinxi.conf, and is not related operationally in any way to inxi, otherwise it wouldn't work as a development branch.
Back to top

I never picked up on the development branch being named differently. This is nice to know.

When I saw pinxi in your example output, I assumed it was a local rename. I was looking for a download name that included numbers and dots. :p

Thanks for answering my request. :)
Back to top

When I was doing the rewrite to Perl, I called the dev copy pinxi so I could run the legacy version against the new version to test. During that process I realized that had worked so well that I would permanently make pinxi the beta/dev version. This lets all users track, if they feel like, pinxi, to see what's happening there, and run current master inxi as well.

It wasn't my original intention to make pinxi a permanent dev version, but it actually fixed all the problems I'd had in the past trying to get branch versions running, and testing the various stuff, and always getting mixed up. It also really helps during active development where a lot of patches will be done rapidly to debug and get a new feature running, that way I can confirm it works or not using the pinxi patch version, the -6 part of the version number. Sometimes that goes up to about 50 on some more complicated features.

I almost never run inxi by the way, usually the only time I run it is to confirm that next inxi in master all works correctly, then I go back to pinxi. Some of my test/dev systems don't even have inxi installed.

pinxi is kind of like Debian sid, Arch testing, or Fedora rawhide, rolling and unstable; inxi is kind of like Debian testing, or Arch stable - rolling but stable. There is no 'stable' non-rolling equivalent since current inxi is always the only supported one.

Your suggestion was a good one, pretty easy to do, easy to see why it's valuable, and a probable win for distro support since as you note, knowing the kernel boot parameters can be pretty important to debug stuff like video issues. If only all new features were so easy to implement, lol.

If you run, with sudo or as root: pinxi -U --man
it will also install/update the current pinxi dev man page, by the way. Without the --man it just updates pinxi.
Back to top

Seems "cmdline parameters" would be better than merely "parameters". Would --admin be the only way string "parameters" would ever appear in inxi output?
Back to top

line length is always a critical element of inxi output, and stuff is ordered by Upper lower case within lines, so:



Also, output is system agnostic, so if I find a way to get this data for the BSDs, cmdline is just a specific file name in Linux /proc file system, it's not actually anything beyond that. What they are are kernel boot parameters.

wiki.archlinux.org/index.php/kernel_parameters that Arch Linux page explains it well. You'll note their, and pretty much all other docs I found researching this, use of the term 'Kernel parameters' to describe what is passed to the kernel on the command line on boot.

--admin or -a is the only way to trigger this since it's verbose and in most cases not particularly useful to end users, this is why I made --admin/-a, to handle cases where the data is so specific and technical that it's only really useful for specific cases, but in those cases, it might be quite useful.

This is already out as inxi 3.0.34.

Basically, the assumption is: if you used -a/--admin, you know why you used it, thus, you also know what parameters refers to. Or the support people know why they asked for it, and what it means. I always use the minimum words/characters possible for inxi field names.

Support people in general, once they discover this, also learn to request: inxi -ba or -baxxx or -SGa or -SGaxxx or -Fa or -Faxxx depending on what they think they need to see.

Note that the -x options are not made for this type of extra output that is only occasionally useful to see, and so technical that most people won't really understand it. -xxx in general is used for data that is either largely useless, or undependable, or often not there, but still available. --admin are for sys admin tasks that are very specific, and can be verbose and extend output quite a bit. --admin was basically created for precisely this type of extra data, which is why when I realized it could be an admin option, I did it right away, otherwise there was no actual logical place to put this type of value.
Back to top