what is "Disk Identifier"?

m4rtin · 07-15-2009, 10:46 PM

when I look my HDD using fdisk there is a "Disk Identifier" value. Where does it come from? Is it calculated? Or stored somewhere in HDD firmware? Is it copied to MBR? What is it used for?

Erik_FL · 07-16-2009, 11:03 AM

Quote:

Originally Posted by m4rtin

when I look my HDD using fdisk there is a "Disk Identifier" value. Where does it come from? Is it calculated? Or stored somewhere in HDD firmware? Is it copied to MBR? What is it used for?

This is a somewhat confusing area of computers because people don't use consistent terminology. So first I'm going to explain some terms.

A Disk Identifier (or Disk Signature) applies to an entire hard disk drive (not a single partition). A Disk Identifier/Disk Signature is a 4-byte (longword) number that is randomly generated when the Master Boot Record/Partition Table is first created and stored. The Disk Identifier is stored at byte offset 1B8 (hex) through 1BB (hex) in the MBR disk sector. Windows Vista uses the Disk Signature to locate boot devices so changing it can prevent Vista from booting. So far as I know Grub and Linux don't use the Disk Identifier.

A UUID (Universally Unique Identifier) or GUID (Globally Unique Identifier) is a 128-bit number. UUIDs are used to identify many different things including some filesystem partitions. Where the UUID is stored for a filesystem depends on the filesystem. Linux ext2/ext3 and Windows NTFS identify filesystems by UUID. UUIDs are generated randomly using either the current time or a random number generator. The UUID is generated and stored when the filesystem is formatted and then does not usually change.

When you copy a partition or disk as raw binary data (for example, with "dd") the Disk Identifier or UUID is also copied. That can result in two disks or two partitions with the same identifier. There are utilities to change the UUID to a new (random) number. There are also utilities to change the Disk Identifier in the Master Boot Record.

The advantage to a UUID is that no matter where you move a filesystem, an operating system can find that particular filesystem. For filesystems that have no UUID the Disk Identifier can at least be used to locate the disk drive.

Windows identifies all filesystems using UUIDs so UUIDs are kept in the registry if a filesystem does not have a UUID in the partition. Windows uses the Disk Signature and other information to match the registry entry for a partition and find the UUID.

Linux can use device names for partitions when UUIDs are not available.

MarcusXP · 07-02-2010, 09:21 PM

Quote:

Originally Posted by Erik_FL

------------------------
A Disk Identifier (or Disk Signature) applies to an entire hard disk drive (not a single partition). A Disk Identifier/Disk Signature is a 4-byte (longword) number that is randomly generated when the Master Boot Record/Partition Table is first created and stored. The Disk Identifier is stored at byte offset 1B8 (hex) through 1BB (hex) in the MBR disk sector. Windows Vista uses the Disk Signature to locate boot devices so changing it can prevent Vista from booting. So far as I know Grub and Linux don't use the Disk Identifier.
------------------------
When you copy a partition or disk as raw binary data (for example, with "dd") the Disk Identifier or UUID is also copied. That can result in two disks or two partitions with the same identifier. There are utilities to change the UUID to a new (random) number. There are also utilities to change the Disk Identifier in the Master Boot Record.
------------------------

Could you please tell me what would be such an utility to change the Disk Identifier from the MBR? I've been searching like crazy but found nothing so far. Only to change the UUID for partitions, but that doesn't help.
I'd really appreciate it.

thanks,
Marcus

syg00 · 07-02-2010, 11:04 PM

Surprised you didn't find this thread.
I stand by my contention as a simple solution.

MarcusXP · 07-03-2010, 07:45 AM

Quote:

Originally Posted by syg00

Surprised you didn't find this thread.
I stand by my contention as a simple solution.

I was looking for something less error-prone. I suspected from the beginning I could do it with dd and hexedit the image, but I haven't tried, I am not that confident in my skills

I found a windows utility that worked for me (mbrwizard).
I was hoping to find a similar one for Linux as well, without involving hexeditors and such..

syg00 · 07-03-2010, 07:50 AM

I'll knock up a script next week when I can play on a machine I don't care about.
(this just to keep me subscribed to this thread).

wroom · 09-04-2010, 12:46 PM

Quote:

Originally Posted by MarcusXP

Could you please tell me what would be such an utility to change the Disk Identifier from the MBR?...

1. The easy, peasy GUI way:
One utility to do this with, is R-Studio, (http://www.r-tt.com), which is a very resourceful Windows shareware for disk handling and data recovery. I own a license for this and do recommend it for anyone working in detail with disk drives and data recovery. With R-Studio one can change the volume ID of a disk in guided mode, and also directly in the utilitys hex editor. I do believe that the trial version of this utility will let you change the volume ID of a disk.

2. The "near hardcore" console way:
The volume ID of a disk can easily be altered with the Linux fdisk utility in expert mode. Start fdisk for the disk you want to change volume ID for, and then enter command 'x' to get expert mode. In expert mode one can enter the command 'i' and fdisk will then display the current volume ID, (a.k.a disk identifier), and also prompt for changing it.

Just enter a fairly random hexadecimal number. And please check that the number you enter is unique to this disk in your system. The volume ID is not that trusted in the unix world, but be careful about Windows and DOS, where the volume ID is used. Changing the volume ID on a Windows machine can hurt bootability.

Also, please be advised that the volume ID sometimes is used for license verification. Changing the volume ID can render one or more software licenses invalid. When changing, make a note of what the volume ID was before the change, so that you can restore it if needed.

When you have changed volume ID of any disk, i would recommend you to immediately reboot the system. And if something bad happens you should have a bootable rescue media that lets you run fdisk to restore the volume ID.

But, i haven't been able to locate the ability to changevolume ID with either cfdisk nor sfdisk, which i find surprising. It seems fdisk is your friendly utility here. The utilities fdisk, cfdisk and sfdisk differ in many ways, and for a certain operation one of them performs exactly what you want, while the other variants may do something bad. Theese utilities should best be unified, and tidied up, concerning all the peculiarities of different partitioning, (DOS, Windows, Linux, cylinder boundaries or not, BIOS deviances, etc).

I would have expected the Linux utility "blockdev", by Andries E. Brouwer, to be able to change the volume ID of a disk, but sadly it cannot. It can get and set other different parameters of a block device, but not the volume ID. I would like to propose to add this ability to blockdev.

o-a-k · 09-04-2010, 03:57 PM

Just replaced a disk in a broken raid5 array, copied the partition table from another healthy disk in the array to the replaced one. To avoid having the same disk identifier on two disks - not that it matters that much, but anyways - I tried the fdisk approach mentioned by wroom. The changes were however not saved after choosing 'w' to write the partition table to disk. Maybe a bug (using util-linux-ng 2.17.2), or probably a user mistake? =)

Anyways, Instead of going the hexedit way, I wrote a little c program that alters the volume ID of a disk. It simply overwrites bytes 0x1B8 - 0x1BB with whatever you like. It might come in handy for someone else so I'm posting it below.

Code:

#include <stdio.h>
#define NEW_DISK_IDENT 0xDEADBEEF
#define IDENT_POSITION 0x1B8
#define IDENT_LENGTH 4 

void readDiskIdentifier(FILE* fp)
{
        fseek(fp, IDENT_LENGTH - 1 + IDENT_POSITION, SEEK_SET);
        for(int i = 0; i < IDENT_LENGTH; i++)
        {
                printf("%0*X", 2, fgetc(fp));
                fseek(fp, -2, SEEK_CUR);
        }
        printf("\n");
}

void writeDiskIdentifier(FILE* fp)
{
        fseek(fp, IDENT_POSITION, SEEK_SET);
        for(int i = 0; i < IDENT_LENGTH; i++)
                fputc(0xFF & (NEW_DISK_IDENT >> i*8), fp);
}

int main(int argc, char **argv)
{
        if (argc > 1)
        {
                printf("%s\n", argv[1]);
                FILE* fp = fopen(argv[1], "r+");
                printf("Current disk identifier: ");
                readDiskIdentifier(fp);
                writeDiskIdentifier(fp);
                printf("New disk identifier: ");
                readDiskIdentifier(fp);
                fclose(fp);
                return 0;
        } else
                printf(" usage: %s file\n Example: %s /dev/sdb\n", argv[0],
                        argv[0]);
                return -2;

}

Sample run:

Code:

$ fdisk -cul /dev/sdb
Disk /dev/sdb: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders, total 1953525168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x790b1f29

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1              63  1953520064   976760001   fd  Linux raid autodetect

$ gcc --std=c99 -o ndi ndi.c
$ ./ndi /dev/sdb
$ fdisk -cul /dev/sdb
Disk /dev/sdb: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders, total 1953525168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xdeadbeef

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1              63  1953520064   976760001   fd  Linux raid autodetect

wroom · 09-04-2010, 05:31 PM

Quote:

Originally Posted by o-a-k

Just replaced a disk in a broken raid5 array, copied the partition table from another healthy disk in the array to the replaced one. To avoid having the same disk identifier on two disks - not that it matters that much, but anyways - I tried the fdisk approach mentioned by wroom. The changes were however not saved after choosing 'w' to write the partition table to disk. Maybe a bug (using util-linux-ng 2.17.2), or probably a user mistake? =)

Indeed there is a bug in fdisk. Someone forgot to check for changes in the whole MBR buffer, and not only for changes in partitions. Strange that this little bug have survived this long, (years!), without anyone finding it?

Workaround:
After setting the new disk identifier, then change partition type of any of the partitions, then change it back again to what it should be. Then exit with the 'w' command. This time the disk identifier is written to the disk.

Now, how does one proceed to file this bug in fdisk so that it will go away?

Looking at the code for fdisk, and knowing the problematic nature of MBR, BIOS and partitioning i don't really feel encouraged to go ahead and make the change myself. I guess the recent implementation of libblkid has been a handfull for the maintainers of util-linux - But why not stomp out this little bug also? Don't know how much else is affected, but the bug seem to be in the code for detecting changes to the MBR buffer. My suggestion is to take on another philosophy for the change detection to be a more rudimentary memcmp() instead of just checking a diversity of change flags.

Edit: Forgot to mention that i currently used fdisk (util-linux-ng 2.13.1) and also did an ediff check with version util-linux-ng-2.18 source code, (ftp://ftp.kernel.org/pub/linux/utils...inux-ng/v2.18/), to see if someone had made any changes to this. Answer is no.

o-a-k · 09-05-2010, 09:15 AM

Yes, it is really amazing that such a bug has been around this long. I checked the util-linux-ng mailing list archives and noticed that this bug was confirmed in August and should now be fixed. See this mail thread: http://thread.gmane.org/gmane.linux....-linux-ng/3424