inxi bugs or failures - please report

[devil]

just to explain: a quite thick user just fired off inxi -h in our channel


greetz
devil

[h2]

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


[melmarker]

h2, sorry - my fault. i forget about drag and drop

[h2]

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.

[h2]

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.

[melmarker]

new minor uploaded, 2.1.18 rev 2197

[h2]

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.

[h2]

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.

[h2]

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.

[dibl]

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:/#

[h2]

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.

[dibl]

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.    

[timc]

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

[h2]

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.

[h2]

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.