SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I've largely completed the big refactor of big chunks of pinxi/inxi. This has cleaned up a LOT of bad perl stuff I was doing, optimized the code, sped it up, and fixed some long standing issues that were not fixable before this refactor. This will become, fairly soon, unless bugs are found, inxi 3.2.00, the long awaited logical volume handling release, plus too many small and larger new features, bug fixes, improvements, to list (the changelog is currently at about 375 lines)
RAM stick reports were improved greatly thanks to a timely issue an inxi user posted, now they pick the actual speed, not the specified speed, and also look for logical absurdities in speeds and note that.
As always: pinxi -U
if you have pinxi installed already, that being the development version of inxi, and
cd /usr/local/bin && sudo wget -O pinxi smxi.org/pinxi && sudo chmod +x pinxi
to install it.
The original cause for this rewrite, besides covid boredom, were two long standing issues, one, disk used totals being wrong if raid is present, and 2, logical volume display, which is now the -L/--logical option.
Most of the block device logic had to be either refactored or rewritten to make these updates possible, but I also took the opportunity to update a lot of the codebase, last I checked, pinxi has 4500 lines different from inxi stable, ouch!! RAID required a full refactor to get this new logic working as well, since it was kind of stuck on a messy hack that only supported mdraid / zfs, and supported them badly I think.
So the potential for bugs is real. Ways bugs can manifest are for example, N/A showing instead of 0 for storage or used sizes for various features, for example.
For systems with LVM (root required, sadly), ZFS, or Mdraid, pinxi/inxi now creates two totals, raw: and usable:, the usable: comes from the actual storage space you can use on the system, which means, the raid size total minus the raid component sizes. The 'used:' disk storage now always refers to the percent of usable total. For LVM systems, pinxi will also show lvm-free: for cases when the volume groups have free space.
The examples below were made to be silly, mainly to test various scenarios to catch bugs, and make sure all the features worked, I realize/hope most people don't actually do something like that, lol, but if you do, seeing the output of pinxi -L, -Lxxy, -Lay, would be great, because I do not have enough non-me generated test systems to make sure I haven't missed anything obvious or not obvious.
Thanks for checking it out.
For regular pinxi features, the most useful options to run are pinxi alone, pinxi -b, pinxi -F, pinxi -v8, with -z to filter if you are going to post output.
Here's a sample of the short and long forms of --logical from a test system I made to create complicated luks/lvm/bcache scenarios, and to test the logic to make sure it works as intended.
As far as I know (which isn't much), it's working as it's supposed to. Normally I do a
Code:
pinxi -F -a -S -m -W <location>
just for some more info for the heck of it. I like how the info on the drives gives how long they've been in use too with this command! My HDD has been in service for 6 and a half years (still working smoothly, by the way), and the SDD has been in use for 4 years.
Unless there's some issues observed soon, this will go live as inxi 3.2.00 later today. I didn't get the feedback I was hoping for, which is unfortunate for a set of changes this big, and the complexity of the --logical feature, so I'll have to trust that I did good enough testing on enough systems to catch most issues. I've been working on this for a few too many weeks, and it's probably time to move onto other activities, unless someone notices something off, or odd, or wrong.
can you show the output? I'm curious, I've only been able to test on vms and one remote test system. This was a hard feature to get working because it required refactoring several other block features and tools internally to make sure they could communicate and share certain data. In particular in RAID I had to strip out the original hacks from when I added zfs support to mdraid as a sort of tacked on bit, and make raid actually handle any number of raid types, like LVM, which required removing all the old hacks and trying to do it closer to 'right'.
Oh, good, that's a much more sane setup than my test stuff, I had gotten worried that the output was too long, but that's really because I was trying to create all the scenarios imaginable, most of which make no sense to do rationally, and because I just kept adding more disks and volume groups and layers. That output is much more manageable, thanks.
This is now out, inxi 3.2.00 is now inxi current master. As always, run pinxi to have the latest stuff, and to help find/fix issues, pinxi is already ahead of inxi because I decided to continue the internal code refactoring, but didn't want to delay 3.2 any longer, the refactors in this case either make no difference to users, or could potentially create bugs, so there was no point in rolling them into 3.2 since that would just delay release more.
This took a minute to figure out, it's one of the unintended consequences I feared from switching to stricter array dereferencing, in the pre refactor version I'd used splice to cut out the first parts of the derived arrays that weren't needed, but with using the actual data, when inxi does that, it's actually removing the first elements of the referenced arrays, which then makes the tests fail.
I was able to reproduce a form of this failure but using a different set of dmidecode features, but I think, hope, it's the same cause. On yours, my hope/guess is it was Battery using dmidecode that stripped out the first values, not positive though.
pinxi 3.2.00-03 should have this resolved, I hope, that issue I think only happened with dmi data, and would only manifest on the second use of the dmi data array, after splice had removed the indexes, heh. I was hoping to get this type of bug caught and fixed before release, but that's fine, at least it was found.
These fixes should correct your issues I believe.
Update/install pinxi [not inxi] to confirm this is corrected now in your case.
My case triggered different sets of errors, but hopefully it's the same cause, if it didn't fix it, then post the output of:
Use of uninitialized value in string eq at ./inxi line 11917.
This was actually an old bug, there were two failures, for dmidecode machine data, it failed to set the field board_version, and in the initial output tests, it failed to check if board_version was actually set before doing a string comparison on it. This bug has been present since inxi perl was created, and simply never manifested because only specific systems running --dmidecode for machine data would ever manifest it, and even then, most would not, or I would have seen a few years ago. This bug would never manifest on most debugger datasets because they don't use --dmidecode option to start inxi with.
In other words, a great bug find!! Since it is not always reproducible, requires specific hardware data to trigger, yet is a real bug.
This only occurs in a subset of systems, but luckily I found one where it does.
The other bug was the repeated one, that was introduced in 3.2, and is fixed now in pinxi. That one always happened if you used the right options, regardless of system.
So thanks for thinking of a test -F --dmidecode that exposed these old and new bugs, and for having a system where those bugs would trigger at all.
Since I need to move on, these fixes are now in 3.2.01, rushed out the door, that also includes some further internal refactoring but that should not be visible to users, just style adjustments.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
