MX Linux Forum

Posted: **Sun Jan 12, 2020 4:01 pm**

Please register your computer by https://wiki.debian.org/Hardware/Database if you want to contribute to the hardware database and plot statistical report like this Ubuntu report for MX Linux.

At the moment the database for MX includes only 22 occasional computers. Once it reaches a significant size, it will be possible to generate the report and save it to a git repository.

Thanks.

EDIT: The hw-probe package can now be installed from the http://mxrepo.com/mx/testrepo/. You can install it by MX Package Installer / MX Test Repo.

Posted: **Sun Jan 12, 2020 4:08 pm**

Code: Select all

root@mx:~# sudo dpkg -i ./hw-probe_1.4-1_all.deb
Selecting previously unselected package hw-probe.
(Reading database ... 343171 files and directories currently installed.)
Preparing to unpack ./hw-probe_1.4-1_all.deb ...
Unpacking hw-probe (1.4-1) ...
dpkg: dependency problems prevent configuration of hw-probe:
 hw-probe depends on acpica-tools; however:
  Package acpica-tools is not installed.

dpkg: error processing package hw-probe (--install):
 dependency problems - leaving unconfigured
Processing triggers for man-db (2.8.5-2) ...
Errors were encountered while processing:
 hw-probe

Posted: **Sun Jan 12, 2020 4:23 pm**

Running apt-get install -f will bring in the missing dependency (acpica-tools)

Code: Select all

$ sudo apt-get install -f
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Correcting dependencies... Done
The following additional packages will be installed:
  acpica-tools
The following NEW packages will be installed:
  acpica-tools
0 upgraded, 1 newly installed, 0 to remove and 8 not upgraded.
1 not fully installed or removed.
Need to get 843 kB of archives.
After this operation, 2,720 kB of additional disk space will be used.
Do you want to continue? [Y/n] 
Get:1 http://deb.debian.org/debian buster/main amd64 acpica-tools amd64 20181213-1 [843 kB]
Fetched 843 kB in 0s (1,882 kB/s)
Selecting previously unselected package acpica-tools.
(Reading database ... 342859 files and directories currently installed.)
Preparing to unpack .../acpica-tools_20181213-1_amd64.deb ...
Unpacking acpica-tools (20181213-1) ...
Setting up acpica-tools (20181213-1) ...
update-alternatives: using /usr/bin/acpixtract-acpica to provide /usr/bin/acpixtract (acpixtract) in auto mode
update-alternatives: using /usr/bin/acpidump-acpica to provide /usr/bin/acpidump (acpidump) in auto mode
Setting up hw-probe (1.4-1) ...
Processing triggers for man-db (2.8.5-2) ...

Could have also used gdebi to install hw-probe, it installs the acpica-tools dependency automatically.

Posted: **Sun Jan 12, 2020 4:34 pm**

acpica-tools is available in the Buster repo.

However, seems strange that Debian is encouraging people to install non-stable-repo software (hw_probe) in order to collect this info. Why not make hw_probe available in the stable repo? This from the people who brought you https://wiki.debian.org/DontBreakDebian

Posted: **Sun Jan 12, 2020 4:36 pm**

Personal build that I will post here and not where I have to jump through all kinds of hoops. Anyone is welcome to post it where ever.

Code: Select all

System:    Host: mauser Kernel: 5.4.0-8.2-liquorix-amd64 x86_64 bits: 64 compiler: gcc v: 8.3.0 
           parameters: audit=0 BOOT_IMAGE=/vmlinuz-5.4.0-8.2-liquorix-amd64 
           root=UUID=aac372a7-702b-4a89-986c-5da6c2115ee0 ro amdgpu.dpm=0 splash 
           Desktop: Xfce 4.14.1 tk: Gtk 3.24.5 info: xfce4-panel wm: xfwm4 dm: LightDM 1.26.0 
           Distro: MX-19_x64 patito feo October 21  2019 base: Debian GNU/Linux 10 (buster) 
Machine:   Type: Desktop Mobo: Micro-Star model: MPG X570 GAMING EDGE WIFI (MS-7C37) v: 1.0 
           serial: <filter> UEFI: American Megatrends v: 1.60 date: 11/06/2019 
CPU:       Topology: 8-Core model: AMD Ryzen 7 2700X bits: 64 type: MT MCP arch: Zen+ 
           family: 17 (23) model-id: 8 stepping: 2 microcode: 800820D L2 cache: 4096 KiB 
           flags: avx avx2 lm nx pae sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3 svm 
           bogomips: 118386 
           Speed: 3145 MHz min/max: 2200/3700 MHz boost: enabled Core speeds (MHz): 1: 3145 
           2: 2433 3: 2224 4: 2409 5: 3607 6: 2280 7: 2074 8: 2438 9: 2286 10: 2567 11: 2913 
           12: 2183 13: 2361 14: 2388 15: 3439 16: 2675 
           Vulnerabilities: Type: itlb_multihit status: Not affected 
           Type: l1tf status: Not affected 
           Type: mds status: Not affected 
           Type: meltdown status: Not affected 
           Type: spec_store_bypass 
           mitigation: Speculative Store Bypass disabled via prctl and seccomp 
           Type: spectre_v1 mitigation: usercopy/swapgs barriers and __user pointer sanitization 
           Type: spectre_v2 
           mitigation: Full AMD retpoline, IBPB: conditional, STIBP: disabled, RSB filling 
           Type: tsx_async_abort status: Not affected 
Graphics:  Device-1: AMD Baffin [Polaris11] vendor: XFX Pine driver: amdgpu v: kernel 
           bus ID: 2d:00.0 chip ID: 1002:67ff 
           Display: x11 server: X.Org 1.20.4 driver: amdgpu resolution: 1920x1080~60Hz 
           OpenGL: renderer: Radeon RX 550 Series (POLARIS11 DRM 3.35.0 5.4.0-8.2-liquorix-amd64 
           LLVM 7.0.1) 
           v: 4.5 Mesa 18.3.6 direct render: Yes 
Audio:     Device-1: AMD Baffin HDMI/DP Audio [Radeon RX 550 640SP / RX 560/560X] 
           vendor: XFX Pine driver: snd_hda_intel v: kernel bus ID: 2d:00.1 chip ID: 1002:aae0 
           Device-2: AMD Family 17h HD Audio vendor: Micro-Star MSI driver: snd_hda_intel 
           v: kernel bus ID: 2f:00.3 chip ID: 1022:1457 
           Sound Server: ALSA v: k5.4.0-8.2-liquorix-amd64 
Network:   Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet 
           vendor: Micro-Star MSI driver: r8169 v: kernel port: d000 bus ID: 27:00.0 
           chip ID: 10ec:8168 
           IF: eth0 state: up speed: 100 Mbps duplex: full mac: <filter> 
           Device-2: Intel Dual Band Wireless-AC 3168NGW [Stone Peak] driver: iwlwifi v: kernel 
           port: d000 bus ID: 29:00.0 chip ID: 8086:24fb 
           IF: wlan0 state: down mac: <filter> 
           IF-ID-1: tun0 state: unknown speed: 10 Mbps duplex: full mac: N/A 
Drives:    Local Storage: total: 7.28 TiB used: 2.90 TiB (39.9%) 
           ID-1: /dev/sda vendor: HGST (Hitachi) model: HUS728T8TALE6L4 size: 7.28 TiB 
           block size: physical: 4096 B logical: 512 B speed: 6.0 Gb/s rotation: 7200 rpm 
           serial: <filter> rev: W414 scheme: GPT 
Partition: ID-1: / raw size: 7.27 TiB size: 7.22 TiB (99.20%) used: 2.90 TiB (40.2%) fs: ext4 
           dev: /dev/dm-0 
           ID-2: /boot raw size: 512.0 MiB size: 487.9 MiB (95.30%) used: 371.9 MiB (76.2%) 
           fs: ext4 dev: /dev/sda2 
           ID-3: swap-1 size: 1.98 GiB used: 0 KiB (0.0%) fs: swap swappiness: 15 (default 60) 
           cache pressure: 100 (default) dev: /dev/dm-1 
Sensors:   System Temperatures: cpu: 41.9 C mobo: N/A 
           Fan Speeds (RPM): N/A 
Repos:     No active apt repos in: /etc/apt/sources.list 
           Active apt repos in: /etc/apt/sources.list.d/antix.list 
           1: deb http://iso.mxrepo.com/antix/buster buster main
           Active apt repos in: /etc/apt/sources.list.d/debian-stable-updates.list 
           1: deb http://deb.debian.org/debian buster-updates main contrib non-free
           Active apt repos in: /etc/apt/sources.list.d/debian.list 
           1: deb http://deb.debian.org/debian buster main contrib non-free
           2: deb http://deb.debian.org/debian-security buster/updates main contrib non-free
           Active apt repos in: /etc/apt/sources.list.d/mx.list 
           1: deb http://mxrepo.com/mx/repo/ buster main non-free
           No active apt repos in: /etc/apt/sources.list.d/various.list 
Info:      Processes: 341 Uptime: 3h 46m Memory: 11.71 GiB used: 1.47 GiB (12.6%) Init: SysVinit 
           v: 2.93 runlevel: 5 default: 5 Compilers: gcc: 8.3.0 alt: 8 Shell: bash v: 5.0.3 
           running in: quick-system-in inxi: 3.0.36

Posted: **Sun Jan 12, 2020 4:37 pm**

Mine is uploaded:
https://linux-hardware.org/?probe=f10553e785

Posted: **Sun Jan 12, 2020 5:06 pm**

Debian has hw-probe 1.4 in Sid, so I'll see about backporting it.

Edit: OK, sending to test repo, but can be downloaded and installed early: https://drive.google.com/open?id=1DGxXw ... rhSzeuRE9c

Posted: **Sun Jan 12, 2020 6:15 pm**

imschmeg wrote: Sun Jan 12, 2020 4:34 pm acpica-tools is available in the Buster repo.

However, seems strange that Debian is encouraging people to install non-stable-repo software (hw_probe) in order to collect this info. Why not make hw_probe available in the stable repo? This from the people who brought you https://wiki.debian.org/DontBreakDebian

acpica-tools is also available in the Stretch repo.

But, yes that does seem strange.

Posted: **Mon Jan 13, 2020 7:49 am**

Paul just upgraded the install instructions on the page to be more secure and safe for the system: https://wiki.debian.org/Hardware/Database

Posted: **Mon Jan 13, 2020 8:17 am**

My opinion on all this is that it constitutes a terrific hardware resource for MX, and that I hope people will make use of it. I added my personal machine and the whole process was quick and impressive.

Sure beats a Wiki entry...

Posted: **Mon Jan 13, 2020 8:18 am**

linuxbuild wrote: Mon Jan 13, 2020 7:49 am Paul just upgraded the install instructions on the page to be more secure and safe for the system: https://wiki.debian.org/Hardware/Database

IIUC, the idea of the Privacy notice:

wiki.debian.org/Hardware/Database wrote:Privacy
Private information (including the username, machine's hostname, IP addresses, MAC addresses and serial numbers) is NOT uploaded to the database.

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.

is to convince the user the data uploaded are in a kind anonymized.
OTHO, I do see UUID's in the uploaded data, which are fairly unique to the devices. Wouldn't it be more privacy focused to get those UUID's also hashed or randomized.

Posted: **Mon Jan 13, 2020 8:28 am**

Some MX probes are currently counted as Debian probes, e.g. this one. Why `lsb_release -a` may report Debian instead of MX on some systems?

Posted: **Mon Jan 13, 2020 8:34 am**

linuxbuild wrote: Mon Jan 13, 2020 8:28 am Some MX probes are currently counted as Debian probes, e.g. this one. Why `lsb_release -a` may report Debian instead of MX on some systems?

That's mine.

My install is from MX-19beta-2.1, I'm not sure what `lsb_release -a` shows on the final release of MX-19.

Posted: **Mon Jan 13, 2020 8:48 am**

Code: Select all

└─> lsb_release -a
No LSB modules are available.
Distributor ID:	Debian
Description:	Debian GNU/Linux 10 (buster)
Release:	10
Codename:	buster

Posted: **Mon Jan 13, 2020 9:05 am**

fehlix wrote: Mon Jan 13, 2020 8:18 am OTHO, I do see UUID's in the uploaded data, which are fairly unique to the devices. Wouldn't it be more privacy focused to get those UUID's also hashed or randomized.

Let's hide them. I'll try to prepare a patch tomorrow morning.

Posted: **Mon Jan 13, 2020 10:15 am**

fehlix wrote: Mon Jan 13, 2020 8:18 am
wiki.debian.org/Hardware/Database wrote:Privacy
Private information (including the username, machine's hostname, IP addresses, MAC addresses and serial numbers) is NOT uploaded to the database.

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.
is to convince the user the data uploaded are in a kind anonymized.

I think this is a great project as far as the concept is concerned.

I would like to see official Collection, Usage, and Privacy policies (I couldn't find these)
"Privacy Notes" just doesn't cut it imho.

Also not sure why hw-probe is under the GPL, but hwinfo is under Creative Commons, but I assume there is a reason.

Pardon my ignorance with the next question, because I haven't installed this yet, but does and can the user see/review the actual data collected prior to it being uploaded?

Edit: added "Collection" to Usage and Privacy sentence.

Posted: **Mon Jan 13, 2020 10:43 am**

linuxbuild wrote: Mon Jan 13, 2020 8:28 am Some MX probes are currently counted as Debian probes, e.g. this one. Why `lsb_release -a` may report Debian instead of MX on some systems?

The same problem happened to me. I did a probe on my MX-18.3 system on 2 Dec 19 which shows my system as Debian 10 instead of MX.

This https://linux-hardware.org/?probe=a06c7f57fe is the upload. The banner on the top of the page says "MX Hardware" but down a bit under Host Info and System it says Debian 10 and my upload is displayed under the Debian and not MX results.

Contrast my upload with the one kmathern said was his (post #13), the banner on the top says "MX Hardware" like mine, but under "Host Info" and "System" his says MX 19.

Running "lsb_release -a" shows

Code: Select all

No LSB modules are available.
Distributor ID:	MX
Description:	MX 18.3 Continuum
Release:	18.3
Codename:	Continuum

Edit: Regarding the question about seeing the data before it is uploaded. Not when I did mine in December 2019. It was all automatic with just a simple response in the Terminal displaying the URL of the upload after the probe was finished.

Posted: **Mon Jan 13, 2020 10:49 am**

Stuart_M wrote: Mon Jan 13, 2020 10:43 am Contrast my upload with the one kmathern said was his (post #13), the banner on the top says "MX Hardware" like mine, but under "Host Info" and "System" his says MX 19.

Mine originally said "Debian 10" in the "Host Info" section.

Someone (linuxbuild ?) changed it to "MX 19" after I made post #13.

Posted: **Mon Jan 13, 2020 12:32 pm**

They seem to have changed in buster where lsb_release get's defaults from:
indicated here with the first lines from diff of libs used ( /usr/lib/python3/dist-packages/lsb_release.py )

Code: Select all

$ diff lsb_release.py.MX18.txt    lsb_release.py.MX19.txt
4a5
< # Whatever is guessed above can be overridden in /etc/lsb-release
< def get_lsb_information():
---
> # Whatever is guessed above can be overridden in /usr/lib/os-release by derivatives
> def get_os_release():

In MX18 /stretch lsb_release info comes from /etc/lsb-release
In MX19 /buster they seem to ignore /etc/lsb-release and get it from /usr/lib/os-release
So "lsb_release -a" to get version/release info is currently not reliable in MX-19 as it ignores /etc/lsb-release

Code: Select all

==> /etc/lsb-release <==
PRETTY_NAME="MX 19 patito feo"
DISTRIB_ID=MX
DISTRIB_RELEASE=19
DISTRIB_CODENAME="patito feo"
DISTRIB_DESCRIPTION="MX 19 patito feo"

and takes all values from /etc/os-release -> /usr/lib/os-release

Code: Select all

==> /usr/lib/os-release <==
PRETTY_NAME="Debian GNU/Linux 10 (buster)"
NAME="Debian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"

Posted: **Mon Jan 13, 2020 6:29 pm**

Since we now have hwprobe in the MX 17-19 test repos, can we get the installation instructions changed in the first post to installing it from there with MX Package Installer?

Posted: **Mon Jan 13, 2020 6:59 pm**

Selecting hw-probe from MXPI:

Code: Select all

...
The following NEW packages will be installed:
  acpica-tools cpuid edid-decode hw-probe i2c-tools iw libi2c0 memtester
  vdpauinfo vulkan-tools vulkan-utils

Wow - it's a very needy tool!

Posted: **Mon Jan 13, 2020 7:11 pm**

I disconnected from the network, and ran 'sudo hw-probe -all' without the -upload. It puts its info in /root/HW_PROBE/LATEST/hw.info/ - and there is a lot, if anyone wants to walk through it to figure out if it's already anonymized sufficiently. Or you can just hope the -upload does enough anonymizing. My own preference is to examine it...

Posted: **Mon Jan 13, 2020 7:19 pm**

OK - I'm spooked. There's stuff in /root/HW_PROBE/LATEST/hw.info that I would not want to fall into the wrong hands. So, I'm going to have to see the anonymized output before cooperating further with this request, even though I very much sympathize with the intention.

Posted: **Mon Jan 13, 2020 8:56 pm**

1. After reading the first two paragraphs of this project's website I see a major flaw in the entire concept: people with incompatible hardware are less-likely to upload their computer's data than are people with systems that are working well, skewing your data and leading to false conclusions.

They're most likely too busy trying to solve their computer issue or have gone distro-hopping

If their issues are to do with networking, lock-ups or crashes they can't upload their data even if they wanted to

So if the purpose of this database is to get an idea about the percentage of incompatible hardware out in the wild, you're not going to get accurate data. It's going to be skewed in favor of the number of working systems.

2. I'm still extremely hinky about giving away my information. Under Privacy the site says "Most private info is not collected or hashed." (italics mine.) It doesn't say what private info is collected unhashed. It also doesn't spell out in detail exactly what is being done with the data. I want to see everything spelled out in detail: exactly what data is being collected, which of those items are hashed and which are saved in the clear, and in minute detail who is using this data and for what purposes. I also want to know who is behind this project: name, age location a photo, their background, etc. Right now I see an unknown random stranger on the Internet trying to get me to send him a bunch of data about (and from) my computer, and that's a great big fat red flag!

Lastly, after linuxbuild's recent flood of replies to multiple help request topics trying to convince as many people as possible to run this utility and share their data I'm frankly very suspicious and skeptical. I wonder what his role in the project may be, and exactly why collecting as much information as possible as soon as possible is so important to him at this time. My experience is that when people behave this way they're often up to no good. No disclosure, no privacy agreement, no nothing means no data, no way as far as I'm concerned.

Posted: **Mon Jan 13, 2020 10:54 pm**

imschmeg wrote: Mon Jan 13, 2020 6:59 pm Selecting hw-probe from MXPI:
Code: Select all
...
The following NEW packages will be installed:
  acpica-tools cpuid edid-decode hw-probe i2c-tools iw libi2c0 memtester
  vdpauinfo vulkan-tools vulkan-utils
Wow - it's a very needy tool!

I changed the Recommends that Debian has to hard dependencies for MX, so it would also pull those in by default on Debian.

Posted: **Tue Jan 14, 2020 7:57 am**

linuxbuild wrote: Mon Jan 13, 2020 9:05 am
fehlix wrote: Mon Jan 13, 2020 8:18 am OTHO, I do see UUID's in the uploaded data, which are fairly unique to the devices. Wouldn't it be more privacy focused to get those UUID's also hashed or randomized.
Let's hide them. I'll try to prepare a patch tomorrow morning.

Fixed in master: https://github.com/linuxhw/hw-probe/com ... 0fa4cbac43

It will be a part of the 1.5, that will be released on January 15.

Posted: **Wed Jan 15, 2020 12:54 am**

kmathern wrote: Mon Jan 13, 2020 10:49 am
Stuart_M wrote: Mon Jan 13, 2020 10:43 am Contrast my upload with the one kmathern said was his (post #13), the banner on the top says "MX Hardware" like mine, but under "Host Info" and "System" his says MX 19.
Mine originally said "Debian 10" in the "Host Info" section.

Someone (linuxbuild ?) changed it to "MX 19" after I made post #13.

Yep. MX is detected now by matching related installed packages if failed to detect by lsb_release or /etc/os-release. But this doesn't work for Flatpak package since the list of installed packages is not accessible.

Posted: **Wed Jan 15, 2020 12:58 am**

imschmeg wrote: Mon Jan 13, 2020 7:19 pm OK - I'm spooked. There's stuff in /root/HW_PROBE/LATEST/hw.info that I would not want to fall into the wrong hands. So, I'm going to have to see the anonymized output before cooperating further with this request, even though I very much sympathize with the intention.

What particular data or files you don't want to share? Probably this is already fixed in master.

Posted: **Wed Jan 15, 2020 1:22 am**

fehlix wrote: Mon Jan 13, 2020 12:32 pm In MX18 /stretch lsb_release info comes from /etc/lsb-release
In MX19 /buster they seem to ignore /etc/lsb-release and get it from /usr/lib/os-release
So "lsb_release -a" to get version/release info is currently not reliable in MX-19 as it ignores /etc/lsb-release

Added a patch to hw-probe 1.5 to collect /etc/lsb-release.

Thank you.

Posted: **Wed Jan 15, 2020 1:41 am**

What particular data or files you don't want to share? Probably this is already fixed in master.

I deleted /root/HW_PROBE. The one thing I saw in the data collected there in particular that spooked me was details about crypto usage, including salt. I didn't bother to look further than that.

It may be that the intention is to have hw-probe gather as much info as it can locally, and then filter it heavily before anonymizing and uploading. But the steps in that have to be made much more transparent.

Posted: **Wed Jan 15, 2020 2:02 am**

imschmeg wrote: Wed Jan 15, 2020 1:41 am
What particular data or files you don't want to share? Probably this is already fixed in master.
I deleted /root/HW_PROBE. The one thing I saw in the data collected there in particular that spooked me was details about crypto usage, including salt. I didn't bother to look further than that.

It may be that the intention is to have hw-probe gather as much info as it can locally, and then filter it heavily before anonymizing and uploading. But the steps in that have to be made much more transparent.

Currently you can upload data in three steps: 1) hw-probe -all, 2) verify&edit /root/HW_PROBE, 3) hw-probe -upload

Ideally we should remove all suspicious strings automatically from logs and make step 2 unnecessary.

BTW Just added a patch to remove collected data from /root/HW_PROBE after uploading.

Posted: **Wed Jan 15, 2020 7:33 am**

JayM wrote: Mon Jan 13, 2020 8:56 pm 1. After reading the first two paragraphs of this project's website I see a major flaw in the entire concept: people with incompatible hardware are less-likely to upload their computer's data than are people with systems that are working well, skewing your data and leading to false conclusions.

They're most likely too busy trying to solve their computer issue or have gone distro-hopping

If their issues are to do with networking, lock-ups or crashes they can't upload their data even if they wanted to
So if the purpose of this database is to get an idea about the percentage of incompatible hardware out in the wild, you're not going to get accurate data. It's going to be skewed in favor of the number of working systems.

2. I'm still extremely hinky about giving away my information. Under Privacy the site says "Most private info is not collected or hashed." (italics mine.) It doesn't say what private info is collected unhashed. It also doesn't spell out in detail exactly what is being done with the data. I want to see everything spelled out in detail: exactly what data is being collected, which of those items are hashed and which are saved in the clear, and in minute detail who is using this data and for what purposes. I also want to know who is behind this project: name, age location a photo, their background, etc. Right now I see an unknown random stranger on the Internet trying to get me to send him a bunch of data about (and from) my computer, and that's a great big fat red flag!

1. Sounds reasonable, but not actually true. 75% of uploaded probes don't contain any issues or unsupported devices. Reason to upload — check if everything works fine.

2.

I want to see everything spelled out in detail: exactly what data is being collected, which of those items are hashed and which are saved in the clear

There are two ways here:

a) Make a probe by three steps: hw-probe -all, review collected data in /root/HW_PROBE, hw-probe -upload
b) Examine the collector source code: https://github.com/linuxhw/hw-probe/blo ... w-probe.pl

Probably you'd better to use a Flatpak instead because it denies access to a meaningful info on your computer.

who is using this data and for what purposes

My work on the current and all previous positions is based on Linux. I love it. So I want to contribute to the Linux (kernel/distribution) development somehow.

Also interested to plot statistical reports like https://github.com/linuxhw/SMART based on the collected probes.

I also want to know who is behind this project: name, age location a photo, their background, etc.

Name, photo, some background, commits: https://github.com/lvc

Age 33, home location can be found by whois, work location is currently Seattle, USA.

Thanks.

Posted: **Wed Jan 15, 2020 7:37 am**

Released hw-probe 1.5 implementing requests from this thread.

Posted: **Wed Jan 15, 2020 10:19 am**

linuxbuild wrote: Wed Jan 15, 2020 7:37 am Released hw-probe 1.5 implementing requests from this thread.

looks promising...
version 1.5 shows still some UUID's ( in form of PARTUUID),
as efibootmgr lists NVRAM entries which seem to have PARTUUID's stored:

Code: Select all

$ grep $(lsblk -no PARTUUID /dev/vda1) ./HW_PROBE/LATEST/hw.info/logs/*
./HW_PROBE/LATEST/hw.info/logs/efibootmgr:Boot0009* MX19-Linux	HD(1,GPT,838ada09-1434-4769-8883-34ccd995ed76,0x800,0x7ed0d)/File(\EFI\MX19u\grubx64.efi)
./HW_PROBE/LATEST/hw.info/logs/efibootmgr:Boot000A* rEFInd Boot Manager	HD(1,GPT,838ada09-1434-4769-8883-34ccd995ed76,0x800,0x7ed0d)/File(\EFI\refind\refind_x64.efi)

Posted: **Thu Jan 16, 2020 6:55 am**

fehlix wrote: Wed Jan 15, 2020 10:19 am
linuxbuild wrote: Wed Jan 15, 2020 7:37 am Released hw-probe 1.5 implementing requests from this thread.
looks promising...
version 1.5 shows still some UUID's ( in form of PARTUUID),
as efibootmgr lists NVRAM entries which seem to have PARTUUID's stored:
Code: Select all
$ grep $(lsblk -no PARTUUID /dev/vda1) ./HW_PROBE/LATEST/hw.info/logs/*
./HW_PROBE/LATEST/hw.info/logs/efibootmgr:Boot0009* MX19-Linux	HD(1,GPT,838ada09-1434-4769-8883-34ccd995ed76,0x800,0x7ed0d)/File(\EFI\MX19u\grubx64.efi)
./HW_PROBE/LATEST/hw.info/logs/efibootmgr:Boot000A* rEFInd Boot Manager	HD(1,GPT,838ada09-1434-4769-8883-34ccd995ed76,0x800,0x7ed0d)/File(\EFI\refind\refind_x64.efi)

Fixed in master. You can skip uploading of it currently by -disable efibootmgr additional option.

Thank you.

MX Linux Forum

The database of hardware

The database of hardware

Re: The database of hardware

Re: The database of hardware

Re: The database of hardware

Re: The database of hardware

Re: The database of hardware

Re: The database of hardware

Re: The database of hardware

Re: The database of hardware

Re: The database of hardware

Re: The database of hardware

Re: The database of hardware

Re: The database of hardware

Re: The database of hardware

Re: The database of hardware

Re: The database of hardware

Re: The database of hardware

Re: The database of hardware

Re: The database of hardware

Re: The database of hardware

Re: The database of hardware

Re: The database of hardware

Re: The database of hardware

Re: The database of hardware

Re: The database of hardware

Re: The database of hardware

Re: The database of hardware

Re: The database of hardware

Re: The database of hardware

Re: The database of hardware

Re: The database of hardware

Re: The database of hardware

Re: The database of hardware

Re: The database of hardware

Re: The database of hardware