[Top][All Lists]

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

search and boot using GPT GUID values

From: Simon Kitching
Subject: search and boot using GPT GUID values
Date: Tue, 06 Apr 2010 20:22:44 +1200

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

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?


reply via email to

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