Linux change hardware id

Posted on Sa 26 Juni 2010

On IDs

When programming software that cooperates with software running on behalf of other users, other sessions or other computers it is often necessary to work with unique identifiers. These can be bound to various hardware and software objects as well as lifetimes. Often, when people look for such an ID to use they pick the wrong one because semantics and lifetime or the IDs are not clear. Here’s a little incomprehensive list of IDs accessible on Linux and how you should or should not use them.

Hardware IDs

1. /sys/class/dmi/id/product_uuid: The main board product UUID, as set by the board manufacturer and encoded in the BIOS DMI information. It may be used to identify a mainboard and only the mainboard. It changes when the user replaces the main board. Also, often enough BIOS manufacturers write bogus serials into it. In addition, it is x86-specific. Access for unprivileged users is forbidden. Hence it is of little general use.
2. CPUID/EAX=3 CPU serial number: A CPU UUID, as set by the CPU manufacturer and encoded on the CPU chip. It may be used to identify a CPU and only a CPU. It changes when the user replaces the CPU. Also, most modern CPUs don’t implement this feature anymore, and older computers tend to disable this option by default, controllable via a BIOS Setup option. In addition, it is x86-specific. Hence this too is of little general use.
3. /sys/class/net/*/address: One or more network MAC addresses, as set by the network adapter manufacturer and encoded on some network card EEPROM. It changes when the user replaces the network card. Since network cards are optional and there may be more than one the availability if this ID is not guaranteed and you might have more than one to choose from. On virtual machines the MAC addresses tend to be random. This too is hence of little general use.
4. /sys/bus/usb/devices/*/serial: Serial numbers of various USB devices, as encoded in the USB device EEPROM. Most devices don’t have a serial number set, and if they have it is often bogus. If the user replaces his USB hardware or plugs it into another machine these IDs may change or appear in other machines. This hence too is of little use.

There are various other hardware IDs available, many of which you may discover via the ID_SERIAL udev property of various devices, such hard disks and similar. They all have in common that they are bound to specific (replacable) hardware, not universally available, often filled with bogus data and random in virtualized environments. Or in other words: don’t use them, don’t rely on them for identification, unless you really know what you are doing and in general they do not guarantee what you might hope they guarantee.

Software IDs

1. /proc/sys/kernel/random/boot_id: A random ID that is regenerated on each boot. As such it can be used to identify the local machine’s current boot. It’s universally available on any recent Linux kernel. It’s a good and safe choice if you need to identify a specific boot on a specific booted kernel.
2. gethostname(), /proc/sys/kernel/hostname: A non-random ID configured by the administrator to identify a machine in the network. Often this is not set at all or is set to some default value such as localhost and not even unique in the local network. In addition it might change during runtime, for example because it changes based on updated DHCP information. As such it is almost entirely useless for anything but presentation to the user. It has very weak semantics and relies on correct configuration by the administrator. Don’t use this to identify machines in a distributed environment. It won’t work unless centrally administered, which makes it useless in a globalized, mobile world. It has no place in automatically generated filenames that shall be bound to specific hosts. Just don’t use it, please. It’s really not what many people think it is. gethostname() is standardized in POSIX and hence portable to other Unixes.
3. IP Addresses returned by SIOCGIFCONF or the respective Netlink APIs: These tend to be dynamically assigned and often enough only valid on local networks or even only the local links (i.e. 192.168.x.x style addresses, or even 169.254.x.x/IPv4LL). Unfortunately they hence have little use outside of networking.
4. gethostid(): Returns a supposedly unique 32-bit identifier for the current machine. The semantics of this is not clear. On most machines this simply returns a value based on a local IPv4 address. On others it is administrator controlled via the /etc/hostid file. Since the semantics of this ID are not clear and most often is just a value based on the IP address it is almost always the wrong choice to use. On top of that 32bit are not particularly a lot. On the other hand this is standardized in POSIX and hence portable to other Unixes. It’s probably best to ignore this value and if people don’t want to ignore it they should probably symlink /etc/hostid to /var/lib/dbus/machine-id or something similar.
5. /var/lib/dbus/machine-id: An ID identifying a specific Linux/Unix installation. It does not change if hardware is replaced. It is not unreliable in virtualized environments. This value has clear semantics and is considered part of the D-Bus API. It is supposedly globally unique and portable to all systems that have D-Bus. On Linux, it is universally available, given that almost all non-embedded and even a fair share of the embedded machines ship D-Bus now. This is the recommended way to identify a machine, possibly with a fallback to the host name to cover systems that still lack D-Bus. If your application links against libdbus, you may access this ID with dbus_get_local_machine_id(), if not you can read it directly from the file system.
6. /proc/self/sessionid: An ID identifying a specific Linux login session. This ID is maintained by the kernel and part of the auditing logic. It is uniquely assigned to each login session during a specific system boot, shared by each process of a session, even across su/sudo and cannot be changed by userspace. Unfortunately some distributions have so far failed to set things up properly for this to work (Hey, you, Ubuntu!), and this ID is always (uint32_t) -1 for them. But there’s hope they get this fixed eventually. Nonetheless it is a good choice for a unique session identifier on the local machine and for the current boot. To make this ID globally unique it is best combined with /proc/sys/kernel/random/boot_id.
7. getuid(): An ID identifying a specific Unix/Linux user. This ID is usually automatically assigned when a user is created. It is not unique across machines and may be reassigned to a different user if the original user was deleted. As such it should be used only locally and with the limited validity in time in mind. To make this ID globally unique it is not sufficient to combine it with /var/lib/dbus/machine-id, because the same ID might be used for a different user that is created later with the same UID. Nonetheless this combination is often good enough. It is available on all POSIX systems.
8. ID_FS_UUID: an ID that identifies a specific file system in the udev tree. It is not always clear how these serials are generated but this tends to be available on almost all modern disk file systems. It is not available for NFS mounts or virtual file systems. Nonetheless this is often a good way to identify a file system, and in the case of the root directory even an installation. However due to the weakly defined generation semantics the D-Bus machine ID is generally preferrable.

Generating IDs

Linux offers a kernel interface to generate UUIDs on demand, by reading from /proc/sys/kernel/random/uuid. This is a very simple interface to generate UUIDs. That said, the logic behind UUIDs is unnecessarily complex and often it is a better choice to simply read 16 bytes or so from /dev/urandom.

Summary

And the gist of it all: Use /var/lib/dbus/machine-id! Use /proc/self/sessionid! Use /proc/sys/kernel/random/boot_id! Use getuid()! Use /dev/urandom! And forget about the rest, in particular the host name, or the hardware IDs such as DMI. And keep in mind that you may combine the aforementioned IDs in various ways to get different semantics and validity constraints.

Источник

Hardware-ID Device Driver for Linux

Download

Please note that the «Quickstarters guide to procfs programming» is part of the driver and is not available for download separately.

Short description

Basically, you can use this to assigne any hardware id to an application that thinks it cannot live with what your system provides as the default. This is mostly the case when you restore a backup to a new hard disk or want to change your Ethernet card while some application depend on the mac address or the drive id of the old hardware.

An other thing is security. There are some commercial programs out in the wild, that try to send personal information to people you don’t trust or even know. Sending hardware IDs is a popular way to track users through the WEB. If you have to use such software, this module helps you to decide what information you want to give out.

The new version contains a feature that records all accesses to hardware IDs and present this to the user via the procfs interface.

Supported features

— MAC addresses of Ethernet cards

Programmers point of view

The module is a very small and readable piece of source demonstrating system call interception and use of the proc file system. If you want to add proc file system support for you own driver you might want to take a look at this module.

I wrote a little tutorial on how to use the procfs in kernel 2.4. It is called «Quickstarters guide to procfs programming» and could be useful to people how want to add procfs support to there own modules. The file is written in LaTeX and includes parts of the module source code. Please check out the current CVS or the tar ball to read it.

— Why don’t older MAC settings work with newer kernels?

New kernel releases changed the size of the MAC field entry. You simply have to add zeros to your old settings to make it work with newer kernel versions. A tail -f /var/log/messages shows you the expected number of digits.

— Can I use this driver to run stolen commercial software XXX on my Linux box?

Don’t ask! I do not support software piracy. Please use this driver only if you have a legal license for your software but have to work around technical difficulties with your license manager.

— Removing the list entries in */mac or */ide sometimes causes kernel oops. What’s wrong?

This problem should be fixed in the current version.

ATTENTION

THE INTENTION OF THIS SOFTWARE IS TO MAKE BACKUPS WORK AND SOFTWARE INSTALLATION MORE PAINLESS. HOWEVER, MAKING BACKUPS IS FOR SOME STUPID REASONS ILLEGAL IN MANY COUNTRIES. NEITHER THE AUTHOR NOR SOURCEFORGE CAN BE HELD LIABLE FOR ANY USE OR MISUSE OF THIS SOFTWARE. MOREOVER, USING THIS SOFTWARE IS COMPLETELY AT YOUR OWN RISK WITH NO GUARANTEES AT ALL.

Источник

16 Commands to Check Hardware Information on Linux

Hardware information

Like for every thing, there are plenty of commands to check information about the hardware of your linux system.

Some commands report only specific hardware components like cpu or memory while the rest cover multiple hardware units.

This post takes a quick look at some of the most commonly used commands to check information and configuration details about various hardware peripherals and devices.

The list includes lscpu, hwinfo, lshw, dmidecode, lspci etc.

1. lscpu

The lscpu command reports information about the cpu and processing units. It does not have any further options or functionality.

2. lshw — List Hardware

A general purpose utility, that reports detailed and brief information about multiple different hardware units such as cpu, memory, disk, usb controllers, network adapters etc. Lshw extracts the information from different /proc files.

Check out the following post to learn more about lshw

3. hwinfo — Hardware Information

Hwinfo is another general purpose hardware probing utility that can report detailed and brief information about multiple different hardware components, and more than what lshw can report.

4. lspci — List PCI

The lspci command lists out all the pci buses and details about the devices connected to them.
The vga adapter, graphics card, network adapter, usb ports, sata controllers, etc all fall under this category.

Filter out specific device information with grep.

5. lsscsi — List scsi devices

Lists out the scsi/sata devices like hard drives and optical drives.

6. lsusb — List usb buses and device details

This command shows the USB controllers and details about devices connected to them. By default brief information is printed. Use the verbose option «-v» to print detailed information about each usb port

On the above system, 1 usb port is being used by the mouse.

7. Inxi

Inxi is a 10K line mega bash script that fetches hardware details from multiple different sources and commands on the system, and generates a beautiful looking report that non technical users can read easily.

8. lsblk — List block devices

List out information all block devices, which are the hard drive partitions and other storage devices like optical drives and flash drives

9. df — disk space of file systems

Reports various partitions, their mount points and the used and available space on each.

10. Pydf — Python df

An improved df version written in python, that displays colored output that looks better than df

11. fdisk

Fdisk is a utility to modify partitions on hard drives, and can be used to list out the partition information as well.

12. mount

The mount is used to mount/unmount and view mounted file systems.

Again, use grep to filter out only those file systems that you want to see

13. free — Check RAM

Check the amount of used, free and total amount of RAM on system with the free command.

14. dmidecode

The dmidecode command is different from all other commands. It extracts hardware information by reading data from the SMBOIS data structures (also called DMI tables).

Check out the man page for more details.

15. /proc files

Many of the virtual files in the /proc directory contain information about hardware and configurations. Here are some of them

16. hdparm

The hdparm command gets information about sata devices like hard disks.

Summary

Each of the command has a slightly different method of extracting information, and you may need to try more than one of them, while looking for specific hardware details. However they are available across most linux distros, and can be easily installed from the default repositories.

On the desktop there are gui tools, for those who do not want to memorise and type commands. Hardinfo, I-nex are some of the popular ones that provide detailed information about multiple different hardware components.

A Tech Enthusiast, Blogger, Linux Fan and a Software Developer. Writes about Computer hardware, Linux and Open Source software and coding in Python, Php and Javascript. He can be reached at [email protected] .

48 thoughts on “ 16 Commands to Check Hardware Information on Linux ”

How i can check memory in CPU. Example OPT, Efuse

Thanks for this. I’m just getting going on a VPS and this helped me discover they’d not given me the extra 1Gb I ordered. Very well explained.

Super happy with
inxi -Fx

more accurate than some of the other utilities.. for instance hwinfo was inaccurate for my Lenovo

Thanks for the great post!

Thank you! Your descriptions were useful and well explained!

Источник