cmd <inxi> glitch ??

[Bewildered Bob]

When running cmd <inxi> with various options the entire system freezes and must be re-booted. The most reliable option is -G (graphics) but -b (basic) often fails and -Fxxxrz almost always fails. Failure occurs after first 3 sections (System, Machine, CPU) appear on monitor; Graphics section would be next if freeze didn't occur first (but if only '-G' option is entered the complete Graphics section alone appears). GO FIGURE !!

Current dual-boot config is Cinnamon in sda5 and LMDE ("Debbie") in sda7.

There is an EZ graphical work-around - System Reports -> System Info since output contents appear identical to running <inxi> (see below)

(1) is any data needed for Forum use missing from System Info shown below ??
(2) what is unique abt <inxi> that causes this strange failure consistently ??
(3) all possible "effects" are OFF (except "style" which is set to 'default')
(4) lower monitor resolution often helps but preferred 1920x1200 works well for all other pgms/apps/cmds

Code: Select all

System:    Host: hp505 Kernel: 4.19.0-17-amd64 x86_64 bits: 64 compiler: gcc v: 8.3.0 
           Desktop: Cinnamon 5.0.5 wm: muffin dm: LightDM Distro: LMDE 4 Debbie 
           base: Debian 10.2 buster 
Machine:   Type: Desktop System: Hewlett-Packard product: HP 505B Microtower PC v: N/A 
           serial: <filter> Chassis: type: 3 serial: <filter> 
           Mobo: PEGATRON model: 2A99 v: 6.01 serial: <filter> BIOS: American Megatrends v: 6.10 
           date: 07/02/2010 
CPU:       Topology: Dual Core model: AMD Athlon II X2 250 bits: 64 type: MCP arch: K10 rev: 2 
           L2 cache: 2048 KiB 
           flags: lm nx pae sse sse2 sse3 sse4a svm bogomips: 12054 
           Speed: 800 MHz min/max: 800/3000 MHz Core speeds (MHz): 1: 800 2: 800 
Graphics:  Device-1: NVIDIA C61 [GeForce 6150SE nForce 430] vendor: Hewlett-Packard 
           driver: nouveau v: kernel bus ID: 00:0d.0 chip ID: 10de:03d0 
           Display: x11 server: X.Org 1.20.4 driver: nouveau unloaded: fbdev,modesetting,vesa 
           alternate: nv resolution: 1920x1200~60Hz 
           OpenGL: renderer: NV4C v: 2.1 Mesa 18.3.6 direct render: Yes 
Audio:     Device-1: NVIDIA MCP61 High Definition Audio vendor: Hewlett-Packard 
           driver: snd_hda_intel v: kernel bus ID: 00:05.0 chip ID: 10de:03f0 
           Sound Server: ALSA v: k4.19.0-17-amd64 
Network:   Device-1: NVIDIA MCP61 Ethernet vendor: Hewlett-Packard type: network bridge 
           driver: forcedeth v: kernel port: e480 bus ID: 00:07.0 chip ID: 10de:03ef 
           IF: enp0s7 state: up speed: 100 Mbps duplex: full mac: <filter> 
Drives:    Local Storage: total: 530.98 GiB used: 7.05 GiB (1.3%) 
           ID-1: /dev/sda vendor: Samsung model: SSD 860 EVO 250GB size: 232.89 GiB 
           speed: 3.0 Gb/s serial: <filter> 
           ID-2: /dev/sdb vendor: Seagate model: ST3320418AS size: 298.09 GiB speed: 3.0 Gb/s 
           serial: <filter> 
Partition: ID-1: / size: 47.81 GiB used: 7.05 GiB (14.7%) fs: ext4 dev: /dev/sda7 
USB:       Hub: 1-0:1 info: Full speed (or root) Hub ports: 10 rev: 2.0 chip ID: 1d6b:0002 
           Hub: 2-0:1 info: Full speed (or root) Hub ports: 10 rev: 1.1 chip ID: 1d6b:0001 
           Device-1: 2-3:2 info: Microsoft Wireless Optical Desktop 3.0 type: Keyboard,HID 
           driver: microsoft,usbhid rev: 2.0 chip ID: 045e:009d 
           Device-2: 2-4:3 info: Logitech M90/M100 Optical Mouse type: Mouse 
           driver: hid-generic,usbhid rev: 2.0 chip ID: 046d:c05a 
Sensors:   System Temperatures: cpu: 29.0 C mobo: N/A 
           Fan Speeds (RPM): N/A 
Repos:     No active apt repos in: /etc/apt/sources.list 
           Active apt repos in: /etc/apt/sources.list.d/official-package-repositories.list 
           1: deb http: //packages.linuxmint.com debbie main upstream import backport #id:linuxmint_main
           2: deb https: //deb.debian.org/debian buster main contrib non-free
           3: deb https: //deb.debian.org/debian buster-updates main contrib non-free
           4: deb http: //security.debian.org buster/updates main contrib non-free
           5: deb https: //deb.debian.org/debian buster-backports main contrib non-free
Info:      Processes: 161 Uptime: 1m Memory: 3.61 GiB used: 611.3 MiB (16.5%) Init: systemd v: 241 
           runlevel: 5 Compilers: gcc: 8.3.0 alt: 8 Client: Unknown python3.7 client inxi: 3.0.32 

[karlchen]

(1) is any data needed for Forum use missing from System Info shown below ??

The inxi output, generated by System Information, is as complete as the one, generated by inxi -Fxxxrz executed in a terminal window.
Actually the inxi coommandline executed by System Information is very similar.
Therefore off-hand I have got no idea why "inxi -Fxxxrz" will make your system freeze.

[h2-1]

There's something not being stated here for sure.

What does 'cmd <inxi>' mean?

cmd isn't a thing unless you are in an irc client, specifically, /cmd .... in konversation.

When you run inxi, it looks like so: inxi -Fxxx (or whatever options you use), there's no 'cmd' involved.

When I see stuff like this, there is I believe without exception always something the user isn't saying about what they are doing, probably because they don't realize it's important information that is highly relevant.

If you are running a legacy inxi in a script that is in your PATH, there was an issue that would cause the script to go into an infinite loop (the script, mind you, NOT inxi), which will tend to kill the system. So that's my first guess.

this is why distros should NOT ship legacy inxi's, bug fixes fix bugs, upgrades add features, and fixes help users fix issues like their scripts going into infinite loops when starting inxi without other option handling in their script.

This is my guess, since the system info is running the same command, and since 'cmd <inxi>' doesn't mean anything, I mean, what is 'cmd'? that's the cause of the issue 10 to 1.

The second guess is that they have a core hardware bug/failure in their system that inxi is exposing, though that's unlikely since -b does less than -F, so my primary guess is it's a legacy inxi being run through another script that is in the user's $PATH.

I keep urging distros to start upgrading their frozen pool inxi's, and that's finally starting to happen, manjaro does it, epel does it, fedora does it, AntiX just did it, though they don't do it routinely, but the message doesn't get through. Debian, Ubuntu, OpenSuse don't do it, so tend to have long lingering issues that were fixed months/years ago. Updating inxi always helps and benefits both users and support people, and not upgrading it always doesn't help anyone.

There's no real reason not to upgrade all pools at the same time with latest inxi always, automatically, since inxi has no significant dependencies beyond Perl 5.008, which is like 15 years old, lol, and has no version based dependencies or recommends on anything, and does all its own internal testing for tools it may try to use. All that happens on frozen pool systems for new features that the frozen pool doesn't support, which is very rare, is that the feature just tells the user that it can't run.

[Pjotr]

I keep urging distros to start upgrading their frozen pool inxi's

And you may well be right. However, in the meantime you can help yourself:

Code: Select all

sudo rm -v /etc/inxi.conf

Code: Select all

sudo inxi -U

(you might need to run that last command twice, in order to update inxi's man pages as well)

Been doing that for years, and never encountered any problem because of it. Which is a strong point in favour of your effort, I suppose....

[h2-1]

If you ever encountered any issue upgrading inxi, installing current inxi, or pinxi, that would be a major bug. The only time new versions can cause issues is on ancient OS, when I forgot to test some features. For example I found and fixed a bug with Perl 5.008 that made 15 year old Debian sarge or etch have some failures, that was not an inxi issue, it was perl in debian having a small bug that was fixed quite soon after (it would have had to have been, it was a core language feature that failed randomly), so I had to alter the code to work around that very old perl bug. And sometimes I have slipped up and used a newer perl feature that 5.008 didn't support without realizing it.

Those are literally the only types of issues that could ever negatively impact an upgrade, and those are bugs and will always get fixed, even when it's not inxi's fault.

Once you get to Perl 5.010 and newer, there are zero issues.

I generally test latest pinxi/inxi now and then on a running Debian Lenny, which I think had Perl 5.010, maybe 5.012, I forget.

Perl was specifically selected because it does not break over years, and is by far the best, and fastest Practical Extraction and Reporting Language in existence, lol. inxi also works on Perl 7, the next perl after 5.032, that's been tested.

Now and then I've hit version based output differences of core tools, but it's always about very old versions causing some issues, never new ones, usually because I used a feature of the newer tool without realizing the ancient versions didn't support it, that's usually quite easy to fix. But again, these small glitches will only hit ancient operating systems that have never been upgraded, 2005, 2006.

I am heartened by the message very slowly getting through however, more distros are realizing you can always upgrade inxi in any repo and it will never have a negative impact, and will always benefit support people and users, so bit by bit. For this to hit debian and ubuntu, they'd have to sort of wake up and realize that not everything should be frozen in a frozen pool. They actually already know this, firefox for example is updated to current since that's the only way to have a secure browser, hopefully chromium is too.

But big end user oriented distros like mint, with their own repositories, could quite literally set up a small auto packaging script, and upgrade all their repos with current inxi automatically whenever inxi gets a new release, that would be a 'script once, run forever' type solution, there just are zero build dependencies by design beyond Perl. In theory I probably would have helped users more over time by writing this for the deb platforms and giving it to the pool maintainers, but that's a pain since you have to deal with stubborness and egos etc, which I don't generally find productive anymore.

[axisofevil]

What is pinxi?

[Pjotr]

What is pinxi?

You should google that yourself, mate....

But for once: pinxi is the development branch of inxi.

[ricardogroetaers]

However, in the meantime you can help yourself:

Code: Select all

sudo rm -v /etc/inxi.conf

Code: Select all

sudo inxi -U

(you might need to run that last command twice, in order to update inxi's man pages as well)

Been doing that for years, and never encountered any problem because of it. Which is a strong point in favour of your effort, I suppose....

Thanks for the tip (it works).

Observation:

You do not need to delete the file:
"/etc/inxi.conf"
Just rename it to any name (not forgetting the old name to revert).
Or change the line:
B_allow_update=false
for:
B_Allow_Update=true

The update (using "sudo inxi -U"), in fact, corresponds the last version available in the Developer's PPA for its version in use of Ubuntu/Mint.
In the case, version 3.3.06-1-1 of August 04, 2021 (valid even for discontinued versions of Ubuntu/Mint).

However this update is not registered in the package management software (APT, Synaptic, ...), which still "thinks" that the oldest version of Inxi, that of the official repository of the distro, is that it is installed.
If there is an update of the Inxi version of the official repository of the distro and this is installed, it will overwrite the update made with "sudo inxi -U".

[deepakdeshp]

Pl mark it solved as per my signature.

[h2-1]

The update (using "sudo inxi -U"), in fact, corresponds the last version available in the Developer's PPA for its version in use of Ubuntu/Mint.

That's not correct, 'the developer', aka, me, doesn't have a PPA, -U goes to github and gets the master branch inxi file and inxi.1 man page file using curl or wget and replaces your installed versions of those with the master versions. The PPA run by Unit193, the debian/ubuntu maintainer of the inxi package, sometimes has the latest version, but not always.

The master branch github inxi version likewise can be close to the development version pinxi, if the last inxi stable release was relatively recently and if no major changes have happened, but tends to drift away fairly soon as new features, fixes, etc, are handled in the development pinxi. Once enough have collected and are stable, or if there is a pressing bug fix that should go out quickly, the new inxi is released, and it starts all over again.

I don't know exactly since I've never used a debian/ubuntu deb packaged inxi, but it's possible if you remove the file, apt will just replace it if missing if a newer version is packaged, I know it won't alter it if you edit it unless the maintainers version is altered, which basically never happens. Changing ALLOW_UPDATE=true (B_ALLOW_UPDATE is legacy but will always keep working) is in general the better way to do it since that way you don't have to worry about the package replacing the file if it's removed or renamed, no reason to rename it since that's just clutter.

Now that I typed the above, I realized that inxi has failed to handle the convention of using .d directories to handle overwriting developer defaults, so next inxi will feature another location to look for, /etc/inxi.d/inxi.conf which is the way debian and other distros want that handled. I forgot to do that, just realized that is present exactly to avoid the entire question of what a package does to a config file. So I'll correct that.

Configuration items are case sensitive and always upper case, so B_allow_update or whatever would result in nothing changing.

[ricardogroetaers]

The update (using "sudo inxi -U"), in fact, corresponds the last version available in the Developer's PPA for its version in use of Ubuntu/Mint.

That's not correct, 'the developer', aka, me, doesn't have a PPA, -U goes to github and gets the master branch inxi file and inxi.1 man page file .....

I ask to consider that I do not master the English language.
The text is translated by Google Translate.
That way, the English text can present meaning different from the original text in Portuguese-BR.

Trying to explain with other words:
- The mechanism by which the "sudo inxi -U" command works and from where it lowers things, I do not know.
- The developer of Inxi has a PPA, observe the figure.
- The Linux Mint packet installer for some reason I do not know, refuses to install the ".deb" file downloaded from that PPA.
- If we try to uninstall the "inxi" by Synaptic, half of the Mint system goes along.
- The concrete fact is that the update of "Inxi" by the "sudo inxi -U" command, installs the most current version, exactly that version in the developer's PPA.
- The concrete fact is that Synaptic does not detect this update (above) and thinks that the old version of "Inxi" is still installed.

[h2-1]

Once again, speaking simply, I am the developer, and the developer has no PPA, so there is no developer PPA. The debian/ubuntu package maintainer (who is not an inxi developer, though he does make good feature suggestions sometimes) has a PPA, which is sometimes with the latest inxi version, and sometimes not. inxi -U never updates from PPA or apt, it always updates from github master using wget or curl. inxi -U is the only way to be sure you are on the latest master branch inxi version. pinxi then pinxi -U is the only way to be sure you are the latest features/bug fix version, but pinxi confuses people so let's ignore that one.

-U is the native inxi method of updating inxi, same for pinxi, both updates themselves from github branch/master using wget/curl. No PPA is ever involved in that process, ever.

PPA inxi installs I've never done or looked at, in general, you want to avoid mixing ubuntu and debian packages, which means debian systems should in general not use ppa's from ubuntu, and ubuntu should in general not use debian package pools to install packages from because the results can be bad. A simple package like inxi should never create any issue, unless there is a packaging bug, but that's a silly way to update inxi, it often is an old inxi, and doesn't help resolve the update issue.

[h2-1]

pinxi now supports /etc/pinxi.d/pinxi.conf override, which is of course useless since pinxi should never be packaged, but that means next inxi, 3.3.07, will support /etc/inxi.d/inxi.conf override, which will be a nice way to not touch distro files at all, and just override the configs and never have them changed by package changes. Should have thought of that years ago, better late than never, oh well. Another one it would have been nice to have in the initial 3.0.0 but can't think of everything.

Note that one problem with forgetting to add features like this earlier is that it only becomes something support people can tell users, that is:

Code: Select all

echo 'ALLOW_UPDATE=true' > /etc/inxi.d/inxi.conf 

after everyone is on 3.3.07, which won't happen for years in most cases for most frozen pool distros, but better late than never.

[ricardogroetaers]

H2-1,

Thank you for the explanation.
I ask you to consider that with these names, which are not real, they are nicknames, it is difficult to distinguish who the developer is and who is the PPA maintainer. Even more when everything is in a language I do not know.

I have reached the supposed developer website for an existing link on Synaptic. And I arrived at the PPA for a link (or similar) that I found in the supposed website of the developer.

Thanks for developing Inxi and provides it for us.
Inxi can be perfected, but that flees the scope of this topic.

[axisofevil]

I got the following:-

Code: Select all

sudo inxi -U
Error 20: Option: U has been disabled by the inxi distribution maintainer.

[SMG]

I got the following:-

Code: Select all

sudo inxi -U
Error 20: Option: U has been disabled by the inxi distribution maintainer.

You will currently need to follow the steps in this post to update inxi to the latest version.

[h2-1]

For those who do not speak English natively, it's probably useful to understand the differences in the terms used.

A 'developer' is the person who develops the software. They are the software author, though they could also be testers, debuggers, etc, but usually they are the ones that write the code. The linux kernel project for example normally has a thousand or so developers active for each release.

A 'maintainer' is a person who maintains a package for a distribution, usually, though in less common cases, a maintainer might be maintaining software but not really developing it, that is, maybe they are just applying bug fixes etc, so it's easy to see how that could get confusing. A package maintainer could also be the developer, for example, I am the maintainer of the TCE packaged inxi for tiny core linux, and I am also the developer of inxi. I am a terrible maintainer, lol, because I forget to update the package all the time.

A distribution in general refers to a distribution of a collection of packages, the normal way linux distros work. It could also in some cases be a distribution of code that is then compiled by the end user, but it's still a distribution of packaged code at some point, more or less. So a maintainer of a package maintains the package for the distribution package pool.

Making it more confusing, non actively developed software can go into 'maintenance mode', which means, no new features are being created, and only updates required to make it work are being applied. I have several projects that are in maintenance mode now. They are not dead, but they are not being actively developed.

But a developer is always the person who develops, codes, the software. A package maintainer is always the person who maintains the package of that software. Unit193 for example is the maintainer of Debian and Ubuntu inxi packages, and also runs his own PPA for other packages he maintains, including inxi. Some groups will create a PPA for the software they develop, but normally other people will package it.

Sometimes projects will release their own snap or flatpak or appimage packages, which makes them then both the developers and maintainers of those packages.

English can be difficult, lol, it has a lot of words.

[h2-1]

I have reached the supposed developer website for an existing link on Synaptic. And I arrived at the PPA for a link (or similar) that I found in the supposed website of the developer.

That would be a packaging or synaptic error, since the website of the developer is either https://smxi.org or https://github.com/smxi/inxi
The PPA is probably unit193's, and he's the package maintainer.

[ricardogroetaers]

Perfect.
The existing link in Synaptic is:
https://smxi.org/docs/inxi.htm

And on this page, in the "Installation" item there is a path to the PPA shown in the figure above, which is from "UNIT193".