[Top][All Lists]

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

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

From: Vladimir 'φ-coder/phcoder' Serbinenko
Subject: Re: Purposing an Alternative Feature Request: Make Use of Whole-Disk UUIDs
Date: Sat, 04 Feb 2012 12:32:42 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0

On 04.02.2012 12:11, Jake Thomas wrote:
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.

A similar but somewhat different approach was already proposed: use partition UUIDs. GPT has per-partition UUIDs and msdos uses the format <msdos id><start sector>. The conclusion is the same for both ideas: it's realisable and patches can be included as long as: 1) interface and code is independent of actual partmap (e.g. search --partition-uuid is fine but search --gptuuid isn't)
2) it doesn't increase the size of kernel or patmap modules
3) isn't default
So it's mostly "patches are welcome"
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:

hd-uuid would refer to the hardware uuid. partmap-uuid is better name
"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.

We've been down this road before. Terribly inefficient.

Vladimir 'φ-coder/phcoder' Serbinenko

reply via email to

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