Invalid machine names for desktop motherboards (?)

[uttarayan21]

Hello. I was using windows 11 / Linux. I installed macchina from master using cargo install --git https://github.com/macchina-cli/macchina On both machines it shows up as the following. Edit: Added linux screenshot

Also sorry for the absence I have been really busy with work for a while. Hopefully I can find some time to work on some of the issues now.

Edit: It should be Asus Z790-P or similar but instead is ASUS System Product Name

[grtcdr]

That's weird... That kernel also looks incorrect I think.

Also sorry for the absence I have been really busy with work for a while. Hopefully I can find some time to work on some of the issues now.

No worries, glad you're back.

[uttarayan21]

Oh yeah. I didn't notice the weird kernel at all.

[grtcdr]

I'll try and see if there were any regressions in recent commits. I'd love to cherrypick my through the commits but I don't have a Windows machine to test with, we also don't know if this can be reproduced yet.

[uttarayan21]

Hmm I'm not sure if this is a bug specifically on windows. This happens on linux as well.

Also this is not a oem manufactured desktop maybe that's why the relevant parts are placeholder text ?

[grtcdr]

I went as far back as 5142f0a (a year ago) and nothing from the commit log looks suspicious, no changes were even introduced in the relevant functions.

[grtcdr]

Hmm I'm not sure if this is a bug specifically on windows. This happens on linux as well

I suppose some machines just simply don't report their information correctly. There isn't, AFAIK, a good and sensible way to compose the "name" of machine.

[grtcdr]

Also this is not a oem manufactured desktop maybe that's why the relevant parts are placeholder text ?

I don't know, the only way to tell is to use the Windows registry and hunt the components down and see whether the manufacturer bothered to name the product.

[uttarayan21]

I cat-ed the files in /sys/class/dmi/id

I think the interesting ones are

board_name: PRIME Z790-P
board_vendor: ASUSTeK COMPUTER INC.
board_version: Rev 1.xx
bios_vendor: American Megatrends Inc.
sys_vendor: ASUS

Other ones which are probably causing the issue

product_family: To be filled by O.E.M.
product_name: System Product Name
product_version: System Version

[grtcdr]

What do you think we assume about non-OEM electronics that we can translate into a function that handles all these weird edge cases?

Is there some sort of documentation we can follow to implement a one-size-fits-all function?

I see here that the contents of product_ files contain these placeholders, but can we assume that other non-OEM electronics will display this exact string as well?

[uttarayan21]

Hmmm. I'm not really sure If these can be handled without having a at least a few examples of what /sys/class/dmi/id contains for a few people and then we'd also have to look into how to get those from windows as well.

Can't really be sure without checking what other vendors fill in their product names as a place holder.

[Gobidev]

@uttarayan21 this function from pfetch probably helps: https://github.com/dylanaraps/pfetch/blob/master/pfetch#L453 I have a host() function in one of my Rust projects (https://github.com/Gobidev/pfetch-rs/blob/1a188977236ba6e1f34bfecb6634d931c5fad927/src/lib.rs#L279) that uses the same method for Unix host detection.

It basically uses a blacklist of known generic values and filters them out of the final string. I know of at least two computers that I have access to which also have a generic output, that might be enough to confirm which values need to be filtered.

[uttarayan21]

Oh that's very useful. @grtcdr Should I make a pr that implements this ?

[grtcdr]

Sure, that'd be great!