Testers for inxi/pinxi redone -C CPU logic... huge internal changes
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 agree, I don't think we have to worry about the getconf -v. The || might be useful in the future if you're checking for _POSIX_V7_LP64_OFF64 but that's a total guess on my part.
-6 is testing fine so far.
Only thing is circling back to the df -T -k output on Solaris 9 (and I'm sure I've seen this on other older operating systems like hpux or aix). Pinxi is stumbling on the output being spread across more than one line for the nfs mount. It's brought back bad memories of having to deal with this exact problem ages ago in one of my own scripts.
My small laptop computer has a 64-bit processor. However, I can not run 64-bit software upon it, because the manufacturer (ASUS) choose to have the BIOS set a flag during boot-up which causes the processor to run in 32-bit mode. (So, I run the 32-bit version of Slackware.)
I have read that it is possible to copy the BIOS-code out of the PROM, edit the code to set the 64/32 bit flag the other way, and then write code back to the PROM. This project is rather far down my to-do list...
It's so annoying when they do something silly like that, but probably had some 32bit only driver or something eh? What year did that laptop come out?
Btw, I hope my sarcasm was clear with that earlier statement.
Oh, the wrapped df output issue. One of worst things to deal with. inxi is actually supposed to deal with that, or try, but that's what the df -P flag was for, which isn't useful if it's not supported of course. If i remember right, once I discovered the df -P option, I removed the hanging line logic, and figured that BSDs wouldn't have such long lines, or hoped.
That issue is wrapping cli output I've found one of the very worst practices in the *nix world, it's like they literally do not stop to think that something might actually be using the darned data and need it to be formatted consistently.
Since this problem can I believe only happen with BSDs that don't support -P, I added in a small hanging line reconnector, more code...
--fake partitions --bsd openbsd lets me fake with real data, makes it fairly easy to fix these things (requires the files to be in the right path on dev system), I hadn't realized initially that this was the dreaded "80 column so why not wrap the output and make all parsing of it break" issue that is all too common with the output of the various BSD tools. There was a sad little comment in the inxi code in that block that noted that Linux has -P, and that BSDs would hopefully not have wrapping lines... lol, sigh...
These kinds of hacks are really ugly, and make the code ugly, basically what inxi has to do is fix their broken output, fix the fact they never modernized to using -P to avoid specifically this very issue, or, better yet, just didn't wrap the darned output in the first place. Now the question is, when was -P introduced for df? In other words, should I make this pre processing fix global or bsd only?
I'm glad I opted to do the global fix, thanks for confirming.
I'd also fired up FreeBSD 12 and found -P supported, hadn't checked my OpenBSD 7.0 install for that. As usual, doing switch based tests is not as reliable as doing feature support based tests.
Because of these changes in df behavior in the BSDs, I've made these tests completely dynamic, and now they ignore if bsd, all they care about is if the feature works or not. This is probably what it should have been all along. This shoots backwards compatibility way back for Linux as well, and for all reduced feature linux like open-wrt, busybox, and tinycore.
pinxi 3.3.11-08 has these changes:
Remove bsd switches in some of the partition logic
For df -k, -kT, -kTP support:
if system supports df -kTP, use that, and set -P found switch to skip hanging line loop
else if system supports df -kT, use that
else if system supports df -kP, use that (busybox for instance), and set -P found switch
else use df -k, and also get mounts data so that can be used for file system type to fill in the missing -T fs type.
If not -P found, before main partition data processing, check for hanging lines, reconnect if found, including support for remote names with spaces in them, hopefully anyway.
Added dynamic columns testing for actual number of returned columns, was hardcoded before, with the darwin df variant that has 3 extra columns.
This will have no impact at all on Linux so I won't do a new release until there is more reason for it, but was good to get locked down since it can hit many corner cases, not just very old Solaris installs, heh.
Debian Sarge, released 6th of June, 2005, df -P supported. Man df shows coreutils version 5.2.1 release date July 2004. So basically all inxi supported Linux had this feature working, except busybox and tiny variants like that. Many times it's busybox that is the most restrictive re features, that's also an issue with ps output that inxi uses.
Heh, just nice to put this old gear back to work for something.
-8 looks good. FYI df -T doesn't work on Solaris 10 (no -P either), which is why it didn't have the issue that 9 did. There's 5 different df's under /usr on Solaris 10...which reminded me of the /usr/ucb dir still being around.
Debian Sarge, released 6th of June, 2005, df -P supported. Man df shows coreutils version 5.2.1 release date July 2004. So basically all inxi supported Linux had this feature working, except busybox and tiny variants like that. Many times it's busybox that is the most restrictive re features, that's also an issue with ps output that inxi uses.
I don't recall it ever being an issue on Linux, but that could just be my memory. I've still got a drive with Slackware 3.4 on it I could test...lol. When I get back to fixing the Dallas clock chip/battery maybe...
Last edited by fourtysixandtwo; 12-22-2021 at 08:28 PM.
For the sake of completeness, booted up a netbsd 9.1 vm, df -kP supported, -T not supported. So that looks like this fix is going to cover a lot of systems, which is quite good, that's the best kind of fix I generally hope for.
Looks like this sequence is right: if -kTP, use, elseif -kT, use, elseif -kP, use, else if -k, use.
Comments also noted that busybox supported -kP but not -kTP, making this one even better. TinyCore supports -kTP.
Yes, it is hugely annoying that the manufacturer restricted the 64bit processor to only 32bits. It may be that a driver was the impetus behind the manufacturer's choice; if I remember correctly I read that Microsoft never did make a 64bit driver for WinXP for the video 'card' in this computer.
Quote:
Originally Posted by fourtysixandtwo
It's so annoying when they do something silly like that, but probably had some 32bit only driver or something eh? What year did that laptop come out?
Btw, I hope my sarcasm was clear with that earlier statement.
I did not catch that you were being sarcastic --- I thought you were being serious, and so I was supplying information. In any case, I was not offended. :-)
@h2-1: sorry if my questions are off topic, but here goes.
In the "auto" mode (and script) of the Slint installer, I would like to find the best settings for the drives target of the installation while asking the user only questions for which the script can't find answer.
More specifically I would like to install an f2fs file system on SD cards and possibly on USB sticks (although i have read that this is risky in the latter case), maybe also on SSD but not on hard drives and provide relevant options for SSD vs hard drives in /etc/fstab
But I didn't find a way to distinguish between an SD card in an USB enclosure and an USB stick, nor between a hard disk and a SSD, especially if both are connected through USB.
How can inxi help me? Or do you know other ways to make sure of the kind of the device I am trying to adapt the setting to?
Any clue appreciated.
Last edited by Didier Spaier; 01-15-2022 at 02:34 PM.
As a side note, I've just added slint/slackware distro ID/system base detection to pinxi, will be in next inxi, 3.3.12.
All of these are problematic.
I had to check the logic, it has been revised a few times. Currently it makes guesses based on some parameters available without smartctl, and detects certain things that must always be solid state, but those are very unreliable because they are just string tests on the model name. It's all just fallbacks testing one thing after another, there is no single reliable data source that provides this information that I am aware of.
inxi makes further fallback attempts to deduce if spinning disk or ssd with smartctl. But that is also not reliable, it's just usually ok. For inxi, if it was unable to determine conclusively if it's spinning disk, which if supported, shows rpm, or ssd, which also has some values that can determine that, but they are not always there.
If inxi shows rpm value for disk, that's I believe 100% certain that it's a spinning disk, since that value can only come from a spinning disk. However, if it does not show it, that does not mean it's not a spinning disk, since that value is not always there for a spinning disk.
Detecting sd cards is even harder, though there might be an alternate way using /sys data that I haven't used or discovered. However, if inxi shows SSD, that is reasonably sure to be correct as well, depending somewhat on the data source, but usually it's going to be right. If it does not show the type: field at all, it means it couldn't get anything conclusive, that can mean many things, an old hdd, a current solid state drive that just didn't report the required data, which is particularly difficult to obtain if it's an /dev/sdx type drive.
If run as root, inxi will make a good attempt to deduce SSD or spinning, regardless of if usb enclosure or local in machine, but that data is simply not always present or available.
The things that will in general be right are: usb drive detected, vs non usb.
MicroSD and SD cards tend to have a very short terse product name, usually too terse to safely deduce anything from it, inxi processes product names of drives to attempt to derive the vendor, so I'm reasonably famililar with the range of possible names, and the short answer is, don't try to use the product name to deduce anything, it's not reliable, and definitely not definitive, inxi uses a huge matching table which grows usually every release to try to get the disk vendor, with reasonable success.
It's all 100% empirical, sd cards will often or usually ID as mmcblk devices, but I haven't tested usb mounted sd cards explicitly to determine it, but I believe they show as sd devices like other usb block devices, but even a test won't determine that conclusively because this stuff varies a lot.
I have never found a 100% reliable way to determine ssd/rotating, inxi uses the best method I've found, and it's absolutely not 100% reliable, and when it fails to accurately deduce the drive type, it shows nothing.
So inxi run as root/superuser is going to do its best to determine this, but currently has no internal interest if an ssd is a nvme, m2, microsd, sd, standard sata ssd. It will almost always show usb type correctly, and it will sometimes be able to get rotating or ssd for external usb drive.
But usb is another rathole, very difficult, some external enclosures allow querying the drive inside them directly, others do not, that's another few steps. There's a reason inxi needs about 2000+ lines of code, in addition to 300 or more for BSDs, certain types of data are just very difficult to get and process, similar in this case to CPU, but modern cpu data proved to be very reliable on Linux, but disk data is not reliable at all when it comes to certain things, disk temp, if modern drives, good, if old, not good, ssd/rotating detection, depends, sometimes good, sometimes not, mmc sd type detection, doesn't exist in inxi, and won't unless I find some better way beyond detecting that it's a /dev/mmcblk type device, which is all you need to conclusively detect mmcblk storage devices, but that doesn't work on usb mounts as far as I know.
Sometimes new data types in /sys make certain things possible, that was certainly the case with /sys cpu data from 10 years ago compared to today, which is why inxi didn't use very much /sys data for cpu since it was created before that advanced data existed in /sys, now it leverages it heavily for default output.
This topic isn't really good for this thread however, it's its own topic, but not one I can spend time on at the moment since I have to do other things.
As with all inxi features, things change and evolve, and sometimes new methods are possible that allow for things that could not be reliably done before to be done much better, as we saw with this cpu thread. However, those things also always require large data sample collection to determine the variance possible. It's never easy or obvious once you leave the core reliable methods, like /proc/partitions, behind.
But /sys has been advancing in the block device area, but I also always see that sometimes those advances are not backward compatible, and depend on new hardware features or certain hardware firmware self reporting things that did not exist on older hardware, or more basic hardware like sd cards.
If you need a short answer, this is it: don't try, you can't get it reliable enough to always work. You can get it to sometimes work. And inxi can often get much of that data correctly.
There's a few reasons inxi puts certain types of data as an -xxx option, one is that it's extremely unreliable, another is that the data is not always present, another is that it's only of minor interest. The first two conditions apply to rotating/ssd detections.
Note that a positive smartctl detection of rotation or non rotation is also not 100% because some cases trigger false ssd positives, like a spun down rotating drive.
Case of all drives reporting full data, type and temp, not surprising since it's my dev system:
Many of these successful matches depend on various string detections, of their /dev/... block id, of their model name, etc, that is, they are extremely low quality detections.
There's probably more advanced ways of doing this more reliably, but maybe there aren't, I don't know. inxi I think checks maybe 4 or 5 different tools to use for some of this data, and does string compares for some, but I would not rely on that for anything critical. Sometimes it's just best to have the user complete the data and have them be responsible for failure, not you. That's why inxi doesn't show anything there if it could not get anything reasonably reliable.
In this case, I believe though not certain that the actual model data comes from the usb microsd adapter, not the sd cards.
Note, it's id'ed as a standard sd device, that's the normal case for this. Because it has no real model name data, which is also normal for microsd/sd cards, it was not able to make a string based positive SSD id, so it doesn't pretend that it could.
I have a huge amount of sample drive model name data, and usually locally mounted mmcblk devices are of course going to be in most cases microsd cards, but I don't know that for sure, I don't know all possible variants.
Here's a spinning usb disk:
Code:
ID-5: /dev/sde type: USB vendor: Western Digital model: WD15EADS-11P8B2
size: 1.36 TiB type: N/A serial: <filter> rev: 2002 scheme: MBR
# then with sudo pinxi -Dxxxz which will use smartctl fallback:
ID-5: /dev/sde type: USB vendor: Western Digital model: WD15EADS-11P8B2
size: 1.36 TiB type: N/A serial: <filter> rev: 2002 scheme: MBR
As you can see, in all cases, inxi was not able to determine the type, so did not guess.
Thanks for your answers h2-1. So I will only continue to make a f2fs file system for partitions whose path begin in /dev/mmcblk, plugged in directly in a fixed card reader, not in an USB enclosure. I remember having asked a similar question in the f2fs-dev mailing list, they didn't know a reliable method either...
Last edited by Didier Spaier; 01-15-2022 at 04:31 PM.
Reason: typo fix
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
