[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Purposing an Alternative Feature Request: Make Use of Whole-Disk UUIDs

From: Jake Thomas
Subject: Purposing an Alternative Feature Request: Make Use of Whole-Disk UUIDs
Date: Sat, 4 Feb 2012 03:11:37 -0800 (PST)

I figured I better give this its own thread, but it stems from "[bug #35354] Cloning GRUB2 1.99 makes clone not bootable".

Is the following a valid suggestion? It'd be pretty powerful and useful if it could be done:

Suppose Grub could utilize MBR and GPT header whole-disk UUIDs. In the MBR, from the four-hundred forty-first byte to the four-houndred forty-fourth byte is a 4-byte disk id, see "master boot record" in Wikipedia. This is not the kind of disk-id you folks have been talking about. You folks have been talking about some hardware name of the hard drive as reported by the drive's firmware. That hardware name is not stored on the hard drive part of the hard drive (main storage area). It's located on a ROM chip with the firmware (or sneakily put on a negative sector of the actual hard drive part of the hard drive that gets hidden by the firmware). I'm talking about something that is easily mutable and visible by a hex editor looking at, say, /dev/sda.

Likewise, in the GPT header of GPT-structured hard drives is a 16-byte UUID for the whole hard drive. GPT-structured hard drives will still have an MBR disk-id in their protective MBR, but it is preferable to use the GPT header's UUID if the disk is GPT-structured.

The whole-disk UUID is very much parallel to an individual partition's UUID, except it is for the whole disk. Both are easily mutable without data loss: you can change a partition's UUID without loosing data on that partition, and you can change an MBR's whole-disk UUID without destroying any data in the partition table or boot code. Both are right in main storage and can be edited with normal read/write commands, as opposed to requiring a firmware-flash to be edited (to rename a hard drive's hardware name, you would need to flash its firmware).

So if Grub already uses partition UUIDs, by symmetry, Grub should also support whole-disk UUIDs.

Suppose this was done:

Add an "--hd-uuid" parameter to the search command that paralells the "--fs-uuid" parameter so that one could do something like the following:

"search --no-floppy --fs-uuid --set=root 0x94f81ddc,3"

This would search all hard drives for a UUID of "0x94f81ddc" and set the root to the 3rd partition on that hard drive.

And maybe even do this:

Perhaps let someone, in a Grub stanza, replace "set root='(hd0,3)'" with "set root='(0x94f81ddc,3)'", if  partition 3 of the disk with the ID of "0x94f81ddc" was the goal partition.

This would solve cloning-related issues as far as Grub is concerned (not going into software raid and other such sticky topics), provided only partitions are cloned and restored rather than whole hard disks.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]