Hi All,
I've been experimenting with booting linux from a GPT-formatted drive on
a BIOS-based x86 pc.
=== (1)
Is there a grub "search" command variant to find the (hdx,y) value for a
GPT partition GUID? (I can't see one).
If not, do you think this would be a useful thing? I might be interested
in trying to code this up.
Yes, search.fs_uuid can also be used; AFAICS there isn't a *huge*
advantage to using partition GUID here, but it fits well with (2) below.
=== (2)
When linux is started without an initrd, the root= param supports only
* root=major:minor
* root=number where number is major<<n + minor
* root=/dev/sd{n}{p}
where n depends on the order in which linux discovers the disks,
and p is the partition index.
None of these options are robust against hardware changes that change
the linux disk enumeration order. When an initrd is used, then
UUID/LABEL can work around this but without initrd these are not
available.
So what do you think about
(a) adding root=GUID as a kernel option
(b) optionally using the search command from (1) above
so that something like the following can be done:
set ROOTGUID=ABCD1234ABCD5678
search.gpt_guid $ROOTGUID
linux /mykernel root=$ROOTGUID
It seems to me that both the grub and kernel parts are reasonably
simple. The kernel just needs to be enhanced to store the GUID value on
the relevant device objects as it creates them. File do_mounts.c already
iterates over all devices to handle "/dev/sda1" style paths, so this can
just be enhanced to check the new GUID value too. And the "guidmap"
command should be really trivial.
Note that root=GUID can be implemented with just support for
partition-schemes compiled in to the linux kernel (which is usual; GPT
support is there by default). The GUID is just an array of 16 bytes in
the partition table, and linux scans the partition tables already.
This solution also appears to be reasonably cross-platform, as GPT is a
platform-independent and bootloader-independent specification.
Supporting filesystem UUID in the kernel without an initrd just isn't
going to happen; it requires filesystem drivers.
===
Any thoughts?
Regards,
Simon
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
