To be able to check if a computer is fully compatible. Please create a Windows Version of this app.

It looks to me that blkid/fdisk/lsblk as well as ifconfig do not provide really interesting data, but otoh gives a lot of information on that computer (like whether FDE is used, are other OSes installed, is a VPN or some other kind of additional network layer is in use).

Is there really a point in collecting those?

Maybe it is possible to add a flag for hw-probe, which would turn on Perl debug output? For example, on one of my machines, probing gets stuck:
$ su
Пароль:
root@Mikhail-MSK-PC:/tmp/hw-probe# hw-probe -all -upload -id M_msk1
Probe for hardware ... hw-probe -all -upload^C
root@Mikhail-MSK-PC:/tmp/hw-probe# ^C
root@Mikhail-MSK-PC:/tmp/hw-probe# hw-probe -all -upload
Probe for hardware ...

And I cannot debug it.

Add output of
acpidump
(Debian/Ubuntu package acpica-tools to be added to debian/control)
Linux kernel developers often ask for it to develop a driver for a rare semi-mobile device.

I tried to Determin the graphicard Problem on my laptop
https://linux-hardware.org/?probe=4cfb07305a

and detected the kernel setup parameter "nomodset" as the source for the problem.

after that change:
https://linux-hardware.org/?probe=b3e69d5f2c
now I only have a "failed" without any hint on this lists.

what could a "failed" without any description mean?

I come here from Ask Ubuntu (As user) dealing much with hardware stacks issues. After some search that point me to the EDID repository and "Linux Hardware" site.

Graphic stack is changing relatively fast within GNU Linux/BSD systems.

Currently, I find many long standing questions which asked there without generic/canonical answer. More concerning: KMS drivers, Monitor Modes, High-DPI, Grub/VESA mode then things get complicated with Multi-Head/adapters (in Multi-Monitor setups) and Bad EDID's.

So, I would request adding the output of:

xrandr --verbose 

It will show much about current setup (Modes, Transformations, Layout..) and how driver decoded EDID. Also xrandr is now a part of the graphic stack.

Side Note

• There are many other cases where users use the Control GUI coming with binary drivers like nVidia and ATi. I am not too familiar with to know how to extract the active setup from them.

• Some users add their workarounds to xorg.conf.d/ folder instead of xorg.conf file. But scanning that may raise privacy issue.

We need a new form to search by computer model in the Web UI.

I think you could widen the audience for this tool if you were to add support for not uploading hashed MAC addresses and serial numbers.

Folks who are a bit paranoid would be more likely to submit hardware probes when those sort of details are not uploaded without their consent and the benefits of uploading them are clearly explained.

I think I would design the support a private mode like this:

Add command-line options for enabling/disabling uploading salted hashed device identifiers.

When one of these options is not passed to hw-probe, print enough information (including other considerations and the benefits and risks of adding the salted hashed device identifiers) so they can give informed consent if desired, in both layperson language and in technical language (mention the hash used etc) and then ask them for consent, without allowing a default answer, so that the decision is entirely in the user's hands.

Also include the exact same information in the --help output and in the manual page privacy section, with a note about the privacy section next to the options for enabling/disabling uploading salted hashed device identifiers.

PS: the manual page is currently missing the information that a salt is applied before hashing.

This isn't going to widen the audience for this tool to the more paranoid people, but it could at least widen it to the slightly paranoid people. The amount of slightly paranoid people is expanding every year because of all the news stories about companies getting hacked or leaking or selling all of their user data.

Hi, on Ubuntu 16.04 (it_IT default locale), i got the error ERROR: failed to detect hwaddr, due to the localized output of ifconfig.

To solve this, i had to change the line:

my $LOCALE = "C.UTF-8";

to:

my $LOCALE = "C";

then the tool worked correctly.

Output of locale -a on my system:

C
C.UTF-8
en_AG
en_AG.utf8
en_AU.utf8
en_BW.utf8
en_CA.utf8
en_DK.utf8
en_GB.utf8
en_HK.utf8
en_IE.utf8
en_IN
en_IN.utf8
en_NG
en_NG.utf8
en_NZ.utf8
en_PH.utf8
en_SG.utf8
en_US.utf8
en_ZA.utf8
en_ZM
en_ZM.utf8
en_ZW.utf8
it_CH.utf8
it_IT.utf8
POSIX

Hello.
As I can see, hw-probe cuts out device mapper device names (for example rewrites /dev/mapper/asdfg into /dev/mapper/XXXXXX), but it's worth nothing because it could leak from grub configuration file:
GRUB_CMDLINE_LINUX="<blabla> root=/dev/mapper/asdfg <some_other_options>"

On multi-GPU systemd (notebooks with 2 GPUs) vainfo reports information about Intel or another first GPU. I suggest to collect information about other devices.

All devices can be found like this:

ls /dev/dri/render*
/dev/dri/renderD128 /dev/dri/renderD129

Then query:
vainfo --display drm --device /dev/dri/renderD128
vainfo --display drm --device /dev/dri/renderD129

Example output:

nikolay@Dell-5521:~$ vainfo --display drm --device /dev/dri/renderD128
libva info: VA-API version 1.1.0
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so
libva info: Found init function __vaDriverInit_1_1
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.1 (libva 2.1.0)
vainfo: Driver version: Intel i965 driver for Intel(R) Ivybridge Mobile - 2.1.0
vainfo: Supported profile and entrypoints
      VAProfileMPEG2Simple            :	VAEntrypointVLD
      VAProfileMPEG2Simple            :	VAEntrypointEncSlice
      VAProfileMPEG2Main              :	VAEntrypointVLD
      VAProfileMPEG2Main              :	VAEntrypointEncSlice
      VAProfileH264ConstrainedBaseline:	VAEntrypointVLD
      VAProfileH264ConstrainedBaseline:	VAEntrypointEncSlice
      VAProfileH264Main               :	VAEntrypointVLD
      VAProfileH264Main               :	VAEntrypointEncSlice
      VAProfileH264High               :	VAEntrypointVLD
      VAProfileH264High               :	VAEntrypointEncSlice
      VAProfileH264StereoHigh         :	VAEntrypointVLD
      VAProfileVC1Simple              :	VAEntrypointVLD
      VAProfileVC1Main                :	VAEntrypointVLD
      VAProfileVC1Advanced            :	VAEntrypointVLD
      VAProfileNone                   :	VAEntrypointVideoProc
      VAProfileJPEGBaseline           :	VAEntrypointVLD
nikolay@Dell-5521:~$ vainfo --display drm --device /dev/dri/renderD129
libva info: VA-API version 1.1.0
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/r600_drv_video.so
libva info: Found init function __vaDriverInit_1_1
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.1 (libva 2.1.0)
vainfo: Driver version: mesa gallium vaapi
vainfo: Supported profile and entrypoints
      VAProfileMPEG2Simple            :	VAEntrypointVLD
      VAProfileMPEG2Main              :	VAEntrypointVLD
      VAProfileVC1Simple              :	VAEntrypointVLD
      VAProfileVC1Main                :	VAEntrypointVLD
      VAProfileVC1Advanced            :	VAEntrypointVLD
      VAProfileH264ConstrainedBaseline:	VAEntrypointVLD
      VAProfileH264Main               :	VAEntrypointVLD
      VAProfileH264High               :	VAEntrypointVLD
      VAProfileNone                   :	VAEntrypointVideoProc
nikolay@Dell-5521:~$ vainfo --device /dev/dri/renderD128
vainfo: unrecognized option '--device'
Show information from VA-API driver
Usage: vainfo --help
	--help print this message

Usage: vainfo [options]
Display options:
	--display display | help         Show information for the specified display, or the available display list 
	--device device                  Set device name, only available under drm display
nikolay@Dell-5521:~$ vainfo --device /dev/dri/renderD129
vainfo: unrecognized option '--device'
Show information from VA-API driver
Usage: vainfo --help
	--help print this message

Usage: vainfo [options]
Display options:
	--display display | help         Show information for the specified display, or the available display list 
	--device device                  Set device name, only available under drm display
nikolay@Dell-5521:~$

Here is a PPA: https://launchpad.net/~mikhailnov/+archive/ubuntu/hw-probe
I hope that I will be able to maintain it further, you can add it to INSTALL and README]

sudo add-apt-repository ppa:mikhailnov/hw-probe
sudo apt update
sudo apt install hw-probe

ddcutil speaks the DDC/MCCS protocols for speaking to external VGA/DVI/HDMI monitors. Using the ddcutil detect/capabilities/usbenv/probe/interrogate commands will provide detailed information about the connected monitors.

https://en.wikipedia.org/wiki/Display_Data_Channel
https://www.ddcutil.com/

@rockowitz is the author of ddcutil and would probably appreciate having external monitor DDC information in the https://linux-hardware.org/ database.

PS: please note that the ddcutil output currently contains serial numbers from the monitor EDID data, so those will need to be stripped out.

Any plans for a new release in future?

Is dmidecode suppose to work with the Flatpak installation?
If I open a shell inside the sandbox with the command flatpak run --command=sh org.linux_hardware.hw-probe and I try to run dmidecode I get only errors as output:

[📦 org.linux_hardware.hw-probe sensors.py]$ dmidecode 
# dmidecode 3.2
/sys/firmware/dmi/tables/smbios_entry_point: Permission denied
Scanning /dev/mem for entry point.
/dev/mem: Permission denied

Is this expected?

IPV6 addresses under "ifconfig" are not properly scrubbed

/128 addresses are visible!

I have Gentoo and installed it; I have kernel 5.6.14 if that makes a difference. It just says Probe for hardware ... and does nothing after that.

I’m wondering what qualifies as a unsupported device and how you detect them.

For instance, I have this in my dmesg:

[   14.217147] lis3lv02d: unknown sensor type 0x0
[   14.217178] hp_accel: probe of HPQ6007:00 failed with error -22

This is an embedded accelerometer, that just doesn’t work under Linux currently. Of course, this is not really important because I don’t know what it could be used for, but it does count as an unsupported device to me. But not sure that you would count it, especially because dmesg is the only place where this is mentioned.

BTW, I think it would be interesting to list separately of dmesg the reported errors (mostly ACPI in general). For instance, this laptop spites:

[   14.301400] ACPI Error: Needed [Buffer/String/Package], found [Integer] 00000000c10b46a6 (20180313/exresop-560)
[   14.301404] ACPI Error: AE_AML_OPERAND_TYPE, While resolving operands for [Index] (20180313/dswexec-427)
[   14.301410] ACPI Error: Method parse/execution failed \_SB.WMIV.WVPO, AE_AML_OPERAND_TYPE (20180313/psparse-516)
[   14.301416] ACPI Error: Method parse/execution failed \_SB.WMIV.WMPV, AE_AML_OPERAND_TYPE (20180313/psparse-516)
[   14.303022] ACPI Error: Needed [Buffer/String/Package], found [Integer] 00000000140c426d (20180313/exresop-560)
[   14.303026] ACPI Error: AE_AML_OPERAND_TYPE, While resolving operands for [Index] (20180313/dswexec-427)
[   14.303030] ACPI Error: Method parse/execution failed \_SB.WMIV.WVPO, AE_AML_OPERAND_TYPE (20180313/psparse-516)
[   14.303035] ACPI Error: Method parse/execution failed \_SB.WMIV.WMPV, AE_AML_OPERAND_TYPE (20180313/psparse-516)
[   14.304256] ACPI Error: Needed [Buffer/String/Package], found [Integer] 00000000638aa933 (20180313/exresop-560)
[   14.304259] ACPI Error: AE_AML_OPERAND_TYPE, While resolving operands for [Index] (20180313/dswexec-427)
[   14.304265] ACPI Error: Method parse/execution failed \_SB.WMIV.WVPO, AE_AML_OPERAND_TYPE (20180313/psparse-516)
[   14.304270] ACPI Error: Method parse/execution failed \_SB.WMIV.WMPV, AE_AML_OPERAND_TYPE (20180313/psparse-516)
[   14.310268] ACPI Error: Attempt to CreateField of length zero (20180313/dsopcode-134)
[   14.310308] ACPI Error: Method parse/execution failed \_SB.WMIV.WVPI, AE_AML_OPERAND_VALUE (20180313/psparse-516)
[   14.310362] ACPI Error: Method parse/execution failed \_SB.WMIV.WMPV, AE_AML_OPERAND_VALUE (20180313/psparse-516)

on every boot. The consequences are not clear to me, but being able to check rapidly whether this laptop model has some kinds of ACPI issues would be interesting.

Also, I would be interested to know how many laptops boot with acpi_osi=! acpi_osi='Windows 2009' or pcie_port_pm=off. Those are used to workaround some very important issues of hardware support under Linux regarding Nvidia GPU in laptops. I wouldn’t really count those devices as perfectly supported, since generally those options have a lot of consequences (non-working hotkeys, increased power consumption…). Yet you do not report this as an issue, because you do not detect it.

It seems like the package the packages dmidecode and lscpu are not available when running FreeBSD on ARM. This means the install script is not working.

Hi,

If I only want to upload hardware related info using the following command, it fails:

# hw-probe -probe -upload
Probe for hardware ... Ok

ERROR: failed to upload probe

However if I choose to upload all, it gets uploaded:

# hw-probe -all -upload
Probe for hardware ... Ok
Reading logs ... Ok
Uploaded to DB, Thank you!

Probe URL:  https://linux-hardware.org/index.php?probe=xxxxxxxxxx

Would it possible to only upload the hardware related probe info (in case uploading of logs may contain sensitive information)?

linux-hardware.org is missing an item on the list: convertible.
See HP Envy x360 15-cp0xxx

Add new probes nvidia-smi, CUDA-Z and numactl -H as suggested on the OpenMandriva mailing list: http://ml.openmandriva.org/pipermail/om-cooker_ml.openmandriva.org/2016-February/000267.html

I ran the hw-probe without -upload. When I checked the logs, HOSTNAME is in xorg.log with more than one line of
Current Operating System: Linux ...

Thanks,
Rob

on my hw-probe I have some sshfs entrys in this entries I could see the server with Username.
also hw-probe transfered the # Comments from fstab which contain sensitive Information which I need to modify my sshfs.
please remove all comments on fstab entries

Since I found this really nice tool, I try to test all kind of devices with it. Last device I tested was this one:
http://linux-hardware.org/?probe=9e530b2e21
Here is a Touchscreen missing. The touchscreen itself is also not working.

I use http://q4os.org/ with Trinity because it's the only system I could install on a device with less than 1024 MB RAM. Also special on this device, it has a 32bit EFI but a 64bit CPU.

./hw-probe.pl -all -upload -id MSI -group 5ebeb48a46d163e6
WARNING: failed to detect Linux distribution
Probe for hardware ... Ok
Reading logs ... Ok
Uploaded to DB, Thank you!
Probe URL (Private): http://linux-hardware.org/index.php?probe=404f145917&token=0da169a0e24278f2
Probe URL (Public): http://linux-hardware.org/index.php?probe=404f145917

Distribution detect should be work, I got:

$ cat /etc/os-release
NAME=Gentoo
ID=gentoo
PRETTY_NAME="Gentoo/Linux"
ANSI_COLOR="1;32"
HOME_URL="http://www.gentoo.org/"
SUPPORT_URL="http://www.gentoo.org/main/en/support.xml"
BUG_REPORT_URL="https://bugs.gentoo.org/"

POP!_OS seems to be detected as Ubuntu by HW-Probe.

Even if POP!_OS is based on Ubuntu, it does more and IMHO should be recognized separately.

On quite a few systems Ubuntu 19.10 won't even boot, but a POP!_OS version (based on Ubuntu 19.10 will have no issues booting and installing.

Thank you.

We need to save output of vainfo and vdpauinfo in the probe.

Manjaro 18.1.5, i3 community edition.

I've installed XFCE in the past, but it's been a long time since I've used it. Here's a link to my probe: https://linux-hardware.org/?probe=86410e30f4

https://linux-hardware.org/?probe=a230cb590f

DE | Cinnamon THAT IS SO WRONG. ->I run Windowmaker with GNUstep
Type | main server. -> Just a Workstation/Desktop?

Hi,

is there any way that I can report a device as not working properly. I have a case where linux loaded a driver for my audio, but it is not working 100% as expected.

The machine's hostname appears in dmesg (at least on system with systemd):

systemd[1] : Set hostname to <MYHOSTNAME>.

This information is also uploaded to the database.

Hi,

I am trying to do a probe of Rock Pi 4.

However when I run hw-probe -check -d, the system crashes and restarts. This is found in the debug TTL log:

[  248.071527] SError Interrupt on CPU5, code 0xbf000000 -- SError
[  248.071529] CPU: 5 PID: 2806 Comm: dmidecode Not tainted 5.3.11-rockchip64 #19.11.3
[  248.071530] Hardware name: Radxa ROCK Pi 4 (DT)
[  248.071530] pstate: 20000000 (nzCv daif -PAN -UAO)
[  248.071531] pc : 0000ffffa82693cc
[  248.071532] lr : 0000aaaaccd06a0c
[  248.071532] sp : 0000ffffd05255f0
[  248.071533] x29: 0000ffffd05255f0 x28: 0000000000000000 
[  248.071535] x27: 0000000000010000 x26: 0000ffffa835a000 
[  248.071536] x25: 0000000000000003 x24: 00000000000f0000 
[  248.071538] x23: 0000000000000000 x22: 0000000000010000 
[  248.071540] x21: 0000aaaaccd20000 x20: 0000aaaad2bbc4a0 
[  248.071541] x19: 0000aaaaccd093b8 x18: 000000000000ffff 
[  248.071543] x17: 0000ffffa82692d0 x16: 0000aaaaccd20e50 
[  248.071544] x15: 0000000000000002 x14: 0000000000000000 
[  248.071546] x13: 0000000000000000 x12: 0000000000000000 
[  248.071547] x11: 0000000000000000 x10: 0000000000000000 
[  248.071548] x9 : 0000000000000000 x8 : 00000000000000de 
[  248.071550] x7 : 0000000000000000 x6 : 0000000000000000 
[  248.071552] x5 : 0000aaaad2bcc4a0 x4 : 0000ffffa836a000 
[  248.071553] x3 : 0000aaaad2bbc4a0 x2 : 0000000000010000 
[  248.071555] x1 : 0000ffffa835a000 x0 : 0000aaaad2bbc4a0 
[  248.071557] Kernel panic - not syncing: Asynchronous SError Interrupt
[  248.071557] CPU: 5 PID: 2806 Comm: dmidecode Not tainted 5.3.11-rockchip64 #19.11.3
[  248.071558] Hardware name: Radxa ROCK Pi 4 (DT)
[  248.071559] Call trace:
[  248.071560]  dump_backtrace+0x0/0x140
[  248.071560]  show_stack+0x14/0x20
[  248.071561]  dump_stack+0xa8/0xd4
[  248.071561]  panic+0x158/0x324
[  248.071562]  __stack_chk_fail+0x0/0x18
[  248.071562]  arm64_serror_panic+0x70/0x80
[  248.071563]  do_serror+0x78/0x158
[  248.071564]  el0_error_naked+0x14/0x1c
[  248.071683] SMP: stopping secondary CPUs
[  248.071684] Kernel Offset: disabled
[  248.071684] CPU features: 0x0002,20006008
[  248.071685] Memory Limit: none

Not sure if its a Linux kernel issue or with hw-probe. Tested on Armbian Buster image with Linux 5.3.11. Thanks.

Hello there,

I think, it would be sensational if you just save the information in current directory rather than root home directory.

Thank you

Hi,

after 30+ days of uptime on my laptop the only thing you will get from dmesg(8) command are mostly this:

wlan0: link state changed to DOWN
wlan0: link state changed to UP
wlan0: link state changed to DOWN
wlan0: link state changed to UP
wlan0: link state changed to DOWN
wlan0: link state changed to UP
wlan0: link state changed to DOWN

Thus using (or at least adding) the contents of the /var/run/dmesg.boot file would be useful.

Regards,
vermaden

Hi!
It would be cool to see the logs /var/log/syslog (relevant for DEB-distro) or journalctl (universally for all with systemd)

I am in ubuntu 19.10 and get this error

Executing hw-probe -all -upload

ERROR: failed to detect Linux distribution

ERROR: Make sure required Snap interfaces are connected:

for i in hardware-observe system-observe block-devices log-observe upower-observe physical-memory-observe network-observe raw-usb mount-observe opengl;do sudo snap connect hw-probe:$i :$i; done

root@k:~#

Thanks

Just FYI, inxi has been rewritten and no longer uses the -! options. Since there are many versions of inxi floating around, and most new ones are the 3.0.x series, which uses --no-host for the the -! 31 option, you probably want to version test inxi then construct the command based on if it's 2.9 or newer or older.

The easiest way to test is to simply read the file, and if the first line contains 'bash', it's old inxi, and if the first line contains 'perl' it's new inxi. Some distros get rid of the /usr/bin/env part so you want to just test for the bash/perl.

sample faliure: https://linux-hardware.org/index.php?probe=0d3c2b71cc&log=inxi

 if(check_Cmd("inxi"))
        {
            listProbe("logs", "inxi");
            my $Inxi = runCmd("inxi -! 31 -Fzx -c 0 2>&1");
            writeLog($LOG_DIR."/inxi", $Inxi);
}

Just as an aside, you can get a ton more information than you're getting from inxi.

I recently found this project while looking for EDID info, and thought it would be nice to contribute a probe upload about my hardware.

I naively ran the suggested: sudo -E hw-probe -all -upload (using the AppImage) for the first time without checking the output beforehand.
After seeing that a full probe include 58 logs! I now regret this, and have some concerns about overall privacy of this.

README claims

Private information (including the username, machine's hostname, IP addresses, MAC addresses and serial numbers) is NOT uploaded to the database.

I didn't know that it would default to collecting so much detailed info (and often irrelevant to "hardware") which seems can be used to uniquely identify a person/computer.
After the upload, I decided to use the -save option and grep for some things to see what else might be there.

1. hw.info/logs/efibootmgr DOES CONTAIN my MAC address on a line like: .../MAC(xxxxxxxxxxxx,0)... with the x's being my actual MAC in lowercase hex, no colons.
2. my username is spattered in a few places:
   Due to byobu: hw.info/logs/dev:/dev/shm/byobu-USERNAME-....
   Due to systemctl (in 2 forms): hw.info/logs/systemctl: media-USERNAME-XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.mount
   and in path form (with UUID as a bonus):

                         loaded active mounted   /media/USERNAME/XXXXXXXX-REAL-UUID-HERE-XXXXXXXXXXXX

3. UUIDs of drives/partitions seem to be masked in some cases, but unmasked versions still slip through all over the place. Mainly as /dev/disk/by-uuid or /dev/disk/by-partuuid

4. running grep -ri serial over the saved folder shows that many lines have Serial number replaced with ellipses:

     hw.info/logs/hwinfo:  Serial ID: "..."
   

   But for some reason, other entries in the same file are not replaced in the same way?
   Then more in hw.info/logs/usb-devices:S: SerialNumber=

   and hw.info/logs/smartctl:Serial Number:
   and hw.info/logs/dmidecode: Serial Number:
   and finally RAM sticks as hw.info/devices:mem:MFG-MODELNUM-serial-ACTUAL_SERIAL_NUM

   Thankfully, at least as far as I can tell, these do get stripped by the time they are stored displayed by the server, but I would have more peace of mind if I didn't see all these being saved.

   I can only assume these show up because they are used for calculation of the ID mentioned here:

   The tool uploads 32-byte prefix of salted SHA512 hash of MAC addresses and serial numbers to properly identify unique computers and hard drives. All the data is uploaded securely via HTTPS.

   And that corresponds to this line hw.info/logs/dmi_id:board_serial: ?

   But if that calculated ID is already written to a file on its own, then 1) does it really need to leave them unmasked in all the constituent files? and 2) is it really using ALL of those to calculate that ID?

5. I haven't (and can't) 100% verify that there's no other uniquely identifying hardware Serial numbers actually stored on the server, but I really wouldn't be surprised if more things are inadvertently slipping through than I've found here, based on the sheer volume of data collected by "-all"

6. Keeping a listing of all installed deb files just seems particularly excessive and irrelevant to hardware.

I know now that I could have / should have limited which logs to upload, but feel a bit mislead by such privacy statements. And I remain skeptical of the usefulness for collecting ALL of this information.

Just grepped over collected logs with latest git version. There still seems to be some serial numbers left? Not all seems to be a real serial number, like the output of hwinfo, which looks like more the device id.

arcconf_smart:       serialNumber : 9616EC7B11C22A9752A4E9698A40FC42
arcconf_smart:       serialNumber : 9616EC7B11C22A9752A4E9698A40FC42
cpuid:      PSN: processor serial number           = 569C712DD5E591AE39A4658DA0549DFB
cpuid:   processor serial number: 3B13CE971D617E1BACAEA29774A69559
dmidecode:		Serial services are supported (int 14h)
dmidecode:	Serial Number: To Be Filled By O.E.M.
dmidecode:	Serial Number: 02AE196EAC3931EEE8481F6F1DE5CFE3
dmidecode:	Serial Number: To Be Filled By O.E.M.
dmidecode:	Serial Number: To Be Filled By O.E.M.
dmidecode:	Port Type: Serial Port 16550A Compatible
dmidecode:	Serial Number: 2C2E502AA613C74B027B56D8EB164493
dmidecode:	Serial Number: 79BABC0E0DD270028F24EDA7D6E66F02
dmidecode:	Serial Number: DA0D9094E6284B14EB66F3A22CA06D8C
dmidecode:	Serial Number: 8E3767E52D628F77D6738AC629550B99
dmidecode:	Serial Number: DF3CB255E3B160C7434E693225BF96A7
dmidecode:	Serial Number: A09C3AF45D079106200F3E9A6D680C2E
dmesg:[    9.450196] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
dmesg:[   10.843120] AAC0: serial 0D511189ED3
usb-devices:S:  SerialNumber=0000:00:1a.7
usb-devices:S:  SerialNumber=0000:00:1d.7
usb-devices:S:  SerialNumber=0000:00:1a.0
usb-devices:S:  SerialNumber=0000:00:1a.1
usb-devices:S:  SerialNumber=0000:00:1a.2
usb-devices:S:  SerialNumber=0000:00:1d.0
usb-devices:S:  SerialNumber=0000:00:1d.1
usb-devices:S:  SerialNumber=0000:00:1d.2
hwinfo:  Serial ID: "1BA0887B68CCEF572FD869CC2F673909"
hwinfo:  Serial ID: "0000:00:1d.0"
hwinfo:  Serial ID: "0000:00:1a.0"
hwinfo:  Serial ID: "0000:00:1d.1"
hwinfo:  Serial ID: "0000:00:1a.1"
hwinfo:  Serial ID: "0000:00:1d.2"
hwinfo:  Serial ID: "0000:00:1a.7"
hwinfo:  Serial ID: "0000:00:1a.2"
hwinfo:  Serial ID: "0000:00:1d.7"
smartctl:Serial number:        606D47AE
ioports:  03f8-03ff : serial
lsusb:  iSerial                 1 ...
lsusb:  iSerial                 1 ...
lsusb:  iSerial                 1 ...
lsusb:  iSerial                 1 ...
lsusb:  iSerial                 1 ...
lsusb:  iSerial                 1 ...
lsusb:  iSerial                 1 ...
lsusb:  iSerial                 1 ...
dmi_id:board_serial: 02AE196EAC3931EEE8481F6F1DE5CFE3
arcconf:         Serial number                      : AA08A0B40FD4625FA17C3C5005D5CD0E
arcconf:         Serial number                      : C695CFC16765E492F76994D5845BB2C9
arcconf:         Serial number                      : 83959B62227F332D4416CC5C946FDDE2
arcconf:         Serial number                      : 23770D42D5FD069DDAB7E9626AFD8093

The boot.log file uploaded (at least) includes information on the location of mount points, like "Mounting /media/ssd" on my ubuntu 16.04 system. These can include private information, e.g. my fstab includes several mounts in my home directory, revealing the username.

Does not seem like these add any value, so they could be stripped from the log or replaced with dummy names.

It would be handy to add a new option of the tool to generate a local HTML page to view the devices list and logs in the probe.

See http://ml.openmandriva.org/pipermail/om-cooker_ml.openmandriva.org/2016-February/000269.html for more info.

We need to include output of vulkaninfo if present.

/snap/core, /snap/spotify, /snap/keepassxc etc. can all be seen in the output. /media/ mounts are anonymized and it would be great if the /snap/ mounts were too.

Ubuntu 18.04.4 LTS
hw-probe results: https://linux-hardware.org/index.php?probe=d87dadfcd6
local lshw report:

The USB 2.0 PC Camera (Alcor) is some-why not listed as a device in the report, although it detects the Toshiba one fine

On openSUSE Tumbleweed ( hw-probe package installed from http://download.opensuse.org/repositories/hardware/openSUSE_Tumbleweed/ ), the following error occurs:

hw-probe -probe -upload
Probe for hardware ... Ok
curl: (25) Chunky upload is not supported by HTTP 1.0
ERROR: failed to upload data, curl error code "25"

Installing the openSUSE Leap15 version ( from respective repo ) worked fine (on the same hardware moments before).

https://linux-hardware.org/?probe=d5de6d141a

Corrections:

Year: 2016

DE: Plasma/Kwin

Not sure how those are being detected.

$ sudo hw-probe -all -upload
Probe for hardware ... Ok
Reading logs ... Ok
ERROR: the probe is larger than 400K
ERROR: failed to upload probe

logs/dmesg.1 is >7 MB.
/root/HW_PROBE/LATEST/ is attached.
I think large logs should be just dropped.

hw.info.tar.gz

Here https://linux-hardware.org/index.php?view=search it would be great to search probes by the distribution, for example, to find all probes made from Rosa or Ubuntu