Unique ID for computer - Motherboard

[tsdnz]

Hi all,

I need a Unique ID from the motherboard or BIOS??
Is this possible.

I cannot use Ethernet as cards might change.

Does anyone have any ideas how to get this?
The ID must be the same each time the OS boots.

Alistair.

[madanra]

This is not really possible, though depending on what you want it for, there might be approximations which would work for you. For example, if you're just wanting to identify the installation, the UUID of the partition your OS is installed to might be sufficient, though this could cause problems if the disk is cloned.

[tsdnz]

Thanks, I was having trouble finding a solution.
I will code in Ethernet MAC and allow for changes when alerting.

[iansjack]

This information should be available from the System Management BIOS Data tables: http://wiki.osdev.org/System_Management_BIOS

[tsdnz]

This information should be available from the System Management BIOS Data tables: http://wiki.osdev.org/System_Management_BIOS

Thanks, what part should I look for in the SMBIOS?
Does it have a Unique ID?

[iansjack]

You could have a look at the source of dmidecode: https://wiki.debian.org/HowToIdentifyADevice/System

There should be a unique Serial Number in the BIOS.

[tsdnz]

You could have a look at the source of dmidecode: https://wiki.debian.org/HowToIdentifyADevice/System

There should be a unique Serial Number in the BIOS.

As usual I am right in the middle of some code, I plan to have a look shortly.

Brilliant, thanks.

[Combuster]

If you really need your OS to have one globally unique ID every time, then there are so many things that can go wrong as well, that makes me wonder what proper use such a feature is.

People who send their computer in for repairs often find themselves with a replaced motherboard, and therefore changed ID. People can upgrade their hardware in bits, and then suddenly things stop working because of a new motherboard. And security-related, every commercial software company will try to get hold of that ID so they can do perfect tracking across all apps.

Basically it sounds like a design choice you will end up regretting later,

[tsdnz]

If you really need your OS to have one globally unique ID every time, then there are so many things that can go wrong as well, that makes me wonder what proper use such a feature is.

People who send their computer in for repairs often find themselves with a replaced motherboard, and therefore changed ID. People can upgrade their hardware in bits, and then suddenly things stop working because of a new motherboard. And security-related, every commercial software company will try to get hold of that ID so they can do perfect tracking across all apps.

Basically it sounds like a design choice you will end up regretting later,

The OS is not for general consumption.
It is to track the server in a grid environment when multiple Ethernet cards are sending start-up messages to the hub controller(s) and to display alerts to a human that a server is down / up / etc...
I have given it some thought and the Ethernet cards MAC xor'ed will do fine.
If the server is getting a new [something] it will be removed from service anyway.

Sorry to be vague.
I know where I am heading, the path has a few curves in it here and there, this is just a kink.

Worked many hours yesterday.
Was not impressed with my Ethernet transmit speed, averages 10,000 TX sends per second with 8 cores all trying to send.
I can send in bulk but also want fast single transfers.
During the night I have found a solution, this is today's project to implement and test.
Edit: This is only 15 MB / sec
Edit: Allocates data for frame to send, set ups frame data (simple broadcast) and also releases memory after frame sent.
Edit: I have a 48 core turning up today, 128 GB, 4 x 1GB Ethernet cards, looking forward to testing OS on this.

Many thanks for your comments,
Alistair

[azblue]

If you really need your OS to have one globally unique ID every time, then there are so many things that can go wrong as well, that makes me wonder what proper use such a feature is.

I've considered something like this:
At bootup, while in real mode, read a file which specifies the desired video mode, then call the BIOS and change to that mode. When the OS is up and running, if the user wants to change the screen mode it will overwrite the value in that file and reboot.

If you're booting from a removable device, it's possible that you may boot the OS from a different computer that doesn't support the desired video mode; a unique ID can help determine whether or not you're booting from the same computer you did last time. If you're not, it can use a safe mode like 640x480x16.

(Granted, this isn't the only solution here; you can check to see if the desired mode is supported without caring whether or not you've booted from this computer before).

[tsdnz]

I've considered something like this:
At bootup, while in real mode, read a file which specifies the desired video mode, then call the BIOS and change to that mode. When the OS is up and running, if the user wants to change the screen mode it will overwrite the value in that file and reboot.

If you're booting from a removable device, it's possible that you may boot the OS from a different computer that doesn't support the desired video mode; a unique ID can help determine whether or not you're booting from the same computer you did last time. If you're not, it can use a safe mode like 640x480x16.

(Granted, this isn't the only solution here; you can check to see if the desired mode is supported without caring whether or not you've booted from this computer before).

Thanks, Most of the servers the OS is running on do not have hard drives or screens.

[Combuster]

If you're booting from a removable device, it's possible that you may boot the OS from a different computer that doesn't support the desired video mode; a unique ID can help determine whether or not you're booting from the same computer you did last time. If you're not, it can use a safe mode like 640x480x16.

And when you had a screen or video card replaced, your unique ID stayed the same and your screen still burns out.

Point is that you should identify based on what you need identified, not by some poorly defined metric. If you want to check if your video setup changed, check the video card and DDC data but nothing else. No global ID of which you don't know when it changes or when it does not.

Also, if you want to boot from your stick on a different computer, you expect most things to be the same where possible, not to find everything reset because some ID changed.

[azblue]

And when you had a screen or video card replaced, your unique ID stayed the same and your screen still burns out.

D'OH!
You're absolutely correct; I'll toss my ID idea. Thank for your input

[Brendan]

Hi,

I've considered something like this:
At bootup, while in real mode, read a file which specifies the desired video mode, then call the BIOS and change to that mode. When the OS is up and running, if the user wants to change the screen mode it will overwrite the value in that file and reboot.

I typically do something similar; except that the "desired video mode" is several optional fields (desired horizontal resolution, desired vertical resolution, desired colour depth and/or desired refresh rate). The boot code gets the list of video modes that the video card supports and filters out anything my OS can't use; then uses heuristics to determine several scores for each video mode (how likely it is that the video mode will work reliably, how much the OS would prefer the video mode, how much the monitor would prefer the video mode, and how much the video mode matches the user's preferences) and combines them into a total score; and then chooses the video mode with the best total score. This means that if the user says they want a 1234*567 video mode they might get 1440*1050 on one computer (because it happens to match the monitor's native resolution), 1024*768 on another computer (because the video card is old) and 800*600 on a third computer (because the OS decided the CPU is too slow to render higher resolution graphics).


Cheers,

Brendan