Siduction Forum

Siduction Forum => Scripting & Kernelhacking => Scripting & Kernelhacking (EN) => Topic started by: h2 on 2014/03/18, 04:30:11

Title: inxi bugs or failures - please report
Post by: h2 on 2014/03/18, 04:30:11
i'm doing a big cleanup of inxi and have found a lot of failures, changed paths, changed or new syntax for things, I'm fixing them as I go along, but let me know if you have any data where something fails to get reported, for example, before inxi 2.1.4, lspci output for graphics cards that used: 3D controller OR Display Controller were not getting handled so those cards would go non recognized.

I found these failures by chance while checking some inxi stuff on the web, and also found and fixed some other bugs, like -d not reporting the optical device name/brand and rev number. That should now be fixed, the /sys/ path had changed, easy to fix with xiin output.

So if you see something fail, get missed, etc, let me know and I'll get it updated.

For those who care about such things, inxi help now wraps dynamically to fit the size of the terminal, takes a bit more time to show help, but it will fit whatever size terminal you use, no matter how narrow. Max width is a global set at 115 columns, but you can change that in /etc/inxi.conf if you want.

I'm aware of certain drivers reporting as FAILED when they aren't, but I believe that is an issue in Xorg.0.log, but if you have a case where Xorg.0.log reports successful load after it reports fail, then post the log and I should be able to resolve that issue. I believe it's a bug however somewhere that is not inxi, but it could also be some change in nourveau, which is where I see the issue most.

Title: Re: inxi bugs or failures - please report
Post by: vilde on 2014/03/18, 16:45:46
I didn't know that inxi could give so much information, I have only used -3 before. Now I checked the -help and found out :)

Didn't know that inxi was from h2 either, long time since I heard anything from you. I have no info about bugs and failures but anyway tanks for inxi h2
Title: Re: inxi bugs or failures - please report
Post by: ayla on 2014/03/24, 11:34:09
update to 2.1.7 came in today, checked the manpage and found option -v7.

Simply nice.

Need a chip ID? Internal or external IP? The uuid/label/size of a certain device? Drivers in use? .....

No need to search through /dev, /etc or remember a lot of commands, just ask inxi.
Detailed, fine ordered overview.

Thanks for that
ayla
Title: Re: inxi bugs or failures - please report
Post by: mylo on 2014/03/25, 22:29:49
h2 is back! Did not know up to now that he is behind inxi.
Thansk for that tool!
Title: Re: inxi bugs or failures - please report
Post by: h2 on 2014/03/25, 23:31:36
inxi 2.1.10 now features more dynamic line wraps, with fixes for some of the ones that didn't work right. -C works better now for example with > 2 cpu core speeds listed, though the single core speed is not wrapping fully et at very narrow widths, ie, 80 columns.

--recommends and -c 94-99, the color selector tool, now wrap well.

Some error messages for missing data etc is now working better for 80 column widths.

And of course, what everyone has been waiting for, inxi now supports showing supybot/limnoria/gribble version information if inxi is started via irc client with shell command, but don't ask me how to do it, all I know is it works. I guess that lets you get data from the host server system or something, not sure, someone wanted it, so there it is.

-G wraps a lot better now too. -D -d -N and -A still aren't fully wrapping. -p/-P now I think should wrap ok unless the mount point is a very long path, but it's too hard to get those wraps perfect so I'm calling it good enough. It's all a lot better than it was so I"m not worried about perfection, but each line takes a lot of testing to get to wrap right with all data combinations.

Sometimes there may appear to be a blank line, but if you highlight the console you'll see that actually it was a forced wrap of a trailing space, which I am having a very hard time getting rid of internally, but that issue  usually only appears at exactly 80 columns, if the line is 79 columns wide including the trailing space/character.
Title: Re: inxi bugs or failures - please report
Post by: melmarker on 2014/03/26, 18:03:27
2.1.10, revision 2242 is now in the repo - thanks h2
Title: Re: inxi bugs or failures - please report
Post by: h2 on 2014/03/28, 00:21:19
And with 2.1.12 I think I'll have to slow it way down. It fixes another line wrapping issue, -D, which is now ok.

Also fixed is zfs raid issue on some systems, but that's mostly going to be bsd so probably doesn't matter to linux users.

Also fixed is an old bug where if you use -c 0 and have a FAILED driver in G your console turns all red, forgot to unset the red variable.

Title: Re: inxi bugs or failures - please report
Post by: cryptosteve on 2014/03/28, 18:50:18
Thansk for that tool!

Definitely +1  ;D
Title: Re: inxi bugs or failures - please report
Post by: melmarker on 2014/03/30, 03:00:30
uploaded 2.1.12
Title: Re: inxi bugs or failures - please report
Post by: dibl on 2014/03/30, 22:13:46
Very nice work -- thanks for this, h2!
Title: Re: inxi bugs or failures - please report
Post by: h2 on 2014/04/01, 23:09:30
I think this is pretty much it for the line wrapping, at least this is as much as I will do:

2.1.15 now fixes wraps on -d, -n,-i,-N, and -A

There are some negatives to the tight wrapping at 80 columns, because if you have multiple cards or whatever one line may wrap and another not depending on their lengths, but that's the cost of doing true dynamic line wraps.

Except for bug fixes, this is now as done as it's going to get I hope anyway.

Things should be wrapping well down to 80 columns now, with some exceptions where the data is just too long, for example long card names, or certain data sets where the total for a second line still is greater than 80 columns, but it's crazy to do more in my opinion. It could be well argued that it was already crazy to do this much, but that's life, we have to waste our time here on earth somehow....
Title: Re: inxi bugs or failures - please report
Post by: h2 on 2014/04/03, 21:34:10
And with 2.1.17 I can see the end in sight. This introduces the obvious option of -y <number >= 80> which lets you override on a one time basis all width settings. Useful for internal debugger use, that way I can set the desired line width in inxi output, and I can test the widths easily without physically resizing my terminal, and people can spit out any width they want as long as it is greater than 80. Width is in columns, that's how console/terminal width is set. IRC is also overridden, which can be useful if you want to send a narrow width to make sure the stuff doesn't wrap wrong.

Also updated man page and cleaned it up.

Usually when I cleanup the man page, it means the main project is pretty much close to done, the last step usually is updating the wiki pages if changes are required.

-y has some restrictions, it won't work with long options like --help or --recommends, but short ones are all fine, like -h.

-y also only works on the line version of inxi, not the short output version of: inxi
which always just fits the screen width no matter what. Put -y first on the list of options to make sure it works as intended, though usually it's fine, except for -h and -c stuff, where the script exits after running that option.

Now off to do real work, heh.
Title: Re: inxi bugs or failures - please report
Post by: der_bud on 2014/04/04, 14:11:37
Very nice work -- thanks for this, h2!
+1
No bug or failure, don't know if this is the right place for suggestions. Inxi gives so many useful information, would be nice to see in its output where grub currently is installed.
Sometimes when new grub versions are updated one gets a debconf dialog to choose device or partition, obviously one should use the current location again but on some multidisk/multiboot-setups it is hard to remember what the current setting was. Last time I probed my devices with
Code: [Select]
dd bs=512 count=1 if=/dev/sda 2>/dev/null | strings
that gives amongst others the word 'GRUB' as output for the device if grub is found. I am sure you could find a way to let inxi say something like "Grub currently on: /dev/sdX" (and hopefully you do not run out of letters :) for options).
Title: Re: inxi bugs or failures - please report
Post by: h2 on 2014/04/04, 20:23:57
With a big groan, I've now completed all the lines, 2.1.18

I also fixed a weird decision I'd made a long time ago to not show the /dev - remote location of the partitions unless labels or uuid was used.

I needed to get this finished so I can move on to actual work projects, so now it's pretty much completely done.

Note that -p/-P, -D, and -o, now show ID-<number>: instead of ID: or 1: id:, ie, they are all the same now. I find it easier to read if they are numbered like that with a lot of partitions or drives.

Try 2.1.18 and see, all the lines more or less will wrap right down to 80 columns, except sometimes with -p and a few times with -S when the kernel name is super long. Maybe -R too isn't right in some cases, but I don't have access to an md-raid system at the moment to test that.

Further fixes are too hard in terms of the length being totally perfect so I call this done.

dd bs=512 count=1 if=/dev/sda 2>/dev/null | strings

requires root, I'm usually not very fond of implementing core features that require root to run, that's why -m memory is not started yet for example.

I agree it's a nice to have feature but it's not as easy as you think, grub can be on a partition boot sector, and I have no idea about EFI stuff and grub, as usual with ideas related to computers and linux in particular, the actual implementation where it actually works for almost all users would take probably 100 times longer than it takes to run a simple one liner on a system where all the data is known. At least 100 times I'd guess.
Title: Re: inxi bugs or failures - please report
Post by: melmarker on 2014/04/04, 21:54:01
inxi in our repos is now 2.1.18 in our repos, thanks h2

And now to something completly different: h2, is it possible to forbid inxi -h output for irc use? (to be true - this is disappointing :) )
Title: Re: inxi bugs or failures - please report
Post by: devil on 2014/04/04, 21:57:40
just to explain: a quite thick user just fired off inxi -h in our channel :)


greetz
devil
Title: Re: inxi bugs or failures - please report
Post by: h2 on 2014/04/04, 22:11:31
All non line output is not allowed in IRC, it's an absolute internal override. Except -c 94-99, that has to be allowed so you can pick your irc colors. This is in Konversation.
Code: [Select]
/inxi -h
[13:07] <h2> Sorry, you can't run the help option in an IRC client.
/inxi --help
[13:07] <h2> Sorry, you can't run the help option in an IRC client.
/inxi -H
[13:07] <h2> Sorry, you can't run the help option in an IRC client.

inxi --version is truncated:
/inxi -V
[13:08] <h2> inxi 2.1.18-00 (2014-04-04)
/inxi --version
[13:09] <h2> inxi 2.1.18-00 (2014-04-04)

/inxi --recommends
[13:10] <h2> Sorry, you can't run this option in an IRC client.
Failure to exit with error, or to truncate --version, is a bug.

If it failed, you have to provide all relevant data about IRC client etc, inxi always detects if it's running in shell or irc, that sets B_IRC global, so the only way help could be triggered in irc is if the irc client was not an irc client, or thinks it's tty.
Code: [Select]
if tty &>/dev/null;then B_IRC='false';else B_IRC='true';fi ; echo $B_IRCthat's the test, verbatim.

If they pasted in --help/-h there's nothing I can do about that of course.

In CLI IRC, irssi:
Code: [Select]
/exec -o inxi -h
13:15 <@h2-irssi> Sorry, you can't run the help option in an IRC client.
13:15 -!- Irssi: process 0 (inxi -h) terminated with return code 1
Title: Re: inxi bugs or failures - please report
Post by: melmarker on 2014/04/05, 00:45:41
h2, sorry - my fault. i forget about drag and drop :D
Title: Re: inxi bugs or failures - please report
Post by: h2 on 2014/04/05, 07:45:09
tiny bug fix, not warranting a version number change, if the partitions listed in -P are less than those listed in -p, it showed the wrong number in the ID-<number> identifier. That's fixed now.
Title: Re: inxi bugs or failures - please report
Post by: h2 on 2014/04/05, 20:43:56
By the way, re grub detection, once you expand the use case to cover everything possible, here's what is actually roughly required:

Detect all bootlloaders, grub, lilo, and whatever else is used on unix/linux.

handle uefi, which requires all permutations of that possible setup and data sets.

locate root partition, check that partition for boot loader.

locate drive id, like /dev/sda, query that. Query all other drives located to discover all other boot loader instances.

Since the main bootloader can be on another drive, and boot the partition either using the partition boot, or a direct connection to the kernel image thing from the primary grub/lilo whatever, the possibities are somewhat staggering, and would require learning exactly how all types of uefi boot implementations can be detected and handled, all types of boot loaders, all partition and main boot sectors, etc. Scary stuff. My experience with inxi is that once you expand the features to cover most possible scenarios, you're talking about a minimum of 2 weeks of research and development, followed by at least 2 more weeks of fringe case handling and issues. In other words, it would be a major feature, not a trivial thing to do, so I'll wait for a patch for the get_bootloader_data function, I'll handle the print bootloader stuff because it's very picky and hard to understand.

Patch would need to include all possible scenarios, raid boot, uefi, all boot loaders, multi disk systems, systems with multiple instances of bootloaders, etc. I suggest filing an issue report on inxi wiki, it will stay up a long time but might at some date be done if I feel the need to actually have that data, just as the ram issue report stays until it gets done one day.

<update> I created this issue on the wiki, but don't hold your breath, it could be years, or never, but it is an idea so might as well put it somewhere it will remind me now and then.
Title: Re: inxi bugs or failures - please report
Post by: melmarker on 2014/04/05, 22:42:11
new minor uploaded, 2.1.18 rev 2197
Title: Re: inxi bugs or failures - please report
Post by: h2 on 2014/04/05, 23:24:45
http://code.google.com/p/inxi/issues/detail?id=56

there's the inxi wiki bootloader issue / enhancement request.

Note that low priority 'enhancement' stuff, that is, new features, are low because they require root to run them.

Anything that can get the data without root will make the issue bump up, or that shows a better way to do it.

Since I don't have an uefi system to test on, I wouldn't really think much on this until I can collect some 20 to 40 user data sets to see what the possible range of data is. But the requiring root is a pretty major negative for inxi. It has a few things that usually need inxi, like hddtemp and file for unmounted partitions, but you can also use sudo configuration to get those working without root, plus they are not core features, just extra data on a line item.
Title: Re: inxi bugs or failures - please report
Post by: h2 on 2014/04/06, 23:43:11
sad to say, I made yet another mistake on the -p/-P ID-<number> count, forcing the release of 2.1.19 :(

Brain dyslexia, logic dyslexia, call it what you will, but now it's right.

Line wrapping dynamically makes the print out logic a lot more complicated, but i think it's more or less come together now.

Now all possible output is done right. The ID- in -D and -o however were always right because that is much simpler in terms of print logic.

I figured it would take a lot of versions to get 2.1 stable, given the number of core changes in output it involves, but hopefully this is now it except for non related issue reports etc.
Title: Re: inxi bugs or failures - please report
Post by: h2 on 2014/04/14, 00:00:36
Looks like 2.1.20 is the more or less stable, includes a few small line wrap fixes (single core cpu ), a fix for new ARM cpu reporting failures, and not much else. 2.1.19 had most of the real final fixes, and with that, and having now updated the inxi wiki and irc factoids and smxi.org inxi install page (including now suggestion to use siduction repos for more current inxi, or the actual inxi packager for ubuntu/debian, Unit193's repo).

Usually when I update docs like this it means it's done, so I'm calling this phase done except for bug and issue fixes.
Title: Re: inxi bugs or failures - disk utilization error
Post by: dibl on 2014/04/27, 16:17:34
There is a bug that I have been meaning to report for some time.  It may, or may not be related to the use of a BTRFS filesystem, or perhaps (more likely) it is related to the fact that this BTRFS filesystem is made directly on the devices, and not on conventional disk partitions.  In the inxi output below, you can see that it reports 2.2% disk usage, but in the df and btrfs outputs, you can see that I am using about half of my total capacity.


Code: [Select]
root@imerabox:/# inxi -v3
System:    Host: imerabox Kernel: 3.15-rc2-siduction-amd64 x86_64 (64 bit gcc: 4.8.2)
           Desktop: KDE 4.12.4 (Qt 4.8.6) Distro: aptosid 2011-02 Ἡμέρα - kde-lite - (201107131633)
Machine:   Mobo: ASUSTeK model: P6X58D-E v: Rev 1.xx serial: 107017670002065
           Bios: American Megatrends v: 0803 date: 08/06/2012
CPU:       Quad core Intel Core i7 CPU 950 (-HT-MCP-) cache: 8192 KB
           flags: (lm nx sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx) bmips: 25174
           Clock Speeds: 1: 3145 MHz 2: 3145 MHz 3: 3145 MHz 4: 3145 MHz 5: 3145 MHz 6: 3145 MHz 7: 3145 MHz
           8: 3145 MHz
Graphics:  Card: NVIDIA GF100 [GeForce GTX 480] bus-ID: 05:00.0
           Display Server: X.org 1.15.1 driver: nvidia tty size: 157x59 Advanced Data: N/A for root
Network:   Card: Marvell 88E8056 PCI-E Gigabit Ethernet Controller
           driver: sky2 v: 1.30 port: d800 bus-ID: 06:00.0
           IF: eth0 state: up speed: 100 Mbps duplex: full mac: 20:cf:30:5c:41:1d
Drives:    HDD Total Size: 2136.5GB (2.2% used) model: WDC_WD1002FAEX
           model: OCZ model: OCZ
           model: WDC_WD1002FAEX model: KINGSTON_SS100S2
Info:      Processes: 335 Uptime: 17:37 Memory: 2781.8/5965.7MB Init: systemd runlevel: 5 Gcc sys: 4.8.2
           Client: Shell (bash 4.3.111) inxi: 2.1.20

root@imerabox:/# df -h
Filesystem                                                       Size  Used Avail Use% Mounted on
/dev/sda1                                                         19G   14G  4.1G  78% /
udev                                                              10M     0   10M   0% /dev
tmpfs                                                            1.2G  896K  1.2G   1% /run
tmpfs                                                            3.0G  2.7M  3.0G   1% /dev/shm
tmpfs                                                            3.0G     0  3.0G   0% /sys/fs/cgroup
none                                                             3.0G     0  3.0G   0% /var/spool
none                                                             3.0G  372M  2.6G  13% /var/tmp
none                                                             3.0G  256K  3.0G   1% /tmp
none                                                             3.0G  4.4M  3.0G   1% /var/log
tmpfs                                                            5.0M     0  5.0M   0% /run/lock
tmpfs                                                            100M   16M   85M  16% /run/user
/dev/sdb1                                                         55G   52M   55G   1% /mnt/REVODATA
/dev/sda2                                                         37G   31G  5.9G  84% /mnt/SDA2
/dev/sde1                                                        495M  162M  308M  35% /boot
/dev/sdc                                                         1.9T  951G  910G  52% /mnt/DATA
/tmp/vmware-don-1983260093/564d8611-3ab6-159f-7365-0de607e1ca06  1.3G     0  1.3G   0% /tmp/vmware-don-1983260093/564d8611-3ab6-159f-7365-0de607e1ca06

root@imerabox:/# btrfs fi df /mnt/DATA
Data, RAID0: total=1.56TiB, used=947.24GiB
Data, single: total=8.00MiB, used=6.28MiB
System, RAID1: total=8.00MiB, used=116.00KiB
System, single: total=4.00MiB, used=0.00
Metadata, RAID1: total=3.00GiB, used=1.65GiB
Metadata, single: total=8.00MiB, used=0.00
unknown, single: total=512.00MiB, used=0.00
root@imerabox:/#
Title: Re: inxi bugs or failures - please report
Post by: h2 on 2014/04/27, 19:42:53
Yes, I actually fixed another part of this bug in 2.1.21, failure to show USB because the device partition is /dev/sdc not /dev/sdc1.

I was actually wondering if that only applied to external usb/firewire partitions, vfat shows the same, by the way on a single partition external drive, or also to internal.

Unfortunately fixing this bug is very hard, because inxi expects partitions to end in a number identifier, that's how it counts the partitions vs actual disks, but as we can see, for some reason btrfs does not actually show that as expected.

It's odd to me when things stray from long standing conventions, makes me think that some people just enjoy changing things just to ensure they have new things to learn and change.

I'll have to look into this, fixing it will not be easy because that requires that inxi both not count and count /dev/sdx sizes in df, quite a challenge.

There may be an easy fix, I'll check.

The USB / Firewire side of this issue is handled however, I wonder if my data samples collected show this.

Please do a: inxi -xx@14
so I have a full data set for your system hardware, though this particular feature is difficult to emulate because it requires feeding in several different data sources at once.
Title: Re: inxi bugs or failures - please report
Post by: dibl on 2014/04/27, 20:37:02
Done.


BTRFS allows for a multi-device installation, using the raw devices -- no partition table needed.  It is a really nice feature, because it combines data striping (RAID 0) and metadata mirroring (RAID 1) on a pair of drives:


Code: [Select]
root@imerabox:/# btrfs fi show /mnt/DATA
Label: none  uuid: 9025bea6-b615-470a-8759-df1b13f63b52
        Total devices 2 FS bytes used 948.87GiB
        devid    1 size 931.51GiB used 804.03GiB path /dev/sdc
        devid    2 size 931.51GiB used 804.01GiB path /dev/sdd


Btrfs v3.14.1


Also note that the BTRFS filesystem can be mounted and queried using only/any one of the devices.  That is why the "df" output I posted earlier only mentions /dev/sdc, even though /dev/sdd is also in the BTRFS filesystem.  I would suppose that fact would add a special extra bit of enjoyment to your scripting challenge.   ;D 
Title: Re: inxi bugs or failures - please report
Post by: timc on 2014/04/27, 21:24:46
I don't know whether this is a bug, but my system currently has three network cards and inxi -Nn is only showing two of them - the two that are not actually being used.

Code: [Select]
inxi -Nn
Network:   Card-1: Ralink RT3062 Wireless 802.11n 2T/2R
           IF: N/A state: N/A mac: N/A
           Card-2: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller driver: r8169
           IF: eth0 state: up speed: 100 Mbps duplex: full mac: 50:e5:49:3a:45:05

The card that is being used is an RTL8192DU USB device for wlan1:

Code: [Select]
lsusb
Bus 001 Device 003: ID 050d:110a Belkin Components

lsmod|grep 8192
8192du                438547  0
usbcore               134168  7 usblp,usb_storage,ehci_hcd,ehci_pci,usbhid,8192du,xhci_hcd

ip addr show
3: wlan1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether ec:1a:59:60:55:b8 brd ff:ff:ff:ff:ff:ff
    inet 10.0.0.13/24 brd 10.255.255.255 scope global wlan1
       valid_lft forever preferred_lft forever
    inet6 fe80::ee1a:59ff:fe60:55b8/64 scope link
       valid_lft forever preferred_lft forever


Tim
Title: Re: inxi bugs or failures - please report
Post by: h2 on 2014/04/27, 22:08:54
Please do not grep your output when posting it for inxi debugging, that does not help me.

I need the full output always to make sure something odd is not happening.

Usually the reason a card does not show is because the device uses something to identify it that inxi has not seen before.
Title: Re: inxi bugs or failures - please report
Post by: h2 on 2014/04/27, 22:13:30
Bus 001 Device 003: ID 050d:110a Belkin Components

You can see why it doesn't see it there, there is nothing to identify it in the usb description, Belkin is a company that makes lots of things, so you can't use that to say it's a wifi card.

the btrfs issue is or should be resolved in inxi 2.1.22

The belkin failure can't be resolved until there's something or some way to identify the device as wifi and not a mouse or keyboard, heh.

I can't really do anything like id detection because that would require all the ids from all companies, that are wifi/nic devices, and that's not a road I am going to go down, I already do it in sgfxi and it's not fun.

So I'd file a bug report with wherever creates the string for lsusb, it should have some indication of what it is in that string, almost all do. Sometimes OEM's literally just don't fill out the field in the data thing they provide to whoever handles this stuff.

This is the list inxi uses now:
Code: [Select]
USB_NETWORK_SEARCH="Wi-Fi.*Adapter|Wireless.*Adapter|Ethernet.*Adapter|WLAN.*Adapter|Network.*Adapter|802\.11|Atheros|Atmel|D-Link.*Adapter|D-Link.*Wireless|Linksys|Netgea|Ralink|Realtek.*Network|Realtek.*Wireless|Realtek.*WLAN|Belkin.*Wireless|Belkin.*WLAN|Belkin.*Network"]
Just to be clear, inxi needs to know which device is which, it can't do random guesses, so it has to construct a device list, find the eth /wlan type numbers, then you can see the actual IF data, you can run: inxi -n or inxi -i and it will I think show the IF data for each device, not positive in cases where the initial data was not complete, try it and see.

However, there is no way for inxi to sythesize non existent device identification data in usb, it might be possible to get it from /sys instead, for example, but it's never easy working directly with /sys.

If you do an inxi -xx@ 14 I may be able to see.

In general, never file missing data reports without also supplying the inxi -xx@14 debugger data set, otherwise it takes me too long to get all the bits of data from you piece by piece.
Title: Re: inxi bugs or failures - please report
Post by: h2 on 2014/04/27, 22:24:11
Here's an interesting one you can play with too, this uses the relatively new --total option in df, which gives oddly altering results:

Code: [Select]
# first see the actual output
df  --total  -P -T --exclude-type=aufs --exclude-type=devfs --exclude-type=devtmpfs  \
--exclude-type=fdescfs --exclude-type=iso9660 --exclude-type=linprocfs --exclude-type=procfs \
--exclude-type=squashfs --exclude-type=sysfs --exclude-type=tmpfs --exclude-type=unionfs

# then add the partition used blocks directly
 df  -P -T --exclude-type=aufs --exclude-type=devfs --exclude-type=devtmpfs  \
 --exclude-type=fdescfs --exclude-type=iso9660 --exclude-type=linprocfs --exclude-type=procfs \
 --exclude-type=squashfs --exclude-type=sysfs --exclude-type=tmpfs --exclude-type=unionfs | \
 awk 'BEGIN {total=0} {total = total + $4 }END {print total}'

 result:
 614562236

# then do it  --total, using only --total output
df  --total  -P -T --exclude-type=aufs --exclude-type=devfs --exclude-type=devtmpfs  \
--exclude-type=fdescfs --exclude-type=iso9660 --exclude-type=linprocfs --exclude-type=procfs \
--exclude-type=squashfs --exclude-type=sysfs --exclude-type=tmpfs --exclude-type=unionfs | \
awk 'BEGIN {total=0} /^total/ {total = total + $4 }END {print total}'

result:
614562228

# then do it with --total but just counting the disk blocks and ignoring the total
 df  --total  -P -T --exclude-type=aufs --exclude-type=devfs --exclude-type=devtmpfs  \
 --exclude-type=fdescfs --exclude-type=iso9660 --exclude-type=linprocfs \
 --exclude-type=procfs --exclude-type=squashfs --exclude-type=sysfs --exclude-type=tmpfs \
 --exclude-type=unionfs | awk 'BEGIN {total=0} !/total/ {total = total + $4 }END {print total}'

result:
614562208

These 3 should all give the same result in theory, but they don't. Using --total gave me a bit higher disk usage percentage for the total than adding up the individual percentages. Odd what I find with inxi and the system.

On my system, the difference is 77.7% disk used using --total vs 76.2% by adding up the individual used blocks.

Very strange. Anyway, the btrfs was an easy fix, I just made the regex sd[a-z][0-9]* (0 or more numbers ending it) instead of sd[a-z][0-9]+ (one or more numbers ending it)
Title: Re: inxi bugs or failures - please report
Post by: dibl on 2014/04/27, 22:51:59
Interesting.  If I'm reading my outputs correctly, on my rig the difference between the highest and the lowest result is only 8 bytes:


Code: [Select]
don@imerabox:~$ df  --total  -P -T --exclude-type=aufs --exclude-type=devfs --exclude-type=devtmpfs  \
> --exclude-type=fdescfs --exclude-type=iso9660 --exclude-type=linprocfs --exclude-type=procfs \
> --exclude-type=squashfs --exclude-type=sysfs --exclude-type=tmpfs --exclude-type=unionfs
Filesystem     Type  1024-blocks       Used  Available Capacity Mounted on
/dev/sda1      ext4     19478204   14356724    4109000      78% /
/dev/sdb1      ext4     57562364      53080   57492900       1% /mnt/REVODATA
/dev/sda2      ext4     37954208   31853332    6084492      84% /mnt/SDA2
/dev/sde1      ext2       506724     165606     314955      35% /boot
/dev/sdc       btrfs  1953525168  996694656  953952792      52% /mnt/DATA
total          -      2069026668 1043123398 1021954139      51% -


don@imerabox:~$ df  -P -T --exclude-type=aufs --exclude-type=devfs --exclude-type=devtmpfs  \
>  --exclude-type=fdescfs --exclude-type=iso9660 --exclude-type=linprocfs --exclude-type=procfs \
>  --exclude-type=squashfs --exclude-type=sysfs --exclude-type=tmpfs --exclude-type=unionfs | \
>  awk 'BEGIN {total=0} {total = total + $4 }END {print total}'
1043123394


don@imerabox:~$ df  --total  -P -T --exclude-type=aufs --exclude-type=devfs --exclude-type=devtmpfs  \
> --exclude-type=fdescfs --exclude-type=iso9660 --exclude-type=linprocfs --exclude-type=procfs \
> --exclude-type=squashfs --exclude-type=sysfs --exclude-type=tmpfs --exclude-type=unionfs | \
> awk 'BEGIN {total=0} /^total/ {total = total + $4 }END {print total}'
1043123402


don@imerabox:~$ df  --total  -P -T --exclude-type=aufs --exclude-type=devfs --exclude-type=devtmpfs  \
>  --exclude-type=fdescfs --exclude-type=iso9660 --exclude-type=linprocfs \
>  --exclude-type=procfs --exclude-type=squashfs --exclude-type=sysfs --exclude-type=tmpfs \
>  --exclude-type=unionfs | awk 'BEGIN {total=0} !/total/ {total = total + $4 }END {print total}'
1043123398


I call that "close enough"!
Title: Re: inxi bugs or failures - please report
Post by: h2 on 2014/04/27, 22:56:44
Using the total flag seems to change the blocks used of my root partition

It's not bytes, it's blocks, a block is 1024 bits I believe. No, sorry, it's 1024 Bytes, 1kB.

# without --total
/dev/sda1 ext3    12479556  12015896    335544      98% /

# with --total
/dev/sda1 ext3    12479556  12015856    335584      98% /

that looks very much like a bug to me, all my other partition data are the same with --total/no --total.

However, a 40kB difference should not account for a greater than 1% difference in size used on 800 gB
Title: Re: inxi bugs or failures - please report
Post by: dibl on 2014/04/27, 23:09:37
Well, duh, it says "blocks" right there in the table.  So I have 8 blocks variance from the highest output to the lowest output -- 8kB.  That is miniscule out of 1 GiB, but still the math should be the same.


Hmmm, I wonder if there's something about ext3 versus ext4?  I would not expect that, but I see your filesystem is ext3.  Also, what about swap -- would it be counted as "used" if something is swapped out, but "unused" if the swap space is unused?
Title: Re: inxi bugs or failures - please report
Post by: h2 on 2014/04/27, 23:17:31
good point re swap, I forgot all about that part.

Technically I'd call your entire disk space for swap used since it's not available to you.

The partition data shows the swap size/percent, but i forgot all about the swap partition for the total size used.

For these purposes I think I will call swap partitions used, since you can't use them for anything else.
Title: Re: inxi bugs or failures - please report
Post by: h2 on 2014/04/27, 23:45:58
Ok, now 2.1.22 includes swap space as used in -D.

Updated -h and man page to indicate this fact.

I don't know why I never thought of swap in the total, but it's clearly not space you have available to use on the disk, therefore it's used.

Makes sense to me. The help menu will further clarify, in terms of raid/swap percentages. Remember that raid will make percentage used wrong since inxi doesn't know about raid in the calculation, to get around that is complicated, means getting all raid data first, then spitting out the /dev id on each disk in the arrays, and faking it slightly and ignoring the size of other elements of the disk array when doing used/size calcs. Too hard for me at this point.

Percent used has always been tricky because of unmounted partitions, so it's never accurate unless all your partitions are mounted and no RAID disks are present. Now it should be a bit more accurate though.

I cannot see where the really big difference in used percentages comes between --total and regular counting up used blocks, unless there is an internal Gawk bug with counting or math.
Title: Re: inxi bugs or failures - please report
Post by: h2 on 2014/04/28, 01:02:41
It turns out there was a bug in inxi, the disk space used was not including /dev/disk... items from df, which is why I was getting such large differences using --total and old method.

2.1.23 fixes this bug, I made a new release number because I only just now fixed the bug.

Weird how such bugs crop  up, it's because linux/bsd is always changing, you can never count on any data to remain constant.
Title: Re: inxi bugs or failures - please report
Post by: dibl on 2014/04/28, 01:11:34
Nice work h2 -- you are the maestro!
Title: Re: inxi bugs or failures - please report
Post by: h2 on 2014/04/28, 01:12:41
Re the two disks of the btrfs raid, those are handled in the -D output already, but inxi -R does not yet have btrfs raid support.

zfs, md-raid are supported, each type has to be added manually since each is totally different in output.

Can you show the full output and commands to get all raid data from btrfs?

Remember to only give generic commands that inxi can use without knowing anything about your system, of course.

From those I can usually figure out how to proceed.

It must have something like a btrfs all command to show all devices and raid arrays, etc.

If you and others can provide full btrfs raid collection methods and data samples, I can add those to the inxi debugger. I'll llook them up for now, maybe we can get -R to support btrfs too.

thanks.
Title: Re: inxi bugs or failures - please report
Post by: h2 on 2014/04/28, 01:31:53
Added some btrfs data collection to inxi debugger:

btrfs filesystem show
btrfs filesystem show --mounted

which will be a start, but I'll need a fair number of sample data sets before I can get the syntax for raid.
Title: Re: inxi bugs or failures - please report
Post by: dibl on 2014/04/28, 03:54:22
This is the basic ID of the btrfs filesystem:

Code: [Select]
root@imerabox:/home/don# btrfs fi show /mnt/DATA
Label: none  uuid: 9025bea6-b615-470a-8759-df1b13f63b52
        Total devices 2 FS bytes used 948.87GiB
        devid    1 size 931.51GiB used 804.03GiB path /dev/sdc
        devid    2 size 931.51GiB used 804.01GiB path /dev/sdd

Btrfs v3.14.1

And to show the capacity utilization we issue

Code: [Select]
btrfs fi df /mnt/DATA

and see something like


Code: [Select]
Data, RAID0: total=1.56TiB, used=947.21GiB
Data, single: total=8.00MiB, used=6.28MiB
System, RAID1: total=8.00MiB, used=116.00KiB
System, single: total=4.00MiB, used=0.00
Metadata, RAID1: total=3.00GiB, used=1.65GiB
Metadata, single: total=8.00MiB, used=0.00
unknown, single: total=512.00MiB, used=0.00




Note that fdisk does not help much, if the BTRFS filesystem is on the raw devices:


Code: [Select]
root@imerabox:/# fdisk -lu


Disk /dev/sdc: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders, total 1953525168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000


Disk /dev/sdc doesn't contain a valid partition table
Title: Re: inxi bugs or failures - please report
Post by: h2 on 2014/04/28, 05:34:04
those don't help because it assumes that inxi already knows the mount points of btrfs, which is what it has to discover.

show the ones I asked

btrfs filesystem show
btrfs filesystem show --mounted

for raid, inxi has to discover what is being used for raid, etc. I don't yet know what data I can get from btrfs, zpool/zfs has great reporting tools, btrfs is not as good yet.

I don't know if I'll look at btrfs raid for a while, I need a  lot more diverse data samples, and it's a big change internally in inxi, it was built for md-raid and zfs, and then only if bsd for zfs, even though you can have zfs on linux. so to upgrade -R will require a pretty major redo of the logic to make it universal, ie, any system, any combination of raid, very hard to develop and test because without a raid system for each type it's very hard to emulate the data.

I did / do have md-raid and zfs more or less solid, but not as 2 of a set of possible raids, more as just one or the other. Not sure how I'd handle that.
Title: Re: inxi bugs or failures - please report
Post by: dibl on 2014/04/28, 12:40:04
There is no difference in the outputs -- probably because the only BTRFS filesystem in the computer is already mounted:


Code: [Select]
root@imerabox:~# btrfs fi show
Label: none  uuid: 9025bea6-b615-470a-8759-df1b13f63b52
   Total devices 2 FS bytes used 948.87GiB
   devid    1 size 931.51GiB used 804.03GiB path /dev/sdc
   devid    2 size 931.51GiB used 804.01GiB path /dev/sdd


Btrfs v3.14.1
root@imerabox:~# btrfs fi show --mounted
Label: none  uuid: 9025bea6-b615-470a-8759-df1b13f63b52
   Total devices 2 FS bytes used 948.87GiB
   devid    1 size 931.51GiB used 804.03GiB path /dev/sdc
   devid    2 size 931.51GiB used 804.01GiB path /dev/sdd


Btrfs v3.14.1


So if I unmount the BTRFS filesystem, the second command gives a null output:


Code: [Select]
root@imerabox:~# umount /dev/sdc
root@imerabox:~# btrfs fi show --mounted
Btrfs v3.14.1
root@imerabox:~#
 

But the first command still shows it the same.


Title: Re: inxi bugs or failures - please report
Post by: melmarker on 2014/04/28, 17:34:12
inxi_2.1.23.r2258.1_all.deb is now in the repo - should be available from the mirrors soon
Title: Re: inxi bugs or failures - please report
Post by: dibl on 2014/04/28, 18:30:03
Wow -- PERFECT!


Code: [Select]
don@imerabox:~$ inxi -v3
System:    Host: imerabox Kernel: 3.15-rc3-siduction-amd64 x86_64 (64 bit gcc: 4.9.0)
           Desktop: KDE 4.12.4 (Qt 4.8.6) Distro: aptosid 2011-02 Ἡμέρα - kde-lite - (201107131633)
Machine:   Mobo: ASUSTeK model: P6X58D-E v: Rev 1.xx Bios: American Megatrends v: 0803 date: 08/06/2012
CPU:       Quad core Intel Core i7 CPU 950 (-HT-MCP-) cache: 8192 KB
           flags: (lm nx sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx) bmips: 25176
           Clock Speeds: 1: 3145 MHz 2: 3145 MHz 3: 3145 MHz 4: 3145 MHz 5: 3145 MHz 6: 3145 MHz 7: 3145 MHz
           8: 3145 MHz
Graphics:  Card: NVIDIA GF100 [GeForce GTX 480] bus-ID: 05:00.0
           Display Server: X.Org 1.15.1 driver: nvidia Resolution: 1920x1200@59.9hz
           GLX Renderer: GeForce GTX 480/PCIe/SSE2 GLX Version: 4.4.0 NVIDIA 337.12 Direct Rendering: Yes
Network:   Card: Marvell 88E8056 PCI-E Gigabit Ethernet Controller
           driver: sky2 v: 1.30 port: d800 bus-ID: 06:00.0
           IF: eth0 state: up speed: 100 Mbps duplex: full mac: 20:cf:30:5c:41:1d
Drives:    HDD Total Size: 2136.5GB (51.1% used) ID-1: model: OCZ
           ID-2: model: OCZ ID-3: model: WDC_WD1002FAEX
           ID-4: model: KINGSTON_SS100S2 ID-5: model: WDC_WD1002FAEX
Info:      Processes: 322 Uptime: 23 min Memory: 1797.7/5965.6MB Init: systemd runlevel: 5 Gcc sys: 4.8.2
           Client: Shell (bash 4.3.111) inxi: 2.1.23
Title: Re: inxi bugs or failures - please report
Post by: dsat on 2014/04/28, 20:38:26
Hi,

referring to the used percentage of my disc I suspect there might be still a bug:
Code: [Select]
System:    Host: x230t Kernel: 3.14-2.towo-siduction-amd64 x86_64 (64 bit gcc: 4.8.2)
           Desktop: KDE 4.12.4 (Qt 4.8.6) Distro: siduction 12.1 Desperado - kde - (201205212202)
Machine:   System: LENOVO product: 34382BG v: ThinkPad X230 Tablet serial: R9VREMH
           Mobo: LENOVO model: 34382BG serial: 1ZPA02C11M9
           Bios: LENOVO v: GCET63WW (2.03 ) date: 11/14/2012
CPU:       Dual core Intel Core i5-3320M CPU (-HT-MCP-) cache: 3072 KB
           flags: (lm nx sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx) bmips: 10379
           Clock Speeds: 1: 1204 MHz 2: 1204 MHz 3: 1204 MHz 4: 1204 MHz
Graphics:  Card: Intel 3rd Gen Core processor Graphics Controller bus-ID: 00:02.0
           Display Server: X.org 1.15.1 drivers: intel (unloaded: fbdev,vesa)
           tty size: 104x25 Advanced Data: N/A for root
Network:   Card-1: Intel 82579LM Gigabit Network Connection
           driver: e1000e v: 2.3.2-k port: 5080 bus-ID: 00:19.0
           IF: eth0 state: down mac: 3c:97:0e:5a:b2:69
           Card-2: Intel Centrino Advanced-N 6205 [Taylor Peak]
           driver: iwlwifi v: in-tree: bus-ID: 03:00.0
           IF: wlan0 state: up mac: 84:3a:4b:06:78:74
Drives:    HDD Total Size: 120.0GB (3446.5% used) ID-1: model: INTEL_SSDSC2CW12
Info:      Processes: 213 Uptime: 30 min Memory: 868.7/15755.2MB
           Init: systemd runlevel: 5 Gcc sys: 4.8.2 Client: Shell (bash 4.3.111) inxi: 2.1.23

Regards dsat
Title: Re: inxi bugs or failures - please report
Post by: dsat on 2014/04/28, 20:53:28
Hi,

sorry, it's not a bug, it's a feature: the space of my nfs-mount is included. When umounted the space used looks correct:
Code: [Select]
Drives:    HDD Total Size: 120.0GB (49.2% used) ID-1: model: INTEL_SSDSC2CW12

Regard dsat
Title: Re: inxi bugs or failures - please report
Post by: h2 on 2014/04/28, 22:55:52
Of more general interest, inxi 2.1.24 fixes _some_ false reading issues for cpu temp.

This fix may break a few working setups, but sensors are very difficult, it's all guesswork in most cases.

If you think inxi is wrong where it was right, please post the output of: sensors
and the output of inxi 2.1.24: inxi -s

I believe _more_ wrong cases will be corrected than previously right cases but now wrong cases will be created.

There's a limit however to what I can get right and wrong, and of course, inxi has to be 'right' for my test systems first of all, ;-)

However, this handles a major bug with temp in msi/asus mobos, and also handles some bad temp data in other systems I have had the sensors output for.

I have added in temp3 readouts as well, though they are only used to get best cpu temp where temp2 temp2 and temp3 exist, they cannot be used to get mobo temp because temp3 is not reliable as a low value.

This fix handles the bad CPUTIN: 127C by using PECI 0 data in that case if there is no core0 data.

It's all hacks and guess work though in the end.
Title: Re: inxi bugs or failures - please report
Post by: h2 on 2014/04/28, 23:04:51
No, that's a bug, re including remote mounts in the disk percent used.

Please generate a: inxi -xx@ 14
so I can look at it, or just paste in:

df -P -T --total

So I can see what was not excluded. make sure that thing is mounted, the one that caused the huge percent used result.

Again, that is a bug, probably caused by my using the --total feature of df.

I need to see the remote fs type.

Post as quickly as possible so I cna squeeze this into the 2.1.24 release.
Title: Re: inxi bugs or failures - please report
Post by: melmarker on 2014/04/28, 23:07:16
inxi_2.1.24.r2265.1_all.deb is in the repo ...
Title: Re: inxi bugs or failures - please report
Post by: h2 on 2014/04/28, 23:17:28
Heh, you were too fast, I just fixed the bug with including nfs/nfs4/smbfs sizes in the -D disk used output.

I didn't boost the version number since 2.1.24 was just released.

But these are exactly the types of bug reports I was hoping to get.

I am now wondering about using --total at all, because every non anticipated file system can break it if it's not explicitly excluded.

that's what caused this error, the non --total method checks to see that it's a dev mounted file system before adding it.

For now the issue is corrected, but only for nfs/smbfs/nfs4 but it's a poorly future proofed method in my opinion, maybe I should drop the --total method.
Title: Re: inxi bugs or failures - please report
Post by: melmarker on 2014/04/28, 23:19:50
h2 - sorry, read your second post after uploading  - but a inxi upload is fast and cheap so this should be no problem :)

EDIT: can i upload again or is this still work in progress?
Title: Re: inxi bugs or failures - please report
Post by: h2 on 2014/04/28, 23:30:11
I decided that this false used bug report was too serious and exposed a serious lack of future proofing, so I removed using --total from inxi, now it only uses partitions that are found in /dev somewhere.

To make sure this mistake dies, I did 2.1.25.

I am excluding those fs types now as well, but that just changes how many loops gawk has to do, nothing else.

thanks for catching that one, I knew --total was too good to be true, and it is.

2.1.25 is stable since it just removes the method. That's two days in row I did two numbered releases, now it's time for work though.

<update> after checking some data, I decided to not use temp3, that item is very unreliable.

There may be other sensors issues, but do keep in mind, some sensors output combinations simply cannot be guessed at without breaking others instantly, so inxi needs to try to be right more than it is wrong in such fringe cases, that's the best it can do.

But always post sensors output and inxi -s output if you think inxi is wrong, sometimes I can find a pattern that is safe to handle without breaking other things, that's how I got PECI, temp3, and Core0 cpu temp overrides working more or less now for example
Title: Re: inxi bugs or failures - please report
Post by: melmarker on 2014/04/29, 01:51:58
inxi_2.1.25.r2269.1_all.deb  is in the repo
Title: Re: virtualization report - add to wish list,pls
Post by: musca on 2014/04/29, 12:02:26
Hello h2,

we enjoy your nice work almost every single day, thank you so much!

Some time ago we talked about Virtualization support and at that time it was difficult to do without root.
Ofcourse there are some indirect hints like type of Graphics or Motherboard.

But there is the package imvirt in sid which now seems to do it without root, e.g.

Code: [Select]
$ imvirt
VirtualBox

$imvirt
KVM

$ imvirt
Physical

and i would like to see such a hint even in the short output of `inxi` without options.

Please add this to the wish list for inxi 3.0   ;)

greetings
musca
Title: Re: inxi bugs or failures - please report
Post by: dsat on 2014/04/29, 17:48:57
Hi,

here is the output:
Code: [Select]
root@x230t:# df -P -T --total
Dateisystem            Typ      1024-Blöcke    Benutzt  Verfügbar Kapazität Eingehängt auf
/dev/sda1              ext4        15995848    8740336    6419928       58% /
udev                   devtmpfs       10240          0      10240        0% /dev
tmpfs                  tmpfs        3226676       3312    3223364        1% /run
tmpfs                  tmpfs        8066688          0    8066688        0% /dev/shm
tmpfs                  tmpfs        8066688          0    8066688        0% /sys/fs/cgroup
192.168.x.x:/media/md0 nfs       5813963776 3976600576 1544334336       73% /media/<directory>
tmpfs                  tmpfs         102400          4     102396        1% /run/user
tmpfs                  tmpfs           5120          0       5120        0% /run/lock
/dev/sda2              ext4          991512     293244     630684       32% /media/System
/dev/sda3              xfs         75739000   48597612   27141388       65% /media/Storage
total                  -         5926167948 4034235084 1598000832       72% -

inxi is up to date and gives:
Code: [Select]
Drives:    HDD Total Size: 120.0GB (49.2% used) ID-1: model: INTEL_SSDSC2CW12
Info:      Processes: 196 Uptime: 8 min Memory: 822.7/15755.2MB
           Init: systemd runlevel: 5 Gcc sys: 4.8.2 Client: Shell (bash 4.3.111) inxi: 2.1.25

Regards dsat
Title: Re: inxi bugs or failures - please report
Post by: h2 on 2014/04/29, 21:06:45
musca, thanks, however, in inxi, I try to keep to an absolute minimum recommended packages, always preferring to query the system directly to get the data, it's more reliable and means it will work for most users right away.

If simple raw virtualization detection is required, all that is needed is a set of checks, for example, vbox has a distinct id in the name of its devices, disks, etc, that is easy to spot.

vmware I haven't seen for a while, but doing inxi -Fxx on any system should show the distinct identifiers used in some cases.

However, you'd have to get in line, 2.2 is reserved for the long waited for -m option, memory, I was hoping that data would appear in /sys but I guess it isn't, so that will require root and dmidecode, sadly. And 3.0 is far far away, that's 9 new major features, I don't know if a bash+gawk script can get that big to be honest.

I won't have time for any other things in the coming months though I think, I have never found a major feature that requires less than 2 weeks of datacollection at least, plus coding, plus fixing exceptions, so I always have to give careful thought to any new feature.

However, people can help this process by collecting data on the feature type, all possible outputs, data sources, etc.

imvirt is getting its data from somewhere, so all you have to do is figure out some method to do that test for each vm type. My guess is a short function would do it. kvm might be harder because it has more options, like using host kernel, etc.
Title: Re: inxi bugs or failures - please report
Post by: melmarker on 2014/05/04, 03:56:32
hi h2 - a special wish: is it possible, that you let inxi detect LXQt? That would be nice for our planned Release at LinuxTag Berlin
Title: Re: inxi bugs or failures - please report
Post by: h2 on 2014/05/04, 19:33:09
to add a desktop identification, I need a few things:

latest: inxi -xx@ 14
from the system running that desktop.

That gives me the data required to see if the standard methods detect it.

Then, I need the actual process name..

let's say it's lxqt

then I need how to obtain its version data: lxqt --version
for example, the actual command, and then I  need the actual literal output of that command

Then, because I've found some fringe cases, I further need this, assuming it's called lxqt:

lxqt --version && echo goes to stdout || echo goes to stderr

this is because in a few cases desktops decide to putput their version data to stderr. weird, silly, but it happens.

Once I have this data I can add support.

I also need to know if the desktop is a derived type, like some are, where the actual id is openbox, for example, inxi in those cases finds the process then queries the primary thing, like openbox, for version data.

Title: Re: inxi bugs or failures - please report
Post by: h2 on 2014/05/05, 19:30:53
If you guys want this, you'll have to do the research and provide all the data required.

Here's what some siduction person's -xx@14 showed me

inxi shows LXDE (Openbox v...)

xprop -root shows the primary container is Openbox

$XDG_CURRENT_DESKTOP is 'Razor'

in ps aux, no razor-desktop appears, but lxqt-session does.

startlxde-qt is present which is why it shows as lxde.

so to get anywhere, I need this:

razor-desktop --version
lxqt-session --version

or any other command that gives version info, like -v.

If not null, post the literal output. if null, post that fact too.

Then someone who understands what the difference is here between razor and lxqt is to post the technical explanations.

Failing this, I'll just leave this alone until it's clarified.

inxi as is will show this as lxde because of the startlxde-qt in the ps aux, but I don't remember what lxde itself looks like in ps aux, though I believe

$XDG_CURRENT_DESKTOP is 'LXDE' but I also believe I could not rely on XDG beiing set, so I added in a fallback ps aux test.

So you guys will have to figure it out then post the literal ways to differentiate the three, lxde, qt-razor, and lx-qt.

with all verison tests etc.

Once i have that, I'll look at the problem again.

Title: Re: inxi bugs or failures - please report
Post by: h2 on 2014/05/05, 19:56:13
I went back through my datasets and found some LXDE stuff, so I can remove one ambiguity, now it can search for /lxsession in ps aux, I believe that closes that.

Then inxi will show razor-qt until I get more logic.

I can add the tests for each type, but I still need the version data if it's present, I realized that inxi only shows the openbox version stuff.

on this one I"ll put a branches/one inxi, which you get by: inxi -! 15 (requires update enabled)

I'm also not clear on what this is in the first place, is LXQt the new LXDE, or are they two different thtings?
Title: Re: inxi bugs or failures - please report
Post by: melmarker on 2014/05/05, 20:40:42
hey :) - need to push the possibility ($foo --version) upstream :P Until now there is no such thing.

LXQt - The "new" one, based on Qt
LXDE - The gtk-based one - should be dead soon, but .. i think it will last for one or another year
Title: Re: inxi bugs or failures - please report
Post by: h2 on 2014/05/05, 21:08:20
we'll see then.

it looks like both qt things, razor and lxqt identify themselves via xdg value as Razor.

I don't know if this is how it will be in the end.

Right now if xdg is 'LXDE' it shows as lxde, and if it's Razor, i can define it as either razor-qt or LXQt, but I know this is unlikely to remain the case.
Title: Re: inxi bugs or failures - please report
Post by: melmarker on 2014/05/05, 21:14:38
i think LXQt will be LXQt - until now the xdg name was Razor :) - Changed in Upstream 3 days ago i think
Title: Re: inxi bugs or failures - please report
Post by: h2 on 2014/05/05, 21:21:14
ok, 2.1.28 should in theory work then.

I've added the xdg LXQt test too, so that means old lxde should id fine, and new lxqt/razor stuff should id fine, with razor-qt showing as that, and lxqt showing as that. I added one default case fallback where it will show LX-Qt-Variant if it failed to match any of the specific tests, so if you see that, it means we need more data.

Show me the new: inxi -Sxxx

in theory.
Title: Re: inxi bugs or failures - please report
Post by: h2 on 2014/05/06, 20:43:37
Does 2.1.28 work for LXQt?
Title: Re: inxi bugs or failures - please report
Post by: melmarker on 2014/05/06, 20:45:51
stay tuned have neighter one or the other now :)
Title: Re: inxi bugs or failures - please report
Post by: h2 on 2016/10/24, 05:58:51
Quote
Some time ago we talked about Virtualization support and at that time it was difficult to do without root.
Ofcourse there are some indirect hints like type of Graphics or Motherboard.

musca, if still around, this feature is now somewhat implemented as part of an -M fix for another issue. Note that the new Device: entry in the -M line covers device type, and if detected as possible vm, it tries to figure out which vm it is. This isn't perfect and will miss some vms probably but I added it remembering this very old feature request.

2.3.2 has the new device id. If you find any blatant failures in vm identification, let me know. The commonly used desktop vms should mostly work, except parallels and the microsoft vm, I'll probably try to figure out a non root way to id those as well but since they are apple and ms products I'm not heavily motivated, but I will add them if there is any actual issue posted on them with enough data to figure out how to reliably identify them with both non root system tests and dmidecode system tests (for bsd, old linux id purposes).

For systemd users, the id should work pretty well because it uses systemd-detect-virt plus some fallback tests, so I figure out of the box I probably handled maybe 98% of realworld virtual machine ids, most of the failures will be on BSDs I believe.

If it couldn't figure out which vm is it, but it is sure it's a vm, it prints: Device: virtual-machine

If it probably is a vm but it could not detect absolute proof, it will print: Device: other-vm?

For non vm, it prints things like desktop, server, laptop, notebook, etc. These will not all be right because they are based on what the system board dmi has, which is as we've seen with ram, often quite inaccurate. But it will be close in most cases. Obviously, for home built systems, if you make a server with a desktop mobo, it's not going to magically say server, it's going to say desktop, since that's what it actually is.
Title: Re: inxi bugs or failures - please report
Post by: melmarker on 2016/10/24, 13:23:16
hi h2 - i found a major bug :P - could you be so kind an tag your releases on github - if possible with a signed tag? If you have questions about the github release process please ping me.
Title: Re: inxi bugs or failures - please report
Post by: h2 on 2016/10/24, 19:57:16
The github inxi readme covers tagging, as do several closed issues. That's not a bug, and it's most certainly not a major bug. I consider, personally, git tagging itself to be a major bug, and one that is so logically absurd that I find it almost mindboggling that users who should know better can't see what an absurdity it is. My general recommendation to anyone in a distro who relies on something that unreliable for anything is to file a bug report with the distro. github itself provides a very nice way to point directly to any commit, and I believe the new git also has that feature, which finally corrects the public belief that tagging is anything more than a crude poorly done hack. Just to briefly reiterate, since each and every inxi commit is the final stable version, each and every inxi commit would need a tag, which is silly, of course.

If there are issues related to vm identification, I'd like to get those covered, but git tagging, no, not interested.
Title: Re: inxi bugs or failures - please report
Post by: melmarker on 2016/10/29, 20:46:22
but it's nice to hear that inxi is still in development even if it will not reach the debianoid world
Title: Re: inxi bugs or failures - please report
Post by: h2 on 2016/10/29, 22:32:39
mel, you're fairly out of touch, inxi is in debian stable, testing, and sid. Has been for a while. As well as gentoo, arch, mint, ubuntu, opensuse, fedora, redhat, mageia, and so on. Also freebsd and a few other bsd variants, though I don't track that much. Plus many derived distros that may package it to have the latest version available, like solus, antix, desktopBSD, etc. mageia has been particularly quick to update, along with arch since the start of packaged inxi. It's also included in the xubuntu installation cd, since it makes user support much easier. I happened to notice that our ancient forerunner, what started it all here, knoppix (knoppix->kanotix->sidux-...) now ships it with his live cd as well, which I thought was interesting. It was only due to a ridiculous mix up, in fact, that inxi didn't make it into old stable, someone had filed a totally invalid issue report that clogged up the introduction of inxi into that stable, but it entered debian right after that, once the issue was cleared out.

Code: [Select]
apt-cache policy inxi
inxi:
  Installed: (none)
  Candidate: 2.3.1-1
  Version table:
     2.3.1-1 500
        500 http://mirrors.kernel.org/debian unstable/main i386 Packages
        200 http://mirrors.kernel.org/debian stretch/main i386 Packages

debian obviously lags a bit between updates, but it's been a lot better as of late, particularly since both 2.3.1 and 2.3.2-2.3.3 contain 'killer' new features which are highly desirable for system support.

inxi's development basically tracks interesting user issues, and things I want, like the relatively new battery info that 2.3 introduced. Both the uefi/bios detection and the new device detection were in response to well done issue reports.

Most of the new features haven't really required the degree of beta testing that you last saw here with the ram info option, which was and is an ugly solution to a problem with no good solutions. Battery for example went live with no issues at all because my hardware had revealed all the possible variances in data format, which was convenient.

I keep in touch with the debian packager, who is actually the ubuntu packager, he sends it upstream to debian's maintainer. I've honestly never understood why it takes more than a few days after a new release to get inxi into debian proper because inxi never has dependency issues, by design, so new inxi can always be dropped into any system, old, ancient, or new.

If you look closely at the inxi files, you'll discover that in fact, they pass lintian tests, which are the best and strictest packaging tests of any distro, I know, because inxi was in all the other distros before it got into debian, and I had to update the man stuff a bit to get it to pass lintian tests. This is an example of a good rule that benefits users, and one I am quite happy to go out of my way to get inxi to comply with, because it has clear and valid and logical and coherent benefits to users, packagers, and me. Unlike something that is badly done, helps nobody at all, and which is pointless and counterproductive, like, oh, say, git tagging. I've literally thought many times of dumping git and github so I don't have to entertain this nonsensical question ever again, but I figure the eyeballs in github make up for the annoyances of git users and their confusions about proper procedures. If it does ever get too annoying, I'll probably move to mercurial hosting, since git does me no personal good at all, it's a negative in every single way for me as a developer except for the eyeballs it gets in github, so I make that personal sacrifice. I'll see how it goes, I've learned to sort of hobble along with git, which is a really bad tool for my needs, so I basically just ignore it except for commits.

It's worth repeating that both git current, latest versions, and github provide a proper, correct, way, to point to commits directly, like it should have always done, as svn always did, so I believe the only people out of the loop on this question are people who haven't been paying much attention to the matter.
Title: Re: inxi bugs or failures - please report
Post by: melmarker on 2016/10/29, 23:33:05
ok, i'm finally out of this game - forever.

PS: Thanks for your words - we will use from now the debian version.
Title: Re: inxi bugs or failures - please report
Post by: Lanzi on 2016/10/30, 22:10:06
h2, this is really outstanding work. thank you very much!